-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for all your feedback.
I had a meeting today and we investigated in detail. Result: Once a page is moved/renamed, realurl correctly expires the pathcache entry. However, child pages of a moved page aren't affected and these are the pages (links), which then lead to the wrong page. I located the piece of code responsible for that functionality and will dig into it during the weekend. Kind regards Steffen - -- Steffen Gebert TYPO3 v4 Core Team Member TYPO3 Server Administration Team Member TYPO3 .... inspiring people to share! Get involved: http://typo3.org I work for TYPO3 solely in my spare time. If you think that my work helps you running your business, you are invited to send me a donation via PayPal to this email address. Thanks On 9/28/12 11:47 AM, Dmitry Dulepov wrote: > Hi! > > Steffen Gebert wrote: >> I guided a bigger client through the update to TYPO3 4.5. Additionally >> few other things were introduced, e.g. Caching Framework activation + a >> hand full of performance-related patches (one of them is a back-ported >> rootline cache from 6.0). >> >> They're now experiencing a nasty behaviour, which did not happen with >> 4.4: >> >> * Page A is created and shown in frontend >> * Page A is renamed to page B >> * A new page called A is created >> * Links to that page lead to the old page A (now B) instead of the new >> one, because the realurl caches are not up to date. > > That's right :) Here is why. > > When you rename page A to page B, RealURL will know and will update all > cached records for page B with path /A to have expiration time. When the > user comes to /A, it will redirect it to /B with 302 HTTP code. This is > made to be Google-friendly (no rude 404s but polite 302s to the new > location). It worked like this for years. > > Now you create a new page A and expect it to be available at /A. But > RealURL has a cache record for path /A, which points to B. Just creating > a new A does not add /A to the cache. Thus, when you navigate to /A > RealURL looks to the cache, finds a record with /A->/B there and redirects. > > What can you do? Go to page B in Web>Info and remove all entries that > say /A for it. That's all. > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQZhhdAAoJEIskG/rSlyw4+cMH/jW/CzKKvp7O/kigAb42EWon C+SsiTGPdxBz3/RUFxwCEd/G/lXphVYN1kYPxFrqgolOPXALFTb8ZShVw3F8DJv1 BhpzLenXaJZf1ZmAx6WSqUDLlZLW04gvmKwoTNXVw4D84Vh4ubJHCTrKBtd4iNYd LnWy7JL4/nW+aXnJGbbEfMf/ibSxSKoqdY2S/8LB5qp+eB8TjzByY72oWJ4npQEv UFnVerVBzVRNk80jTP9uD+M+LrV22zD8ivWzBLP8XH6OlFLqun8j1LTBt6HgzXTK 7U2M6uU6Ea/CjHe+sNG7C8SURSRJlCGUEfnT4QRFY/6KfuNlbYf8iAIFpO3BOI8= =m8cH -----END PGP SIGNATURE----- _______________________________________________ TYPO3-english mailing list [email protected] http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-english
