MODx3 Friendly URLs causing blank links?

MODx cloud using 3.0.0-pl

When I enable FURLs all Wayfinder links and link tags [[~2]] are being rendered as blank.

When I clear the cache I see error messages like this:

[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 2
[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 3
[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 4
[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 5
[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 6
[2022-04-08 07:24:34] (ERROR @ /www/core/src/Revolution/modCacheManager.php : 122) Resource URI already exists for resource id = 1; skipping duplicate resource URI for resource id = 7
[2022-04-08 07:24:42] (ERROR in resource 1 @ /www/core/src/Revolution/modLinkTag.php : 114) Bad link tag [[~2]] encountered
[2022-04-08 07:24:42] (ERROR in resource 1 @ /www/core/src/Revolution/modLinkTag.php : 114) Bad link tag [[~7]] encountered
[2022-04-08 07:24:42] (ERROR in resource 1 @ /www/core/src/Revolution/modLinkTag.php : 114) Bad link tag [[~3]] encountered
[2022-04-08 07:24:42] (ERROR in resource 1 @ /www/core/src/Revolution/modLinkTag.php : 114) Bad link tag [[~6]] encountered

Without FURLS on the links (/index.php?id=2 etc) are rendering fine.

My site only has 7 resources and they all have unique aliases.

Any suggestions will be greatly appreciated?

Does it help if you run “Manage” → “Clear Cache” → “Refresh URIs”?

Are the values in the column uri of the database table modx_site_content correct and unique?

Hi and thanks for responding.

I’ve tried Refreshing URIs without any positive affect.

The all the uri values in that table are empty?

So the system setting friendly_urls is set to Yes.
There is a value (with normal characters) in the field “Resource Alias:” ([[*alias]]) of the resource.
The checkbox “Freeze URI” is unchecked.
You click save, and the column uri of the database table modx_site_content stays empty?

See if you might have double resources in the DB, with different class_key fields. I’ve seen this on a MODX 2 site that was upgraded to a MODX 3 alpha version.

halftrainedharry - Yes that is correct. Even if I manually set the ‘uri’ value to ‘support.html’ for *id=2 (directly into the table), the ‘uri’ value is reset to ‘’ after save.

This is a fresh install of 3.0.0.-pl in MODx cloud (php 7.4) with default system settings. Only a handful of context settings are set for the ‘web’ context:

bobray - there are no duplicate resources in the ‘modx_site_content’ table:

This is weird.
The field uri should be set (in this line) when you save the resource.


If you create a snippet with the following code and run it on the resource, does it produce the correct output?

<?php
return "alias-path = " . $modx->resource->getAliasPath($modx->resource->get('alias'));

Ok I’ve found the problem.

halftrainedharry - That snippet does indeed display the correct output:

But with ‘friendly_urls’ turned on in the ‘web’ context settings the ‘uri’ value was still blank.

So, I bypassed the context settings - and enabled ‘friendly_urls’ in the System settings and boom, the ‘uri’ value is now being created correctly and things are working as expected.

It seems that the context setting is not overriding the system setting?
Is this expected behaviour?

Did you try setting the context setting for both the web and mgr contexts? If you set it for the mgr context, it wouldn’t apply in the front end. If you set it for the web context, it might not apply in the Manager.

I have noticed some possible weirdness with the settings hierarchy, in MODX 3, though. User settings for the current, logged-in user should override any usergroup, context, or system settings, but that doesn’t seem to work in some situations.

I haven’t had time to investigate it properly. If you want to check, you can create a setting with the same key at each level and make the value, the type of setting it is (so the context setting value would be ‘context setting’). Then display the value with a setting tag:

[[!++setting_key]]

You could also get the setting in code with a one-line snippet:

return $modx->getOption('setting_name');

You shouldn’t get the user or usergroup setting in the front end unless the user is logged in to the front end, if they are logged in, the user setting should show up in both cases.

It makes sense that the ‘friendly_urls’ setting would only work at the system level as it requires global nginx configuration as well.

I’ll investigate system/context/user settings scope further when I have the time but for now the system setting is working as expected.

bobray & halftrainedharry - Thank you so much for your assistance. It is very much appreciated.