Upon fiddling with a RealURL config, I noticed that I had unknowingly turned off RealURL caching, as in this old post http://blog.marit.ag/2007/07/24/realurl-pathcache-ausschalten/
As of 2015, are there still reasons to disable RealURL Caches?
Urs, I have no idea why blog's author gave that statement but it's generally wrong. Have no idea what kind of problems they encountered (maybe if they described it, it had some sense), anyway best solution is proper RU configuration instead of disabling the cache.
Keep in mind that general rule in TYPO3 is - cache, as much as possible, as long as possible.
If you'll meet some problems, then you can just clear the RU cache (currently probably by truncating RU's tables in DB, as dedicated ext have some problems with TYPO3 ver. 6.2) and try to fix the configs.
I just checked RU configs in several installations for my own curiosity, to check if is there is somewhere disabled RU cache, result: 0.
No, it is aboslutely bad (I would even say evil) idea to disable realurl caches. Don't do that and never listen to anybody, who tell you to do so.
The option to disable caches was made only for time when you create the site and rename/move pages frequently. In order to prevent cache pollution, it can be disabled. Production systems absolutely must have realurl caches enabled.
Related
We upgraded a TYPO3 installation from 8.7.x to 9.5.19.
Afterwards, the User-Icon dopdown in the top toolbar is missing. (see screenshots)
We found out that the toolbar is generated in this class:
/typo3/sysext/backend/Classes/Backend/ToolbarItems/UserToolbarItem.php
We see that there have been lots of changes here since v7.6 but don't know where to go from there.
Is there a configuration file, where the items in the top bar are noted?
Additional information: we are working with the typo3-themes extension and have worked with our own theme before the update. During the update we switched to the bootstrap4 + bootstrap4-child theme - would this be a starting place for further investigations?
Before upgrade:
After upgrade:
UPDATE: It seems like this was at least not the root of the problems. After reactivating typo3_console the user-icon was still visible. So it looks like we have further investigating to do.
Update (2 Days later):
We can't reproduce the error. My best guess for now is, that deactivating the extension "repaired" a corrupt configuration file which had caused the disappearing of the user settings icon. After a lot of researching i have not found anybody with a similar problem so this might be an edge case. I wish i could offer more insight to this.
Thanks to Peter Kraume's basic suggestions i found the answer: after i deactivated the extension typo3_console it immediately worked!
Just for the record, here are the other steps we tried:
BE (via top bar)
Flush frontend caches
Flush all caches
BE Admin Tools ("Maintenance")
Flush TYPO3 and PHP Cache
Remove Temporary Assets
Logs
BE System log shows no current errors
Shared Hosting, /var/ contains no logs, /logs/ contains ftp and access logs
Hosting Provider Backend
Cleared OPcache
Created a new Admin-User, logged in, same behaviour
Tried on two different PCs
Primarily tested on Firefox 77.01, checked with Chrome 83.0.4103.116
Extensions:
was not sure, which extensions might manipulate the topbar - deactivated typo3-console, because i remembered seeing some error during the upgrade process. My feeling was more like: i don't need this right now, so i could as well deactivate it. 1 second later, the user drop-down reappeared. Unbelievable! Thanks for reminding me of the basic stuff - like turning off things!
We just had the same problem after upgrade from TYPO3 8 to 9. I have compared the working BE-User with the non-working BE user. They differ in given Language. Working BE-User has lang=''. Non-Working BE-User lang='de'. After switching the working BE-User to lang de, too, the UserToolbar is gone. I have updated the languages in Maintenance-Module and now everything works as expected.
Solution for us was to disabling the "belog" extension.
I had the same problem and I could solve it on all systems with:
Install-Tool > Maintenance > Manage Language Packs > Download the files again.
I've a question about the upgrade of Kentico V11 --> V12.
After the correct migration, I got these errors messages (20 times).
When I'll check the website, all design are blank. I just have the menu link without design.
I already re-sign the macro.
I've check all version of CMS.*.dll --> V12.
Do you have any idea for this blocking issue ?
Kind regards !
The error message
did you resign all the macros after the upgrade?
Typically there are a few things which can cause this. First being the hash salt changed in the web.config. If this changed, you need to resign your macros. Even if your hash salt hasn't changed the easiest thing is to go to System > Macros and check both boxes and resign all the macros.
The second thing, highly unlikely, would be you need to clear your browsers cache. Sometimes JS errors arise from the upgrade and cause problems with the system not running code.
What is the entire error message? What is the source URL and where is the code which is throwing the error? Isn't it possible it is coming from some transformation? I am asking since there were some API changes and the GetFileUrlFromAlias method was removed. See the API changes. You may want to use the Code upgrade tool to detect such changes.
I just give you a feedback.
The problem seems to be during the migration...
Due to the VPN low speed, that possible there was some timeout for many steps. (mandatory because the COVID19 =( )
I just get the database on my local computer and redone the migration, and all seems to be good now.
Thank you for your help on this subject :)
Take care of you in this period !
Today, our team once again stumbled upon old bugs being resolved with LATER or REMIND, and it's high likely that we'll forget about them soon again. Both of these non-resolutions tend to get out of sight when mixed into resolved bugs. The Mozilla team itself agreed on removing them [1] for their installation and many other projects have followed since. Using LATER and REMIND is merely a source of confusion.
So also we decided to disable[2] them:
Administration > Field values > Resolution
for both values: unchecked property enabled for bugs
But they don't disappear from the user interface for bugs. Is it broken, have I to delete the values instead? What am I doing wrong?
[1] The discussion has held in 35839 – REMIND and LATER considered harmful to bugzilla.mozilla.org
[2] deleting them seemed not to be appropriate due to the already existing bugs
Now (after having changed the language from German to English for asking here) I tried it again, and the values aren't available any more. I suffered probably only from a caching effect.
I've come across a strange kind of a bug or issue after updating my MODx Revo 2.2.15-pl to MODx Revo 2.3.0-pl
The right side of the admin panel just disappeared after modx revo update
However, if I install a fresh copy of MODX from scratch, this problem doesn't appear at all.
I have updated my site several times before without problems. I always followed the steps described in the official manual Upgrading MODX Revolution 2.x
Maybe someone familiar with this situation can help me find out what's wrong?
Also be careful with .htaccess in root MODx folder, try not change him, in some cases it causes issues. MODX Revo bug.
I find this is generally a symptom due to permissions on the /assets/ directory
make sure the webserver has permission to read/write to /assets/components/ [and /manager/ and /connectors/]
clear cache [always!]
disable js/css compression
make sure that the left panel is not actually collapsed [older versions was difficult to see the little arrow!]
Errors/problems should show up in core/cache/logs/ installation log.
Anyway, probably what has happened here is that you uploaded all your files VIA ftp as the ftp user & the webserver cannot overwrite those files. To make life easier on you, use the advanced install - that way all you have to upload are the /setup/ and /core/ directories [both should be read/write by the webserver as well]
My site eighttwentydesign is running Joomla 3.0. I have SEF URLs on, and have done for sometime without issue. But today when you go to the site, and click on anything, say portfolio you get the home page under the portfolio's URL, but if you add a leading slash at the end, the right article (portfolio) shows. Additionally, if you click on say "Web Design" it sends you to the Portfolio page. I might add this menu is a menu within Joomla - not be adding internal links manually
Doesn't work: http://www.eighttwentydesign.com/portfolio
Does work: http://www.eighttwentydesign.com/portfolio/
I have checked the .htaccess, and actually reverted it to the original with no luck, I have check Global Config but I can't see anything which may cause this. It was working nicely yesterday. I haven't adapted with any PHP source or anything in the past few weeks, the only notifiable thing I have done is yesterday enabling the Cache - have others experienced problems after doing this? I have disabled it under global config, with no avail.
Exact Joomla Version is 3.0.2 with very few plugins
I do have daily backups, but would rather a solution and be able to figure out a prevention from that, rather than just putting on a band aid.
I've search for a good couple of hours, and aside from just not being able to fix it, it appears no one else is experiencing this, so I am starting to think it may be a bug.
Just as I was about to post this I discovered my solution.
If you are having your SEF URLs display the wrong content then solve it by disabling the Cache plugin. You can do this by doing the following steps
Login to Joomla backend
Navigate to Extensions > Plugins
Go to "System Cache"
Disable system cache
I hope this helps someone in the future as I really struggled to find any answers on this.