Update to 8.12.0 server 500 error #81176

Hello,
When you installed RO CSVI 8.12.0 package did it go without any errors? The fatal errors you posted comes from Google library and was fixed in RO CSVI 8.12.0 version. Since you are seeing these error I am guessing RO CSVI update did not go well.

Hello,
We have added code in RO CSVI 8.12.0 version to copy files into Google library and that did not work in your installation and so the error. To solve this, go to folder administrator/components/com_csvi/assets/google/vendor/psr/log/Psr/Log either copy the content of file LoggerInterface5.php to LoggerInterface.php or rename LoggerInterface.php to LoggerInterface_old.php and LoggerInterface5.php to LoggerInterface.php. That should solve the error. Let me know on how it goes.

Hello,
Did you try the solution posted in my previous reply? Doing a fresh install will not help if needed file is not update with installation so please try to copy the file as suggested and see if the error is solved.

Hello,

but I can see there is no difference in files both are 3.06 kb

Did you check the contents of the file? The end should have a function like this:

    public function log($level, string|\Stringable $message, array $context = array());

If you have that, the error is not coming from this file. In your previous post you only post a screenshot of the error. Can you also post the Stack trace when you get the error? That will tell us where the error originates. You can get the Stack trace by clicking on the tab called Stack trace on the error page.

Hello,
Thank you for the details but it would be nice if you can post us the whole of stack trace. As of now we do not know the source file where the error is coming from. Please send us full stack trace to check.

Hello,

But on some other domain with the same joomla and virtuemart version working OK so I don't know what on this particular instance is wrong.

Are these domains are on same server? There is a possibility that update did not go good even though it says so when RO CSVI is installed second time.

Hello,

So that stack trace is not really a stack trace if it only shows the same error :D Can you post (S)FTP and Joomla login details for me to check what is going on? I am sure it is not that file we spoke about but some other one, just need to figure out which one.

Hello,

With the information we have here it is nearly impossible to say where this goes wrong, that is why I asked for the server login details in my previous post to investigate. This is also due to the magic of autoloaders. It is an abyss :D

Would you like to investigate this further or leave it at this?

Hello,

Since this is a live website, we better investigate this at another time since I am not really available tomorrow. Would it be possible to create a copy of the live website on the same server, for example in a subfolder locked behind an htaccess password? That way the live website does not have to be down or is not immediately affected by it.

Let me know what you think of that idea.

Hello,
There is no access to RO CSVI extension with the login credentials given. There is nothing I can check now. As Roland mentioned, can you create a test site which is replica of live site? That way we are not breaking anything with live site.

Hello,
Yes I am able to access RO CSVI from components menu. So I ran export from one of your Google Merchant template (G Merchant EN) and see 500 error "Unsupported operand types: string * int". We need details on where that 500 error is coming from. I tried to set Error reporting to maximum in the template and unpublished template fields one by one to check if any of the fields is causing the error but anything I do with template gives me a page with 500 error like in attached screenshot. We need complete details on the 500 error so to fix it. FTP access only to plugin folder did not help either. We need access to RO CSVI folders otherwise it is difficult for us to find and fix the issue.

Hello,

Without proper access and debug settings we cannot help you find the root cause of the issue. It is like riding a bicycle with one wheel and being blindfolded.

But Is hard to give you full error reporting since is not in my knowledge how to do this.

You do have the knowledge to lock everything down it seems. The plugins folder is not enough as that is not where RO CSVI runs.

so must be something in files

Sure it is somewhere in the files but in the files on your site because we have no other users with these problems. Since we cannot see anything, there is nothing I can give as feedback.

Unless you are able to give us access I do not see how we can help you with this issue. Until the problem solves itself magically, you can keep using the older version that does work for you.

Hello,

Hope this helps.

This has certainly helped and I have been able to trace back to the actual point the whole thing goes belly up. This happens inside the ElasticGeek ClientBuilder.php file. To be exact, this piece of code:

private function buildLoggers(): void
    {
        if (is_null($this->logger)) {
            $this->logger = new NullLogger();
        }

        if (is_null($this->tracer)) {
            $this->tracer = new NullLogger();
        }
    }

That is also the reason you experience the issue and not any other users as you seem to be the only one using ElasticGeek. The actual NullLogger of ElasticGeek does not match the signature of Joomla nor does the RO CSVI NullLogger match that. You just got lucky that the RO CSVI one breaks otherwise the ElasticGeek would break at some point. For the next release of RO CSVI, I will add some more hardening on this file so it won't break at the RO CSVI point at least.

Now for the error about the operand type int*string, I have traced that back to the convertWeightUnit function of VirtueMart. Specifically this line of code:

$g = (float)(1000 * $value);

This piece of code is triggered by the custom_shipping field of the SKU wine-tasting-slovenia. This product has no weight so you get 1000 * '' which is invalid. Either exclude this product from your Google Merchant file or set a weight so it can calculate the shipping price.

I have not checked if you have more products without a weight, if you do, they may break the export as well. This will also be hardened in the next release.

The FTP connection did not work for me but you can fix the 500 error by editing the file administrator/components/com_csvi/assets/google/vendor/psr/log/Psr/Log/NullLogger.php and change line 26 to:

public function log($level, string|\Stringable $message, array $context = []): void

Save the file and the 500 error should not happen anymore. The other error will happen if there is a product with no weight set.

Let me know how it goes.

Hi,

This can happen as it depends in which order which file is loaded. That is either a lucky website or this one is an unlucky one. :D