When copying a page the slug field is not updated properly - typo3

When I copy a page in TYPO3 10.4.9 and insert it as a subpage of a different page in the same site the slug is not updated properly. It stays the same with a suffix "-1". I would expect the slug to be regenerated based on the new rootline. Anybody who can confirm this behaviour? I would have thought that this bug is already be fixed: Copying a page copies the slug without making it unique?
Example: Page mypage with slug /somepage/mypage is copied and inserted as subpage of page otherpage. The slug of the copied page is set to /somepage/mypage-1. Expected slug value would be /otherpage/mypage.

Use extension sluggi in version >= 2.0.0. to change the default behaviour of TYPO3 10. With this extension installed slugs of pages are updated on copy according to the new rootline.
(There is a bug report addressing the default behaviour of TYPO3 10: Slugs are not maintained reasonable when copying pages/pagetrees)

The described behaviour is correct. URLs are not updated automatically, as it may be desirable to continue using the old URL.
The addition of a number, however, is automatic and is necessary because the URL '/somepage/mypage' now exists twice.

Related

TYPO3 v9.5 no URL Segment [slug] field visible in Page Edit

After upgrading from Typo3v9 to v9.5, I still do not see the URL Segment [slug] field .
The field has been added to the "pages" table under the column/field "slug" and also been populated, but the field is not visible in the BE and the links not updated.
Is there documentation/configuration I am missing?
You need to add a Site Configuration for your page tree in the new Sites module of the TYPO3 backend.
Only then the new slug field becomes visible in backend forms and the URL segments get used in the frontend instead of the old default index.php?id=1 links.

TYPO3 9.5.x URL Segment (slug) ignore page

In the past we organized pages inside the page-tree by putting them into pages like "meta" or "submenu". These pages had the option "exclude from speaking url" so their name was not rendered to the url.
Is there any option to do this in TYPO3 9.5 to ignore pages from generating the "slug"?
as example:
WRONG: https: //www.somedomain.tld/metamenu/terms-and-conditions/
RIGHT: https: //www.somedomain. tld/terms-and-conditions/
How to "ignore" the page "metamenu" for automatic-generating the slug?
Best regards
Johannes
It is mandatory for a page to have set a slug and every menulevel will generate another url part. It is not possible to exclude a page - think about how to access this page via url
Here Mathias Schreiber tells a bit about this feature: Feature Demo - Speaking URLs Part 1
The TYPO3 extension "masi" provides this feature, including an upgrade wizard that migrates the realurl tx_realurl_exclude settings.
Have you tried using a Folder instead of a "Page"?
page/page/page
somedomain.tld/metamenu/terms-and-conditions/
page/folder/page
somedomain.tld/terms-and-conditions/
You can leave the parent-page as it is and edit your child-pages. There you can delete parts of the urls in the slug-field.
There's a feature in RealURL for TYPO3 8.7 "Exclude from speaking URL". If set 'domain.com/page-one/' loads 'page-one' and 'domain.com/subpage-of-page-one/' loads 'subpage-of-page-one' with no need of 'page-one' in the URL.
The very same thing can be achieved in TYPO3 9.5 manually editing slugs but you can't set the parent page to be excluded from the URL automatically.
It's a missing feature.
I had the same Problem. Sadly there is no "good" solution as far as i know. But there is a little trick. You can fix this in the database. I deleted all my "slug"-entries in in the database for my pages. Then i wrote in all pages wich should not show in the url in slug "/". This does sadly not work in TYPO3, because the BE allows just one "/" and the second "/" will be changed to "/1". But in the Database you can do it. After you edited the slug for your page metamenu and other to "/", you can go into the upgrade-wizard in the installtools, reset the "generate slugs" task and run this task again. This is sadly the only solution i came up with.

Why do I get an 404 Error after using TYPO3 V9.5

I am using TYPO3 9.5 and I created a root page with several subpages.
Before I created a site configuration the subpages were available as
/index.php?id=19
after the site configuration the url has changed to
/events
which is absolutely fine but my subpage cannot be found anymore. I get an 404 Error.
The subpage is still available under the old url but the new one doesn't work.
What can I do to fix this?
after changing the slug(path/path segment) for a page you need to update the slugs for all subpages manually.
The slug is generated automatically when the page is created. Probably your slugs were generated wrong before you build your site configuration.
Try to autogenerate all the slugs with the adapted wizard. You must do it by hand for each page as there is no wizard for page subtrees (yet). you might do the multi-edit in the list module for the slug field.
I have similar issue and no clue how to solve. See TYPO3 9.5 URL Routing with URL Segment is not working
Manual slug override, saving, chache clearance etc. does not help.
Are you using as well Apache? Maybe the issue is related to the webserver.

news: wrong link to detail page, ok after clearing fe cache

I use tx_news 4.3.0 with TYPO3 7.6.12 and realurl 2.0.15
From time to time i get detail links which show to a wrong detail page.
e.g.
veranstaltungen/talks/detail/xy-talks/
shows to another detail page:
veranstaltungen/talks/detail/z-talks/
after clearing the fe cache the link ist ok.
how to avoid this?
I got the same problem some time ago.
I use for many TYPO3 system a single page for news list and detail.
I wanted to have URLs like example.com/news/ für list view and example.com/news/this-is-a-news/ as detail URL.
To archive this, I configured realurl to skip controller and action for news links. But in the link configuration inside the news template, they were used to build the link.
Since realurl does not create a new cHash for a link (since Version 2.0.12 I think), the link generated by realurl does not match the cHash that was generated in TYPO3 and cached by realurl. So TYPO3 provides a wrong cached version of this page. I my case, it was the first news entry, that were called and cached. This news entry got displayed every time I clicked on a news.
To avoid this, I removed the controller and action skipping from realurl and add some TypoScript (link.skipControllerAndAction = 1) to my news configuration.
I think you might have a similar issue. Try to disable realurl in a dev environment and try if this happens again. When this fixes your problem, check your realurl configuration for news.

Get the timestamp of last modification of TYPO3 page, difference between tstamp and SYS_LASTCHANGED

What is the right way to get the date of last modification of a TYPO3 page (and its *tt_content*) ?
There are 2 fields in properties of table pages : tstamp and SYS_LASTCHANGED.
In this article SYS_LASTCHANGED are recommended. But what is the role of tstamp in this case ?
Which one should we use ?
tstamp is modification time of the page record itself. SYS_LASTCHANGED is the modification time of the page OR its content. It's updated once the page is rendered in the frontend, not right after the change in the backend. However, thanks to this it also includes changes of content records residing on a different page and inserted into the given page using "Insert Records" content elements.
Note: Tested in TYPO3 4.5 LTS and might not work in later versions.
tstamp is the date and time of the last change of the data stored in the pages table. It gets updated only when the page properties are changed, not the content of the page.
SYS_LASTCHANGED is often called as the real last update of the page including its contents but that seems not to be true at all and is not trustworthy. I can't tell what exactly triggers it's change but it seems to be related to the pages rendering. Even more strange is that it could be 0 on already rendered pages. My advice is to never rely on SYS_LASTCHANGED.
Our way to get the last change of a page displayed is currently as follows:
We added <time date-current="{data.tstamp}"><time> to our custom Contents/Partials/Header/All.html (you need to overwrite the fluid-styled-content-elements) and to our page template. Then a java script does the job to find out the latest change and inserts the html to the page, displaying the last change.
The field SYS_LASTCHANGED is only updated in the frontend once the page has been rendered.
Check lastmod in sitemap
Edit content element on page
Call page in frontend
Check sitemap again