Resolved Error on import: Failed to start session because headers have already been sent

Hello Roderic,

This is unfortunately not an easy fix because it concerns a 3rd party library. This will be fixed in RO CSVI 10 which will be Joomla 5 and up only. In there all old code will be removed and updated with up-to-date versions and that will also solve these deprecations.

The only way to deal with it now is to set a different error level, if you choose something else than Maximum, at least the deprecations should be filtered out.

Hallo Roland,

So that means, I will not be able to manually upload untill RO CSVI 10? Any ETA?

Yes, I only set the error level to Maximum to be able to see the actual error during this manual import. Having one more option between simple and maximum would be nice, to get rid of the deprecated but a bit more than just simple, as that wasn't enough in this case to get the actual error instead of the dreaded 500.

Fijne avond!

Hi Roderic,

If you get a 500 error, changing the error reporting level will not change that. The error will remain a 500 error, if the server is setup to log these errors, they will appear in the server error log. This is unrelated to the deprecation notices. If you get a 500 error, nothing else will come after that.

RO CSVI 10 will not solve that issue for you.

Failed to start the session because headers have already been sent by

This is often caused by deprecation messages as they will be output before anything else. If you turn off error reporting, is that when you get a 500 error uploading the file manually?

f you turn off error reporting, is that when you get a 500 error uploading the file manually?

Yes, and the serverlog isn't helpfull as well:

500 GET /administrator/components/com_csvi/rantai/rantai.php?task=import&runId=26012&_=1714508538354 HTTP/1.0

Hello Roderic,

That is not the error log but the access log. The access log does not have any information regarding errors except for the HTTP status, which is the 500.

We may have found a way to reproduce your error, we are looking into this. Once we have more info on the issue I will update this ticket.

Hello Roland,

It's a combined log viewer, there are several warnings and errors in there. Just nothing concerning the import, in this specific case.

We may have found a way to reproduce your error, we are looking into this. Once we have more info on the issue I will update this ticket.

Great!

Cheers

Hello Roderic,

So the one issue we found that produces a 500 error is a conflict between the Google and Joomla core due to Joomla not being up-to-date with the PHP standards. So if you use the Google library please do the following:

1. Go to the folder administrator/components/com_csvi/assets/google/
   
2. Delete the vendor folder
   
3. Delete the composer.lock file
   
4. Run composer install
   
5. Check if the import works
   

In case you do not use the Google library at all, you can just follow step 1-3 and the import should be fine as well.

If you do use the Google library and the error still happens, please post your composer.lock file.

Hallo Roland,

There was no vendor folder in the google folder. I also do not use the google library (?). I Still did all the steps, first 1-3 and afterwards also 1-5. No change in error.

Cheers

Hey Roderic,

In that case there is another 500 error. Could you post the website and (S)FTP login details so I can check it on your site as the error log does not specify the actual error?

Hi Roland,

I imported the same csvi templates to another (J5.1) website, then tried to run them but got the same error.
I've now logged-in to another test website that runs on joomla 5, here as well, I get the 500 error on every import. So it seems like a Joomla 5.1 thing.

So this is not the website I had the original error, but you can have a look.

Hey Roderic,

Whilst I was debugging this I realized this is not the first time we have had this issue. No it has nothing to do with Joomla 5.1. The root cause is that when the import starts it loads the plugins. One of the plugins you have installed is the RO CSVI Custom Fields for All plugin. This loads the file plugins/system/customfieldsforallbase/bootstrap.php and that is where it crashes. The bootstrap file tries to load a number of things and that fails. Most likely due to the Joomla compatability plugin not loaded by RO CSVI.

Like I mentioned in the other topic, the reason we run everything through rantai.php is because we do not need the complete CMS to import data. By not loading the complete CMS the import is much faster. We worked hard not to need the compatibility plugin but I guess there is no way around it.

The workaround for now is to disable the RO CSVI Custom Fields for All plugin and the import will complete. We will look into the issue to see if it helps if we load the compatiblity plugin. Of course this is not an option when you actually need it. Being punished for being diligent and follow the new way of coding

Hi Roland,

So ideally, Breakdesigns would optimize their plug-in so it won't need the bootstrap? Or there is functionality in there that it can't do without? Otherwise I'd create a ticket there as well..

Cheers!

Hello again,

So I was thinking, when running the Cronjob, there is no error. So at this point it isn't loading the bootstrap? Then that kinda already answers my question, that it is not needed to load.

Ciao