Bug #3988
cache history not working completely
| Status: | New | Start date: | 2009-07-27 | |
|---|---|---|---|---|
| Priority: | Could have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Votes: | 0 |
Description
In my cachehistory table are the following entries:
uid tstamp mpvar workspace rootpid languageid pageid path
11 1248371255 0 1 0 5 test123456
12 1248371369 0 1 0 5 test12345
13 1248371377 0 1 0 5 test1234
14 1248371380 0 1 0 5 test123
17 1248444953 0 1 0 5 second-page/regenerateAll of the history links work fine apart from the last one. I.E I can go to
http://localhost/v3/test123.html
http://localhost/v3/test1234.html
http://localhost/v3/test12345.html
http://localhost/v3/test123456.html
And the page loads fine. If I go to
http://localhost/v3/second-page/regenerate.html realurl generates an error saying the keyword is missing - i.e it can't find the page.
I can't find enough documentation to say if this is actually a bug but I thought the cachehistory existed so that when you renamed a page old bookmarks would still work? I hope that I have not totally misunderstood its purpose and wasted your time. If it is a bug please let me know what other information you might require to debug.
Associated revisions
Fixed bug 3988: /start/Feedback gets not found because of uppercase; searchTitle_searchPid() return does not use "encoded" version in lookup
History
Updated by Ralph Hardwick almost 4 years ago
I have tested various other url strings and noted whether or not they have a problem.
http://localhost/v3/seven/888.html - WORKS
http://localhost/v3/777/888.html - WORKS
http://localhost/v3/second-page/regenerate.html - FAILS
http://localhost/v3/secondpage/regenerate.html - WORKS
http://localhost/v3/second-page/regenerat.html - FAILS
http://localhost/v3/secondpag-e/reg-enerate.html - WORKS
http://localhost/v3/second-page/888/999.html - FAILS
The last one returns the array of:
Array ( [0] => second-page [1] => regenerate ) Array ( [0] => second-page [1] => regenerate )
It appears that the problem is second-page which is a valid path in the main tree. Here is my page tree:
- Homepage for the dummy site
o LEVEL 1 TEST CACHE
o Second Page
+ Third Page # Fourth Page
o REGENERATE
When I rename "second-page" to "second-page-backup" the urls in the cache history that contain the path "second-page" begin to work.
Sorry if this information is confusing, I'm trying to provide as much error information as I can.
Updated by Tolleiv Nietsch over 3 years ago
- Status changed from New to Needs Feedback
You're right that's what the history is used for - could you please try to reproduce this with the latest SVN-version of the extension?
Updated by Ralph Hardwick over 3 years ago
I will try that. Where can I download the latest version from?
Updated by Tolleiv Nietsch over 3 years ago
- File T3X_aoe_realurlpath-0_3_0-z-200910281250.t3x added
Updated by Daniel Poetzinger about 3 years ago
- Priority changed from Should have to Could have
Hey
The behaviour is by intention:
the logic checks for matches in the non-history table. If there is a path containing "second-page" this is threated as a hit and there is no lookup in the history table anymore.
Problem is the last pathparts could also be postvars.
Another modi of detection would be useful in this case, but still wont work with postvars in the history
1) check cache for full path
2) check history for full path
3) check cache with decreasing path
Updated by Dmitry Dulepov over 2 years ago
- Status changed from Needs Feedback to Resolved
- % Done changed from 0 to 100
Applied in changeset r3863.