Typo3 8.7: Could not analyse class: maybe not loaded or no autoloader? Keeps coming and going - typo3

I have had this problem as seen in the title in the past and I always resolved this issue by adding the psr-4 autoloader in the emconf and simply reactivate my extensions.
Now I'm facing the same problem:
Could not analyse class: maybe not loaded or no autoloader?
but I have set the autoloader correctly as always. This also happens in more than one Extension right now.. After deleting the php cache in the install tool und dump autoload and reactivating my extension, the error was gone for some time, a couple hours later its back again.. Therefore I think it must have something to do with temp files, but I can't figure out what it is exactly..
Does anyone have a solution? I have seen plenty of topics about this issue on stackoverflow, I used them in the past, but unfortunately none is working for me right now.
Important fact: This error is happening on my new server now. On my old server (with the same code in the extensions) this didn't occur and they worked fine.
Thanks in advance.
Edit: Vendornames etc. are set correctly and there are no errors in the syntax whatsoever. As I said, the extensions worked fine.
Edit2: I just found this changelog of Typo3:
https://docs.typo3.org/typo3cms/extensions/core/Changelog/8.4/Breaking-78222-ExtensionAutoloadInformationIsNowInTypo3confautoload.html
But there is no solution for the impact for none composer installations. Can someone provide one for me?

When you use composer installation and you use extensions which are not installed via composer, you need to add the autoload information in the root composer.json of your project and then run composer dump-autoload. (ext_emconf.php dont works in composer mode?)
{
...
"autoload": {
"psr-4": {
"Vendor\\ExtensionNameA\\": "public/typo3conf/ext/extension_name_a/Classes",
"Vendor\\ExtensionNameB\\": "public/typo3conf/ext/extension_name_b/Classes"
}
}
}
A possible explanation for strange timing thing "works and later not". Maybe it has something to do with the red clear cache button in the TYPO3 backend (Clear all caches). Maybe it start not working when u hit this button and cache files get cleared. Then you need to reinstall extensions to get the autoloader "temporarly" working, till the point you hit the clear all caches button again. With the solution i mentioned above, it works permanet.

Have you left any configuration in your ext_tables.php?
As the TCA configuration, which is cached, is expected in Configuration/TCA/[Override/] any code in ext_tables.php might get lost.
If you want some configuration to be executed for each run you need to put it in ext_localconf.php

Thanks for all the help, I found the solution myself now.
Actually it was not really caused by any autoloader configuration, but and old version of fpdf which apparently caused two extensions to not load their classes properly. The exception thrown was simply misleading. I have upgraded the version of fpdf and now it works properly. It is not clear to me why the same code worked a week ago and now it failed, but atleast I have found the solution to my problem.

Related

TYPO3: Backend Toolbar User-Settings gone after Update to TYPO3 v9.5.19 from v8.7

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.

Typo3 plugin not working in draft-workspace

I have a selfmade T3-plugin that actually works fine.
Unless I try to look at it in the draft-workspace - then I get an error saying «Template could not be found at "typo3/sysext/workspaces/Resources/Private/Templates/Preview/Preview.html"» (of course, the template is there).
We're working with T3 6.1.8
There were some rollbacks made recently that might have caused this, but that's just a wild guess...
Any ideas what could cause this?
The solution to this was actually quite trivial.
The person who wrote the extension used chdir() in the extension's header to write a PDF file. This confused the workspaces plugin so it didn't find it's own directory anymore.

Accidentally published CompositeC1 with precompile on

I accidentally published Composite C1 from Visual Studio with "Precompile during publishing" when I first set it up and have now come to realize that several plugins do not work with precompile turned on. Unfortunately I have no idea how to reverse this. I've tried several things to no avail. I usually end up with a 500.0 error. If I go to the admin interface everything is working properly, and I can even preview the pages, but from the customer side all I get is a 500.0 error.
Of course I could republish from the Visual Studio project I have, but that project has the default template on it. I've tried copying what appears to be changed on the server to the original project but I end up with a 500 error. I've tried removing all the precompiled stuff on the server but I end up with a 500 error. I'm pretty lost.
At this point I'm willing to do anything. Is there a doc explaining how to copy the content to a newly downloaded copy, kind of like an upgrade doc but "side-grading"? I am using the most current version at the time of writing this 4.2 Update 1
Thank you
Solved use the PackageCreator suggested by wysocki's answer. It was not exactly straight forward to create the package. The errors can very cryptic at times. So here are some of the issues I encountered and how I got past them:
wysocki was correct to suggesting starting with a bare bones installation even though my original project was started with the Venus theme. I tried both ways.
I encountered issues with the MasterLayout and the Page Template Features which are currently not supported by the PackageCreator, although they may be supported in future versions. The solution was to add the missing elements to the fresh C1 project from the original C1 installation in the App_Data/PageTemplates and App_Data/PageTemplateFeatures folders.
A few times I ran into an issue where I added the same page or function twice to the PackageCreator. This was obviously my fault, but it should be mentioned that you can add the same site element twice which throws and error on import. Make sure you are careful to only getting one of each when creating the package to be exported.
If you are getting and error and it uses and Id like "4061397b-ee9e-4512-984d-f2b2d41eb654" I've found that it was very helpful to extract the zip file you are trying to import and then search the extracted folders for that Id. The lines with the Id usually have more information on them that will help you to identify exactly what content page or whatever the error is being generated from.
If you are using installed packages in your project like SimpleSearch for example, make sure you don't add it's functions to the PackageCreator. Install them separately.
I had an issue where I somehow had an element in the Data section that didn't have a "type". The error simply "The type cannot be empty". This was obviously tough to find so I suppose the lesson is, less is more. If you think your project might have a few elements that are unnecessary, don't add them at first and see if the project you import them into complains about missing them. It's much easier to troubleshoot missing elements than it is to figure out which element is causing the issue that you really didn't need.
Is there a doc explaining how to copy the content to a newly downloaded copy
You can try and export content / templates / anything else related to a "package" via Composite.Tools.PackageCreator.
Its latest version gives you quite a lot of flexibility in what you can export ("package") - please its user manual.
Once the package is made and downloaded, you can go on and install it on a new website. If you export / import a lot of content / templates etc, it makes sense to have a "Bare Bones" site as the new one.
All the starter sites like "Neptune", "Venus" are installed as a bunch of packages in specific order during Composite C1's initial setup.

guard-livereload stopped working

Since merging in my co-worker's changes this morning, guard-livereload has stopped working. The javascript is being injected into the page, and guard does detect my browser, but no matter what files I modify, it simply does not reload whatsoever.
Here is my console output today, with livereload not working. Note that there is just zero output after detecting the browser - unlike other questions on stackoverflow, where livereload claims to be reloading but does not do anything. Here is my console output from the last time I was at work, when it did function correctly. The annoying thing is that ui.css.scss is the file I'm modifying now as well! My guardfile has not changed, I've checked.
Here is my bundle install output from this morning (my co-worker updated a bunch of gems). I'm using rack-livereload in lieu of a browser extension.
Any advice?
UPDATE: I've tried using the Livereload Chrome extension, but I get exactly the same (lack of) output, so I don't believe rack-livereload to be the culprit.
Found the solution, in part thanks to this.
It turns out Sublime Text 3's atomic save feature is what was preventing LiveReload from detecting changes to Sass files. Why it worked before a certain commit is beyond me...
Simply add "atomic_save": false to your Sublime settings to avert this.
Just to add an alternative solution - for me this was because I'd upgraded to rails 4.2 and changed my asset file names from .css.scss to .scss as per the recommendation in the logs.
Of course, when I checked my Guardfile I was still watching for .css files:
... (css|js|html|png|jpg) ... { |m| "/assets/#{m[3]}" }
A simple change from watching for css to scss like so:
... (scss|js|html|png|jpg) ... { |m| "/assets/#{m[3]}" }
and all fixed!

firebreath plugin refresh after update

I want to reload a plugin after update without restarting browser. I tried the mac version, it works fine, howeve, I need to change the plugin name for each version.
navigator.plugins.refresh(false);
http://www.firebreath.org/display/documentation/Deploying+and+updating+your+plugin?focusedCommentId=8585308#comment-8585308
In windows, I tried those steps and I couldn't make it work. Has anyone had any luck with this? Does anyone know what could be wrong?
"On Windows you even need to install it to a version-specific directory with a version-specific filename. Once the plugin is installed, you can try the following to reload the plugin in open browsers
<script>
var myplugin = "<object id=\"plugin\" type=\"application/x-foobar\"> </object>";
function onload(){ // Assuming this function put your plugin on the page in the first place
document.getElementById('pluginHere').innerHTML = myplugin;
}
function reload(){
document.getElementById('pluginHere').innerHTML = "";
document.getElementById('pluginHere').innerHTML = myplugin;
}
</script>
thanks alot.
This is a difficult trick that can go wrong in a lot of different ways. It's difficult for me to guess what might be going wrong specifically, particularly since you said "on windows", but you haven't specified what browser that is. All of the browsers work differently in subtle ways and IE and the others are completely different as far as this goes.
Things you could try:
use setTimeout to add a small delay between removing the plugin from the DOM and re-adding it
open about:plugins and then shift-refresh to see if it picks up the new version
Try different browsers and see what the behavior is
Use Process Monitor to monitor the queries of the registry and see when the registry keys are being accessed; use this to help plan your strategy.
Anyway, I hope some of that helps; I used to upgrade that way but it was too error prone and too prone to things changing with new browsers, so these days I just make the client restart their browser on upgrades. It saves a lot of hassle and lots of development time.
I use a signed CAB with MSI inside to load the plugin on internet explorer.
On the first time install I found that the plugin can be accessed from Javascript but events were not working.
When I looked at loaded plugins, the plugin was not loaded.
If I refreshed the page the plugin is loaded.
my solution was to add the following code from this stack overflow question
One time page refresh after first page load
This worked like a charm.