[3.5.0] &filters=private is ignored in DLMenu – Frontend login how to?

[leonie12]

In one of my websites I use DLMenu to create the Navigation. Because there is a login-restricted section the navigation is generated using a switch:
[[Personalize? &yesChunk=content-navi-logged-in &noChunk=content-navi-logged-out]]

Chunk content-navi-logged-in: [!DLMenu? &config=content-navi:custom!]
Chunk content-navi-logged-out: [!DLMenu? &config=content-navi:custom &filters=private!]

This works fine at least with Evo CE 3.1.30 and worked with former releases (I do not know which) of Evolution CMS.

Now &filters=private is ignored and the private pages are shown even if the user has logged out.

[Dmi3yy]

How it should work if you use [[cached snippet with logic where should be not chached [! So you got first result every time

[leonie12]

If I use Personalize uncached there is no navigation at all but the call in plain text. I used it since years like this because at least there was that nested snippet calls needed to be alternating between cached and uncached. With Evo CE 3.1.30 it works like this til now.

What could/should I change to make it working again?

[leonie12]

Nice side-effect of cc2fb6b is that it solved also this issue. Now the nested Personalize DLMenu-Call works like it once did …

[leonie12]

Sadly i was too fast with closing the issue: It seems that cc2fb6b did not solve this issue as a side effect. It worked in that case only because I installed an older backup before.

Actually my frontend login is managed by formlister/userHelper and Pathologic's modxapi. I am not sure if this worked before with evolution-cms 3 or only with Evo CE 3, where it still works.

I can nowhere find instructions how to setup a frontend login for web users to get access to restricted ressources.
Is formlister and Pathologic's modxapi the actually recommended way of signing in for frontend login or is there anything else in evolution-cms core? Where can I find documentation?

[Dmi3yy]

We have only one documentation: is docs.evo.im

And about users:

https://docs.evo.im/03_develop/06_di_v_evolution_cms/05_usermanager.html

[Dmi3yy]

FormLister, DocLister, modxApi, DLMenu

That all deprecated component, we not test them so if you have problems you can describe what and where not work with details and then we can help.

There you can find a lot of information how use laravel components and not use old legacy

https://modx.evo.im

[leonie12]

Hi Dmi3yy.
In the past and in parts until now one of the main advantages of MODx/Evolution CMS was its simplicity, that it was easy to setup websites with most necessary functions using just snippets and plugins. I think this made it attractive to many non-programmers like me.
I translated documentation about user mangement under https://modx.evo.im/ and read it, trying to understand how to replace existing snippet calls with whatever … Sadly it is too confusing for me to grasp where to start and what to do.

At the moment I use formlister for frontend login on a login page (307) like this:

[!FormLister?
&formid=`login`
&controller=`Login`
&model=`Pathologic\EvolutionCMS\MODxAPI\modUsers`
&modelPath=`core/vendor/pathologic/modxapi/src/modUsers.php`
&loginField=`username`
&passwordField=`password`
&allowedFields=`username,password`
&rules=`{
	"username":{
		"required":"username (required)"
	},
	"password":{
		"required":"password (required)"
	},
}`
&context=`web`
&formTpl=`@CODE:
	<form method="post">
		<input type="hidden" name="formid" value="login">
		<div class="form-group[+email.errorClass+][+email.requiredClass+]">
			<label for="username"><b>username</b></label>
			<input type="text" class="form-control" id="username" name="username" value="[+username.value+]"/>
			[+username.error+]
		</div>
		<div class="form-group[+password.errorClass+][+password.requiredClass+]">
			<label for="password"><b>password</b></label>
			<input type="password" class="form-control" id="password" name="password" value=""/>
			[+password.error+]
		</div>
		[+form.messages+]
		<div class="form-group">
			<button type="submit" class="btn btn-primary">Login</button>
		</div>
	</form>`
&messagesOuterTpl=`@CODE:<div class="alert alert-danger" role="alert">[+messages+]</div>`
&successTpl=`@CODE:<div>Login succesfull, [+fullname.value+]!</div>`
&errorTpl=`@CODE:<div class="alert alert-danger">[+message+]</div>`
&requiredClass=` has-error`
&errorClass=` has-error`
&requiredClass=` has-error`
&redirectTo=`30`
&exitTo=`30`
&skipTpl=`@CODE:	<a href="[~307~]?logout">Logout</a>`
!]

The main navigation on every page is created by DLMenu which is functioning well also with evolution-cms 3.5.
It is called by this chunk:
[[Personalize? &yesChunk=content-navi-logged-in &noChunk=content-navi-logged-out]]

where chunk content-navi-logged in is this: [!DLMenu? &config=content-navi:custom!]
and chunk content-navi-logged-out this: [!DLMenu? &config=content-navi:custom &filters=private!]

How could I recreate this functionality with evocms core functions, ideally snippets?

Even if formlister and co are deprecated and are not as easy to use as one would wish they are at least snippets with parameters that are easier to understand and use for non-programmers than laravel.

I think that it would be great to have easy to use snippets for core functionality like login/logout like it was in recent times. But I would also be glad about some advice that would also be usable as a how-to for other users searching for advice.

[leonie12]

What does

FormLister, DocLister, modxApi, DLMenu. That all deprecated component.
mean. Not too long ago they were the supposed way to go and should for example replace ditto, wayfinder, weblogin etc, which were then deprecated. Where can one see if something is deprecated and what the supposed replacement is?
How behav these deprecations in respect to the goal of backward compatibility?

[Dmi3yy]

I not see simplicity in Formlister

New way match simplest and universal.

https://gist.github.com/Dmi3yy/10e5a004bb77a72a4446ac1ad4c2d9ad

Just look on this example how you can work with form without any additional snippet like FormLister

Because whay need use this monstr snipet if it work without it

Sure if you stoped your study on modx

Then sure for you easy way old way necause no need do any think

But if you spent 10 hours to your study how work Evo 3.0 and why we choose Laravel component and what reason then you will shop use old solution

Yep for you your way somplest just because you have a lot expiriences with legacy

But just think why some part is legacy ? Maybe because we find simplest way ?

Yep old fuel car is good but smell bad and beed more service

So if you prefer old legacy way then why you spend time to use new version ? What sence ?

Use old one or russian edition they like old legacy be with them. Whay you write there ? Not understand realy

You not go in direction where we go and not happy what we not support lagacy ( by the way you want free support of legacy )

So select another direction not a problem

[leonie12]

I appreciate your work on evolutioncms and your helpful responses.
If, like me, you volunteer to maintain the website of a small non-profit organization, you'll be glad if the CMS allows you to implement the desired functions as easily as possible without having to “study” the CMS.

I have been using MODx/Evo for over 15 years and have always tried to keep up with the changes and to contribute as much as I can, for example by testing the latest releases and reporting bugs. To this end, I have always read and “studied” the documentation and searched the forums for solutions and advice.
I use evolutioncms 3 since it was released because it seemed like the more futureproof solution.
In recent years, however, there have been repeated abrupt changes, the former forums have been discontinued, the new ones are hardly used, there was/is little or at least not easily accessible and up-to-date documentation, and I, at least, have no longer been able to understand what the recommended procedures are, which versions are being further developed, what is deprecated and what is replacing it, etc.

For this reason, I currently have both evolution-cms and Evo CE installed and am following the further development of both, asking questions where I hope to find answers. Recently, there has been several years of uncertainty about the further development of evolutioncms, which certainly drove many to Evo CE, which was actively being developed by different members of the community at the time.

For users of open source tools, it is neither apparent nor important who the main maintainer is or what nationality individual members of the community are, as long as the joint project is free from political influence. In the past, the focus of the community has shifted regionally time and again, but there has always been participation from developers from all over the world. For me, the latter is an essential part of the open source idea, that everyone can contribute, regardless of age, origin, or religion.

When it comes to legacy, is it really the case that user-friendliness (usability even for non-programmers and users) and further development are mutually exclusive? Easy usability even for non-devs, good documentation with examples, and a helpful community have always seemed to me to be one of the great advantages of MODx.

[Dmi3yy]

Thank you for sharing your thoughts and concerns. I’d like to clarify a few important points and give some context from my side.

First of all, Evolution CMS is something I actively support and develop. Sergey and I are currently the main maintainers of EVO. I’ve been with this system from the very beginning — my first installation was MODX Evolution 0.7. Over the last 20 years, I’ve built well over a thousand projects on EVO, so this is not a theoretical discussion for me, but a long-term, practical commitment.

You mention that you are following the changes, but in practice this doesn’t seem to be the case. Around five years ago, we introduced Laravel under the hood. This was a major step that effectively raised EVO from a typical open-source CMS level to an enterprise-grade platform — without complicating the codebase, but actually simplifying it. I strongly believe in reducing complexity, not increasing it.

The problem is that many users continue to rely on legacy components and then say they are “following the changes”. In reality, they are not. The Laravel integration has been explained in detail, including video tutorials that are still fully актуальні today, even though they were recorded five years ago:
• https://www.youtube.com/@EvolutionCMS2/playlists
• https://www.youtube.com/watch?v=JjIX3gkTVwA&list=PLKTHZGrYLdto_T6SjfZsdFD3SnRlAYk_c

If these materials are ignored, it’s not correct to say that “the core was broken” or that changes were unclear. Using legacy components is, of course, your right — but it’s not a reason to shift responsibility and say that the maintainers are doing something wrong.

Regarding the forums: the old forum on modx.im was moved to modx.evo.im and is now read-only. The reason is simple — LiveStreet turned out to be a very inefficient system and caused server issues even with a small number of users. That’s why a new, active forum was created:
• https://forum.evo.im/

We also deliberately switched to English there, to move away from a purely regional (Runet) focus and support true internationalization.

As for the changes in recent years — many of them are directly related to the fact that a full-scale war started in my country, Ukraine, and has been ongoing for four years now. Unfortunately, the people most actively promoting EVO-CE come from the same side that attacks my country. EVO-CE was not even properly forked — there is no fork from Evolution CMS and no fork from MODX CMS. For me, people who steal free open-source code and at the same time support or justify rockets flying into my home are enemies. I have no intention of cooperating with them.

That said, in practical terms very little has “broken”. What changed is that I stopped actively promoting new features publicly and instead focused on deepening my knowledge and improving the architecture. Out of my 42 years of life, 21 have been spent on EVO. I see no reason to abandon it — especially now, when backend technical debt is largely eliminated thanks to Laravel and its ecosystem. The framework community covers that debt, provides tooling, examples, and documentation. All of this exists — but very few people actually read it.

For end users, everything works fine. But a developer — or someone who claims to be a developer and earns money by building projects for clients — must understand what’s under the hood. Otherwise, that person is a manager, not a developer. The lack of UI for some new features is not a “core problem” — it’s a community issue. I didn’t sign up to do everything alone. I develop EVO the way I see fit and according to real client needs: Git workflows, dev/prod environments, auto-deploy, dependency management, version control. Legacy architecture simply cannot handle this properly, which is exactly why it is being refactored.

The Laravel component-based approach works extremely well and requires far fewer maintenance resources.

Yes, we still have technical debt in the admin interface and UX, and we are working on it. But the future is clear: developers who can only work through the admin panel will soon be unnecessary. Clients will be able to do much more themselves, especially with AI that understands Laravel well and can assemble solutions directly.

Legacy slows everything down. If someone hasn’t been able to understand how the system works in five years — when it actually takes about 40 minutes and 5 lessons — that’s not a core problem. Complaining that “the core is broken” is easier than improving one’s skills.

To be honest, I don’t really care how or what you use. I see the path I started 21 years ago. Yes, I made mistakes along the way, but the direction has always been the same — and now I see it more clearly than ever.

The real issue is that about 99% of the community only wants to take — because it’s free — and is not willing to invest anything back. Complaining about documentation while contributing nothing is hard to understand, especially when we are always available to answer questions directly. Documentation doesn’t write itself — it’s built through learning and contribution. That’s how I started, and I wasn’t alone.

Criticizing those who actually do the work, while doing nothing yourself, is a classic pattern. This is open source — you’ve been using it for 15 years. If there has been zero contribution, then the only valid claims are to yourself, not to the maintainers. I also don’t see any contribution to the tool you’re making a living with.

One more important correction:
We are not MODx and not MODX.

We are EVO or Evolution CMS — and have been for 8 years already. If after all this time the project name is still unclear, I strongly recommend starting with the basics:
• https://modx.com/blog/evolution-cms-has-a-new-home

MODX officially dropped EVO. Since then, this project has had no relation to MODX. Yes, legacy code still contains $modx, but that’s because we don’t do blind search-and-replace. We carefully refactor and clean things up. “If it works, don’t touch it” still applies — but when it doesn’t work, we fix it properly.

Right now, for example, I’m refactoring session handling, because legacy and Laravel sessions running side by side on the same server can cause bugs. We fix this carefully, while maintaining backward compatibility for legacy users.

So the direction is clear, the work is ongoing, and the foundation is solid. EVO is moving forward — not away from usability, but away from stagnation.