URI not updated after save

PHP 5.3.13
IIS 7.5
MS SQL
ModX revo 2.2.4 (fresh install, not an upgrade form previous)

Strange issue.
The uri in the database is not updated after resource is saved.
Alias is fine, but the uri is not, which messes up the friendly url.

One particular bad case is with resources that was duplicated.
The uri didn't change on duplication, and saving the resource doesn't update it either.

I'm going for a sql fix to get them to work, just want to see if anyone else is having this issue.

note: not cache issue, it's the uri column in the db. And there are no errors in the ModX log. [ed. note: developer_tw last edited this post 14 years, 1 month ago.]

Do you have Freeze URI checked? That will prevent any changes to the URI.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Ok, to shamelessly hijack this thread, can somebody please explain to me what the URI is? And why there should be a checkbox for freezing it? [ed. note: sottwell last edited this post 14 years, 1 month ago.]

... can somebody please explain to me what the URI is?

A URI stands for Unique Resource Identifier. It is a standard for accessing resources (be they content, data, or execution) across a network of devices (most often a wide area network). URIs are used for a ton of things, including Android packages, ActiveDirectory, the entire WWW, FTP, Gopher, even accessing hard drive data uses an outdated URI convention. A URL is a type of URI. URIs are built in the following way:



Example:

In the URL (htt.p://forums.modx.com/thread/78683/uri-not-updated-after-save#dis-post-433707), http is the scheme, forums.modx.com is the host, thread/78683 is the path, uri-not-updated-after-save is the resource, dis-post-433707 is the position and there are no parameters.

So, for the purposes of MODx, the URI is also equivalent to the URL.

And why there should be a checkbox for freezing it?

This is because most broken links on pages are due to alias changes and structure change. If the URL changes after it is live this can have dramatic effects upon your site, its indexing, and its search results placement. Further, if there are link-backs, all of those break.

Freezing the URI can make sure that no matter your changes, the page will always be at the same address (as long as it isn't deleted). The will make sure that search results aren't diluted, manual links aren't broken, and engine placement remains contingent upon the evaluated comparative criteria of competitive sites. (Hint: This is why wikis often have so many redirects)

Further Notes:

Freeze URI should never or rarely be used on a development site before it goes live. In general, it should rarely be used unless you cannot afford to: either a) deal with the "lag time" between index additions, changes and removals; or b) rely on link-backs to fix themselves. There are many "better practices" in lots of others' opinions. You could create a permanent redirect, which would fix the link-backs and indexing all at once, for instance. [ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

There could be other uses, but I think one is to let users customize the URL for specific pages or to have an unusual URL scheme that can't be easily generated by MODX's built-in URL generation.


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

(I know what a URI is in general) so basically it's to set a permanent URL for a given resource and prevent it from ever being changed. So Revo uses this field instead of fussing around with alias + extension + alias path settings?

@BobRay

There could be other uses, but I think one is to let users customize the URL...

Absolutely. As a matter of fact, Articles applies a slightly different URL scheme to its Article Containers such that Containers in Containers are treated as siblings rather than Parent/Child. It doesn't freeze the URI though.

I can't think of very many other uses (right now), but I'm sure there are others.

@Sottwell

I know what a URI is...

I'm sorry. The question was general, so I assumed that you needed general information. I was working in software for 6 years before I actually learned what a URI was... LOL. I had been using them for years and didn't have a clue.

So Revo uses this field instead of fussing around with alias + extension + alias path settings?

For as long as it is applied, yes. Remember the URI is set upon Refreshing the cache. So, when you check the Freeze URI and save, if Refresh Cache is checked, it runs makeUrl() one last time on the Resource and never again. If Refresh Cache is not checked, it locks the URL to its current value (if it has one). This basically turns off the automatic request to "makeUrl()" on refreshes for as long as it is on. The alias can be manually changed via xPDO again. You may also manually use makeUrl().

Personally, I prefer to use the default workings of MODx, They tend to account for most things.
[ed. note: fuzzicallogic last edited this post 14 years, 1 month ago.]

According to the database settings I see for individual Articles resources (class_key = Article), url_override is set to 1, so what does that mean?

That means that the Articles Container sets the URI. When you place an Articles Container in an Articles Container, the URLs for the child and parent are siblings to each other (according to URL path).

The children get their URL from the Container specifically...

Example:
Assume Container1 is in root, Container2 is a child of Container1. URL for Container1 is http.://base_url/Container1. URL for Container2 is http.://base_url/Container2/. Children of each recieve their URL from the relevant container. This is just one of the many nuissance nuances of Articles, despite its amazing construction.