I have an installation with TYPO3 9LTS where all URls show the start page after the last deployment.
Our system has a deployment in three steps: dev, test, prod.
I have build new features on dev and got it working so I deployed it to the test system (including an update to the latest version 9.5.18 of TYPO3). On the testsystem (which worked nicely before) I can see only the startpage as all URLs (which are calculated correctly) result in showing the startpage.
With ext:realurl I cold inspect the array $_GET to inspect which paramters realurl has decoded.
Where does TYPO3 store the detected page uid and possible other parameters?
Maybe I have some errors in the YAML configuration of the routeEnhancers.
How can I detect errors in the routeEnhancers configuration? (although the same configuration works on the dev system)
EDIT:
As there are multiple answers hinting to uniqueInSite: maybe there are multiple errors, but I have one solution which makes my installation work: I can't use conditions for the domain.
I leave the question open/ unanswered as long as there is no solution to systematicly find an error in URL-resolving.
There might be also problems with the uniqueInSite, but that results normaly in a 404 which is handled separately and which nomaly does not result in the startpage to display.
I've been debugging an error on one of out installations for 5hours today, and this sounds extremely alike, so maybe this gets you on the right way.
After upgrading from 9.5.15 to 9.5.16 suddenly some Links stopped working erratically. ErrorAHndling wasn't set up so the error resulted in redirection to the root page. The generation of the URLs was fine, but resolving didn't work. The RouteEnhancer in question is PersistedAliasMapper, for example, with the following configuration:
-
type: Extbase
extension: News
plugin: Pi1
routes:
-
routePath: '/{news-title}'
_controller: 'News::detail'
_arguments:
news-title: news
defaultController: 'News::detail'
aspects:
news-title:
type: PersistedAliasMapper
tableName: tx_news_domain_model_news
routeFieldName: path_segment
This is the configuration for news, basically copy-pasted from the example. It is used in my case to map globally used entities. This worked perfectly before.
An (afaik) undocumented change as of two months ago introduced this bit of code:
// limit results to be contained in rootPageId of current Site
// (which is defining the route configuration currently being processed)
if ($this->slugUniqueInSite) {
$results = array_values($this->filterContainedInSite($results));
}
The problem is, that this treats all entities with the eval containing uniqueInSite as being limited to the site. My installation uses entities of many domain models on a global page above all sites. These were no longer found.
So, again, not sure if this is the problem for you. But if this doesn't help, you can try to go the same route as I did: Look up the source on github for the Mapper in question and refer to the changes in a certain time frame.
We've got the same problem.
It's caused by [BUGFIX] Respect site for route persisted mappers.
See https://github.com/TYPO3/TYPO3.CMS/commit/2a1bda4f7dd33dfdcd0782afd49924925a623511
We temporary fixed this by changing the TCA config of tt_news:
--- Configuration/TCA/Overrides/tx_news_domain_model_news.php.org 2020-05-27 16:34:07.544603640 +0200
+++ Configuration/TCA/Overrides/tx_news_domain_model_news.php 2020-05-27 16:29:16.763232655 +0200
## -22,7 +22,7 ##
],
],
'fallbackCharacter' => '-',
- 'eval' => 'uniqueInSite',
+ 'eval' => 'uniqueInPid',
'default' => ''
];
}
Check your TCA. You might have 'eval' => 'uniqueInSite' configured.
That will cause a 404 if your model object records are stored outside of the root page where you inserted the plugin.
This happened for me after upgrading from 9.5.15 to 9.5.18.
Check the j4k3's answer for the change in the core.
Setting 'eval' => 'unique' should fix it in that case.
I had the same problem. For me it was caused by havin a forward to https in the htaccess (which worked just fine) but a regular http path in the sites config. The page looked as it should but all pages showed the homepage content while having the correct slug in the address. After changing the site config to https everything worked as should. Stupid me :)
In the migration to version 9.x all pages gets a slug. See: \TYPO3\CMS\Install\Updates\PopulatePageSlugs.
Which page to redirect to is done in: typo3/sysext/core/Classes/Routing/SiteMatcher.php:104
We had this issue today with Typo3 8.7.47 and the reason was that the index.php was somehow statically rendered in the document root. Maybe the webpage got hacked. I don't know.
Adding this solution in case anybody else has struggles with strange typo3 behaviours.
Related
so i was on vacation for 5 Days and when i came back our Website (Typo 3 - 7.6.25) was "broke".
If i try to go on the page i get the following Error:
#1205414233: No suitable request handler found.
TYPO3\CMS\Extbase\Mvc\Exception thrown in file
/html/typo3/typo3_src-7.6.25/typo3/sysext/extbase/Classes/Mvc/RequestHandlerResolver.php in line 83.
Neither me nor anyone else in my company changed something on the Typo3 Website in the past 5 Days.
I've tried to search for Solutions but neither of them helped.
Sadly we have no Backups (This will be Priority 1 after this).
I've also found a Typo3 Website talking about that problem here: https://wiki.typo3.org/Exception/CMS/1205414233
but i dont know where to include the code given by this Site.
Does anyone know what I can do with this Error?
Thanks.
first of all TYPO3 7.6.25 is from 13.03.2018. The last free release is 7.6.32 from 11.12.2018. There are many security updates since your version. If you buy ELTS you can download and install 7.6.41 ELTS (28.01.2020) Maybe this will help with your problem.
Other things you can check: Hosting Provider changes php version or mysql? I really think you should try update to TYPO3 8.7 and test again. Backup your site befor update.
It seems this can have different reasons. In my case (in TYPO3 8.7) the problem was triggered from comments in TypoScript. I've used a (valid!) multi line comment:
plugin.tx_myplugin {
settings {
firstsetting = 1
/*secondsetting = 2
thirdsetting = 3*/
}
}
In the "TypoScript Object Browser" there was a warning, it seems TYPO3 had problems parsing TypoScript due to this comment.
I have just updated my typo3 site from 8.7.29 to 9.5.11 following the official documentation. From technical point of view everything went fine: the upgrade wizard ran successfully in all the required steps and there are no complains from all the available checking tools (database, extensions,...).
The additional problem was that I had to migrate from css_styled_content to fluid_styled_content (because scc_styled_content is not supported anymore by typo3 9). So I modified my old template to work with fluid. After that everything is fine except the fact that all the internal links are not rendered correctly. In particular in the FE all the internal links are reported as:
<a class="internal-link" href="t3://page?uid=246" title="Opens internal link in current window">My link</a>
So obviously typolinks are not parsed correctly.
Some other users reported a similar problem when the extension frontend editing is used. In my case the problem is still there even if this extension is disabled...
Do you have any idea on what is going on?
Thanks a lot for your help!
I built an extension and a plugin where frontend-users can edit their profile but I noticed a critical issue:
Under "Edit profile", users could see the full information about another user who wasn't even logged in. Apparently the form was a cached on the server because after adding:
config.no_cache = 1
it didn't happen again. Now the issue is that indexing is disable on the whole website.
Is there a way to disable caching only for this specific extension / plugin ?
You should have something like this in your ext_localconf.php :
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::configurePlugin(
$_EXTKEY,
'List',
array('User' => 'list,editProfil'),
array('User' => 'editProfil') // Uncached actions
);
Here is where it is explained : https://docs.typo3.org/typo3cms/ExtbaseFluidBook/4-FirstExtension/7-configuring-the-plugin.html
If you want this to only apply on specific pages or be controllable by integrators, you can override the TS rendering instruction for the object:
tt_content.list.20.YOURLISTTYPEHERE = USER_INT
Or if you registered it as a custom CType:
tt_content.YOURCTYPEHERE.20 = USER_INT
The above should work for fluid_styled_content and css_styled_content.
It is almost never advisable to use config.no_cache = 1 since this disables a lot of things other than just caching, as you found out. It also disables all caching for the entire page and it is almost always better for performance to only make the specific plugin not cacheable - and if possible, only do so on pages where the plugin gets used to render views which should not be cached.
Be careful if you do end up needing to cache some parts of your view. It isn't a silver bullet in terms of security, but it is a good start to always include the user's ID (and possibly other things from the authentication as well) in any cache identifiers. And try not to store sensitive information in caches at any point, including code where you output things like the user's name.
I have a strange problem:
TYPO3 7.6 with realul 2.2.1
I got a page with a form. One field of the form gets prefilled via get-parameter (sysid=xxxxx).
The site is multilanguage: german->0, english->1, mapped via prevars '' and en.
When I call the page via www.domain.tld/form-page/?sysid=xxxxx I can fetch the get parameter and fill the field.
When I call the page via www.domain.tld/en/form-page/?sysid=xxxxx I get a 404. That's weired because www.domain.tld/en/form-page/ works without any problems.
I tried several settings (e.g. exclude sysid from chash generation) but nothing worked.
Any hints what I could do?
One additional note: the getvar links are not generated in TYPO3, the are called via barcodes.
I cannot reproduce your problem on the same versions of T3 and realurl.
And I guess (wild guess), it is not a realurl problem, but a TYPO3-core problem.
Could you try calling the page via:
www.domain.tld/index.php?id=XX&L=1&sysid=xxxxx
Furthermore investigate and tell us your settings of
[FE][pageNotFound_handling] and according (installtool/LocalConfiguration).
Nevermind. Error occured because I didn't adjust the realurl-setting for the domain after moving to live. Therefore automatic configuration took place and that didn't work. With manual conf it works.
we are using Typo3 7.6.6 for our new homepage. To simplify the process of writing new articles, we introduced the extension TinyMCE4 as TYPO3 RTE. On our test-system tinyMCE works fine, the editors are satisfied.
To prepare for production environment we introduced SSL. Hence the homepage is referenced over https://....
Since this change tinyMCE no longer appeared. After some research we found out, that the tinyMCE extension tries to load a specific dynamically generated js-file tinymceConfiguration....js over HTTP (not over SSL as preferred).
Since we have a strict policy, the server doesn't allow the client to catch the script without using SSL. Unfortunately we cannot change that policy.
The question is: where does the extension get the URL from. Can I overwrite it to reference the https://.. path?
I already tried changing
config.baseURL
tinyMCE.init({
...
document_base_url : "https://.."
});
But it didn't work.
Does anybody have an idea?
Regards,
Thomas
you could try to tell your browser to use "Content-Security-Policy" in that way all http links are rewriten by the browser itself. Maybe the lazy way.
https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https?hl=en
http://www.html5rocks.com/en/tutorials/security/content-security-policy/
Regards
Pete