[Assegnato] Fatal Error when saving a product: Array callback must have exactly two elements in Post.php

Hello Jemal,

Thanks for reaching out to WPML Support. I'm Prosenjit from the WPML Development Team, and I'll be happy to help you with this issue.

I understand the problem and appreciate you providing such detailed information — it's very helpful for the investigation.

Since you have a custom setup for updating products via API, I've conducted a preliminary code review based on the stack trace and the specific line where the error occurs. Here's what I found:

At the line where the fatal error is triggered, the code is trying to call `$translationsLanguages` as a function using `$translationsLanguages($translationID)`. However, according to the method signature, `$translationsLanguages` is actually defined as an array parameter (`array<int, string> $translationsLanguages`), not a callable function.

PHP 8.3 has stricter validation for array callbacks. When PHP encounters `$translationsLanguages($translationID)`, it interprets this as an attempt to use an array as a callback function. Since the array doesn't have exactly two elements in the expected callback format, it triggers the fatal error: "Array callback must have exactly two elements."

Based on this preliminary investigation, the issue appears to be in how the code is calling this parameter. Given the method signature, could you please try updating the code as shown below and see if it resolves the issue?

- Go to /wp-content/plugins/woocommerce-multilingual/classes/Synchronization/Component/, open Post.php and scroll to the line 69
- Replace the entire line with the following code:

$translationLanguage = $translationsLanguages[ $translationID ];

Important: Please make sure to take a full backup of your site before making any code changes.

Please test the code update and let me know the results:

- If the fix works: I'll escalate this internally and work to include the fix in the next WPML update so it's available for everyone.

- If the issue persists: Please reach out, and I'll be happy to conduct a deeper investigation. Given the complexity of your custom API setup, there may be additional factors at play that we'll need to examine more closely.

Either way, I'm here to help ensure this gets fully resolved for you.

Looking forward to hearing how it goes!

Best regards,
Prosenjit

Hi!

Thank you for checking and getting back to me.

I've just verified the same version you're using (5.5.3.1), and I can confirm that the folder structure does exist in that version. Additionally, since the stack trace explicitly shows this file path and filename in the error message, the file must be present in your installation — the error couldn't reference it otherwise.

Could you please access your site's file system using either FTP or your hosting control panel's File Manager and then check again?

Path: `wp-content/plugins/woocommerce-multilingual/classes/Synchronization/Component/`
File: `Post.php`

If you find that the file is indeed missing, I'd recommend:
1. Taking a complete backup of your site first
2. Deactivating and deleting the WooCommerce Multilingual plugin
3. Reinstalling it fresh from your WPML account

However, before we proceed with any of these steps, please let me know what you find when you check the file system. This will help us determine the best course of action.

Let me know, please! I'm here to guide you through each step if needed!

Best regards,
Prosenjit

Hi!

Thank you for trying the solution I provided. I appreciate you taking the time to test it and reporting back.

Since the issue persists even after the code adjustment, this indicates we need to investigate more deeply to identify and address the root cause properly.

You mentioned that this error occurs specifically when an external plugin updates a custom field via API. To provide you with the most effective solution, I need to understand exactly how this process works, as I'm not familiar with the specific external plugin you're using.

To replicate the issue accurately and identify the root cause, I'll need:

1. Access to your site - This will allow me to:
- Examine the complete setup and configuration
- Review the exact code execution flow when the error occurs
- Test different scenarios safely
- Implement and verify a proper fix

2. Understanding the workflow - If possible, could you provide:
- A brief explanation of how the external plugin works/procedure
- Which specific API endpoint or method does it use?
- Ideally, a short screen recording showing the process that triggers the error

Having this context will enable me to replicate the exact scenario and see firsthand what's happening, which is crucial for working on a reliable, permanent solution.

I've enabled the private fields below so you can securely share your site credentials with me. Please be assured that:

- Your access information is 100% secure and encrypted
- Only authorized WPML support staff can view these credentials
- We handle all access information with the highest level of confidentiality
- Access will be removed once the issue is resolved

I'm personally committed to getting this resolved for you. Once I have access and understand the complete workflow, I'll be able to provide a targeted, permanent fix rather than a workaround.

Please share the access details when you're ready, and if you have any questions or concerns before doing so, don't hesitate to ask.

Looking forward to resolving this for you!

Best regards,
Prosenjit
WPML Development Team

Hi again,

I wanted to follow up with an important update based on my investigation.

Shortly after my previous message, I continued my investigation using the FTP access you provided. I examined your site's debug log and found something important:

The original fatal error you reported in this ticket was last logged on January 7th. I don't see any instances of that specific error occurring after that date.

1. After updating the code I provided, have you triggered the custom field update via the external plugin's API?

2. If you've encountered a fatal error since then, is it the same error you originally reported in this ticket, or is it a different one?

To try to replicate the issue, I went to WooCommerce → Sirio WooSync, selected a product, and clicked the "Start Sync" button. This did trigger a fatal error, but when I checked the debug log, I found:

- The error is different from the original one you reported
- It's not originating from the WooCommerce Multilingual plugin

Could you please verify:

1. Whether the replication process I followed (using Sirio WooSync → Start Sync) is the correct way to trigger the error you're experiencing
2. If you're still encountering the original fatal error, or if it's a different error now
3. When you last saw the error occur (date and time, if possible)

It's possible that:
- The code fix I provided may have already resolved the original issue
- You might be experiencing a different error that needs separate attention
- We need to use a different method to trigger the original error for testing

Understanding exactly which error you're currently facing will help me provide you with the most accurate solution.

Please let me know these details, and I'll continue investigating to ensure everything is working correctly for you.

Looking forward to your confirmation!

Best regards,
Prosenjit

Hi,

Thank you so much for confirming that and for taking the time to investigate the logs on your end as well!

I'm glad we were able to confirm that the original fatal error you reported in this ticket has been resolved. The code fix I provided appears to have successfully addressed that specific issue with the WooCommerce Multilingual plugin.

You're absolutely right in your analysis — the current error is originating from the Sirio WooSync plugin itself. This is definitely something the Sirio developers will need to address in their code, as it's a bug in how their plugin handles cases where a product object might not exist or be available.

I'm more than happy to keep this ticket open for a few days as you suggested. If the Sirio developers indicate that the issue is related to a WPML hook returning `false` or any other WPML-related behavior, please don't hesitate to reach out. I'll be here and ready to investigate further from our side if needed.

I'll monitor this ticket, so if anything comes up or if the Sirio team points to something on the WPML side, just update this ticket and I'll jump right back in to assist you.

Thank you for your patience throughout this investigation.

Best regards,
Prosenjit