Improve URI character limit handling

[smg6511]

What changed and why

Removed hard front end limit on URI field and added limits based on the cache_alias_map system setting:

1. When the map is off routing depends on db indexing which, in the current implementation, limits the URI character count to 191 for reliable operation.*
2. When the map is on, URI length can be unlimited but research indicates it's advisable to limit this for performance and usability reasons; the max of 2,000 commonly comes up and that's what the new default limit is via the introduction of the uri_max_length setting

When these limits are reached, a general error is emitted instead of trying to show a field error on the URI input. This choice was made because it's difficult to reconcile the fact that this field's derived value can be invalid whether or not Freeze URI is on—but it needs to be on to see an error when it's emitted on the field itself.

*Manual testing shows that when uris go beyond 191 characters, particularly when the first 191+ characters are not unique (imagine documents within a very deeply nested folder with relatively long alias lengths along the way), individual documents at that depth cannot be navigated to reliably (or at all).

Error Display

The new error is relatively verbose about how to resolve the issue and provides direct links to the system settings that can be changed to overcome the limit causing the error. This brief video shows what to expect:

modx-uri-error-solution-2.mov

HTML in Error

One other small change to the js allows the general error to include html by changing the message method from alert to show. This will not affect current implementations but will allow html messages when they're properly json encoded. (See the change to modx.js.)

How to test

1. There are a few css additions for the error window, so grunt build is required
2. Create a folder structure with long page titles so you can reach the 191 character limit; this will be needed to test the case when cache_alias_map is off
3. With cache_alias_map on, change the uri_max_length setting to a reasonable length to test its operation; I used a short length of 80 (and even less) to easily verify
4. Follow the links in the error message to verify they lead directly to the setting mentioned

Related issue(s)/PR(s)

Alternate to PR #16895; solves #13815

Although this PR covers an arguably edge-case situation, it adds the benefit of allowing admins to limit URIs to they're liking to keep content editors from running wild with complicated/long structures and titles.

Compatibility notes

n/a

Breaking change assessment

None. Temporary BC references from old methods (marked deprecated) to new Trait method.

Test coverage

New cases added to ResourceCreateProcessorTest for basic coverage for new Trait takes the place of Create->prepareAlias and Update->checkFriendlyAlias and URI character length limits

Contributors

Review of @Ibochkarev's initial proposed solution prompted this alternate one.

AI tool use

n/a

[smg6511]

A Different (Almost) Solution Set Aside for Now

Just for reference, I'd initially tried to solve this with emitting the URI field error in mind, but it became too difficult to properly maintain the correct state of the alias and uri along the way — it can be done, but I concluded it wasn't worth the effort right now (I'd argue a general refactor of how the whole alias/uri generation works and how it's placed in the UI will be in order for some future MODX version). In this version, the URI is always visible, but disabled unless Freeze URI is on OR there was an error on the field. Also, a live character counter is shown on the errored field once editing begins. Here's what it was looking like:

modx-uri-error-solution-1.mov

[Mark-H]

Lil' bit worried about the modx.js change making it render HTML. That might trigger for a bunch of different scenarios, including when rendering HTML is not expected.

Perhaps at the very least parse that through the safeHtml utility we added a few versions ago?

[smg6511]

Perhaps at the very least parse that through the safeHtml utility we added a few versions ago?

Although I don't anticipate this ever seeing user input (at least that which isn't controlled by the core or Extras), it's not a bad idea to sanitize the message at that point to be sure (although if a message makes use of user input it probably should have been sanitized beforehand). I'll add that in this evening.

Just in case, one thing to be clear on is this change only allows html to be used in the error messaging, assuming it was properly encoded on the php end of things; it doesn't expect html or transform the incoming content in any way other than decoding it.

Good to see you back in action!

[smg6511]

UPDATE: Applied safeHtml to message in showError method.

The completely ideal implementation would be to have a new modx.js method showFormattedError that supports html and leave showError as it was, but I cannot for the life of me figure out how to get an object (in this case array) passed as a second arg to the modError::failure method to pass through to the response data on the js side, e.g. I was thinking I'd signal which show method to use like so:

$this->failure('A message', ['isFormatted' => true]);

But, that array data is nowhere to be found in the js failure response.