Typo3 10.4.16
I am not able to create a sitemap.xml with the system extension SEO.
My current understanding is, that the only requirement is, to install SEO and include static template. Than I should be able to see a sitemap with https://yourdomain.com/?type=1533906435. But I always see my start page and not a sitemap.
Under EXT:seo/Resources/Public/CSS/Sitemap.xsl I see a file, but it is 1 month old has nothing to do with my site.
Is there any possibility to trigger seo to generate a new sitemap?
Output from Template -> Template Analyzer:
Or what can I check?
Edit 2021-06-14 10:10
I have moved up the seo static template to to top. No change!
Yes there is a redirect from www.mysite.xyz to www.mysite.xyz/startseite!
When I use a different type, no changes.
This is the a screen shoot from the Object browser:
Edit 2021-06-14 11:00
I am a big step forward. The problem was the redirect, thanks to Richard.
But now I have a problem with the redirect. Even if I include under sites->StticRoutes a new Route with sitemap.xml it is not working together with the redirect.
So the next I tried is the new feature of seo to set xslFile. So I used xslFile = sitemap.xsl and also tried xslFile = /sitemap.xsl but both are not working!
Is it not possible to define a xslFile on the root?
Related
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.
Does anybody have sophisticated knowledge about running a multi-domain-site using a single typo3-instance ?
E.g. I have 2 domains, both being served by the same webserver, using different vhosts. What I want to achieve, is both vhosts pointing to the same document root, where a typo3-instance is installed. This TYPO3-instance should check by typoscript, which domain was used in the request and forward requests for each domain to a specific subpage ("landing page for that domain").
I need this to work in a productional & stable environment, due to custom-self-developed extensions, which provide necessary data for both installations, also specific extbase-domain-models should be usable in both domains etc.
I am already able to check the requested domain via typoscript-conditions. What I am missing, is some info, about how I could possibly realize the redirection, without the client being redirected to the landing page each time while using sub-pages of the landing-page. Do I need to set cookies for this !?
Thanks in advance, Oliver
In TYPO3, you can combine several sites (each with a different domain) in one Installation. This already works out of the box.
So, for this requirement
This TYPO3-instance should check by typoscript, which domain was used in the request and forward requests for each domain to a specific subpage
it is not necessary to add a check for TypoScript, TYPO3 will automatically resolve the URLs.
Page Tree:
pid=0
| --> root page 1
| --> root page 2
On both root pages, enter page properties : "Behaviour" checkmark enable "Use as Root page"
On both root pages, create a TypoScript template, edit it, got to tab "Options", checkmark "Rootlevel". Have this TypoScript template include your general TypoScript configuration, e.g. via "static includes" (ideally you put your TypoScript configuration in an extension)
Since TYPO3 9: configure a site for each page tree under "Site Management > Sites". Before TYPO3 9: On both root pages create a "Domain" record
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.
it is possible to have a direct path to a special news entry?
example:
my link is: http://www.domain.de/start/topnewsdetail/news/really-long-name-of-news-entry.html
and it would be nice to have
http://www.domain.de/newsEntry.html.
Can someone give a hint?
it is a little bit complicated if you want a general automatic solution.
you can do it by hand if you insert pages of type 'external url' where you insert the long path as external url.
with realurl you have problems as realurl at least will use one path segment for the page with the detail view before the last segment which is for identifying the news record. AFAIK coolurl can ommit the path segemnt for the page.
on the other hand: make sure the news identification (title, subtitle?) is unique and does not collide with pathes for normal pages.
at last you can use .htaccess rewrites, but that needs to differentiate between short urls for news and short urls for top-level pages. So those urls will show the page, those urls are not generated inside of TYPO3 and so nowhere used (except manual)
this EXT. adds a custom link to records like system category or news:
https://typo3.org/extensions/repository/view/recordlink
It'S deployed for TYPO3 6.2 but perhabs it'S helpful to create an own EXT.?
Has anyone played with the new redirect feature in Ektron 8.6?
We tested it (in 8.6.0) before upgrading and were happy with it. But when it came time to do the upgrade, Ektron had released 8.6.1, so we upgraded directly to that.
Now we are having trouble with the redirect feature. (Yes, we should have tested everything again in 8.6.1 before upgrading)
Now if we try to add a redirect rule for an existing page in the CMS, it does not work.
But if we create a redirect rule for a page the does not exist, then try to hit that address, the redirect works fine.
We need the redirects to work for existing pages in the CMS.
To clarify what "working" and "not working" means...
If I have an existing page in the CMS with manual alias of "/erc/lucien.apsx", I can create an entry in the redirect table like this...
Adding this entry generates no errors, but when I visit the page, all I see is the regular old page I created. NOT the Google site it should be redirecting to. I do not get any 404 errors.
But if I create a redirect entry for a page that does not already exist, like this...
It works perfectly. If I try to visit the /erc/fake.apsx address, I end up on the Google site, as expected.
(FYI, we create a "fake" page in the CMS for external content so we can attach metadata to it and make it searchable in taxonomies, but then provide a link to the "real" page. I want to use redirects here so users don't have to do this extra click)
I suspect it might be cache related -- the original URL gets cached as an alias, then subsequent requests to that URL are redirected to the quicklink without the need for a db look up. When you add the redirect, it’s probably not clearing the old item from the cache. I'd try an IIS reset after you add the URL redirect and see if that clears up the issue.
An "outside the box" (of Ektron) answer to this is to place the redirect at the web server rather than in the Aliases section of the Ektron CMS.
The server I work on uses IIS and I have this set up for several pages.