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.

Hello,

I had this exact same issue on a fresh install. Nothing saved in the URI column for site content in the database, and plenty of these errors when I ran Manage > Clear Cache > Refresh URIs, although by the time I got these it seemed to be resolving itself.

Resource URI program-search.html already exists for resource id = 38; skipping duplicate resource URI for resource id = 312
Resource URI classical-cafe.html already exists for resource id = 72; skipping duplicate resource URI for resource id = 73
Resource URI class-db-staging.html already exists for resource id = 36; skipping duplicate resource URI for resource id = 309
Resource URI classes-staging.html already exists for resource id = 37; skipping duplicate resource URI for resource id = 310

It had previously had ‘Resource URI classes-staging.html already exists for resource id = 2; skipping duplicate resource URI for resource id = xx’ where xx seemed to be every other page in my site.

I had .htaccess in
I had friendly url property turned on
No duplicate tables

When I tried to directly load a resource with ‘Domain.com’ I got a blank page with just a number - the ID the page was pointing to if it was a container.

No unique settings in web or mgr contexts related to urls - I didn’t know I could set them at a context level, I went straight to settings.

The errors also happened after I added the to the header.

But then, after hitting Manage > Clear Cache > Refresh URI a few times, it seemed to fix itself, which I don’t get at all.

So just adding my voice to this odd issue.

Thanks,
Jen

What this is saying (as you probably know) is that the resource with the ID 38 has the same URI as the resource with the ID 312. Typically, there are only two causes for this. 1) They have the same alias, or 2) Their aliases are both empty.

Is the “Freeze URI” option checked on any of the listed resources? That might keep MODX from storing the correct URI to the DB.

Hi! Thanks for replying!

Gotcha on the reason for them. These few make sense and I’ll look to check for either of those cases tomorrow, but when I first had them it was literally pages and pages of:

‘Resource URI classes-staging.html already exists for resource id = 2; skipping duplicate resource URI for resource id = xx’

Where XX was every page of my site. This was without Freeze URI, and the URI column in site_content was empty. Not sure why.

Just wanted to weigh in that it’d happened to me too :slight_smile: