Dec 5, 2014

TYPO3 7.0 and RealURL

RealURL is not compatible with TYPO3 7.0 because old compatibility classes were removed in TYPO3 7.0 but RealURL must be compatible with TYPO3 4.5.

I plan to release a new version of RealURL somewhere in March 2015. It will compatible with TYPO3 6.2 and newer TYPO3 versions (not with TYPO3 4.5). That new version will use different principles for building URLs: faster and more reliable. This will be completely new code. Configuration will be compatible with existing version with the exception of redirects: they will not be included into new RealURL because I strongly believe it is not a RealURL functionality and redirects should be done in a different way.

That's all news for now.

19 comments:

  1. Thank you for update. RealURL is one of the most important extensions.

    ReplyDelete
  2. Thank you, Dmitry. Without a doubt - one of extensions which should be ported into core.

    ReplyDelete
    Replies
    1. Why not? Functionally it should. Who's going to really use 7.0 now?

      Delete
    2. Functionally yes, I do think so. Who's going to use 7.0 without RealURL?

      Delete
    3. People who use CoolURI for example. :-)

      Delete
    4. @mathias, cooluri does not work with version 7. if you know a way than please share

      Delete
    5. @mathias, cooluri does not work with version 7. if you know a way than please share

      Delete
  3. How do you intend to handle cHash in new version.
    Because currently you are storing generated cHash values in a "cache" table.

    Problem is when one deletes that table and then calls an URL that requires the cHash directly (without a corrsponding URL being generated first, e.g. from an external page).

    I think it might be a good idea to generate a new value in such a cause (maybe an optional setting).

    Another problem currently is that in case the UID for a speaking path changes (e.g. new article with same title and deleted the old one) then the value in the chash cache table is the cHash for the old UID and this will result in an error.

    ReplyDelete
    Replies
    1. There will be no separate cHash I think. Current RealURL was developed like a burning candle: one layer after another. In the end it is neither fast, nor looking good. I plan to think it well first and only than implement. The will be only two good caches I think.

      Delete
    2. OK.
      As mentioned currently the cHash Table has the suffix cache but one cannot really delete it without running into troubles with pages that require the cHash value and are accessed directly via links (e.g. advertisment links).

      Also one can get a cHash value stored that is not correct because of bypass and so on, e.g. if a link was creaetd for a page with an extbase action but the page itself does not require any parameters.
      Though this is not that often the case.

      Delete
  4. Regarding fixed post vars it might be nice to have a possibility to use those without providing page ids in configuration, e.g. by setting the option for a page in the backend.
    That way one is more flexible then always having to provide the correct page ids.

    ReplyDelete
    Replies
    1. Thanks for the suggestion. It is a good idea!

      Delete
  5. Do you plan to use the caching framework. Database-only caching is a problem for some websites.

    ReplyDelete
    Replies
    1. I have not decided yet but I do not think so. I have to keep many variables that make a cache key (root page id, mount point, language, GETvars, etc). I could use sha1 but it does not make a good hash for fats lookups.

      Delete
    2. At least the decode/encode Cache could be done via the Caching Framework because I believe you only use one key there?

      Delete
  6. Regarding Page-Title Lookup it would be nice if the segments would also ensure to be unique on encode somehow (e.g. by forcing the page to store a unique alias via Datahandler hook).

    Also: If I have a title for a table lookup that is not unique, it might still be unique for the viewing page, so it might be a good idea to add the viewing page to the lookup table (if not unique).

    Also the counter start value to ensure unique should be configurable (because e.g. I would let it start with 2 instead of 1).

    ReplyDelete
  7. One option that would be nice:
    Implicit parameters, e.g. if I have a News ID matching, it would be a good idea to be able to set as implicit parameter the controller name/action.

    valueDefault alone does not really ensure this because that way (in combination with valueMap) I only get a "//nextvalue" instead of "/nextvalue" in the best case on encode.

    If I put it at the end, however, it will not be used because the value is not set at all.

    ReplyDelete
  8. One other thing: The determination of the post variables via the segment, it might be interesting to make this segment language configurable, e.g. news in English, aktuelles in German ...

    ReplyDelete