Unable to Continue Editing Proposal/Invoice After Adding First Line Item

James.Amett · December 16, 2024, 6:30pm

I am currently experiencing an issue in Dolibarr where once I add the first line item to a proposal or invoice, I am unable to continue editing that document. Specifically, after saving or validating the first product/service line, any attempt to add additional lines or modify existing ones is simply not possible. Find attached screenshot.

Has anyone encountered a similar issue, and if so, how did you resolve it? Any guidance on troubleshooting this problem or pointers to relevant configuration/settings that might cause this would be greatly appreciated.

dndwtech4life · December 16, 2024, 6:38pm

I’m having the same issue, will try to re-install the previous version to work for the moment, did the change on Dec 6th and today it won’t work

James.Amett · December 16, 2024, 6:41pm

I noticed it on the version 20.0.0… I thought there would be a fix in v20.0.2 but it seems the issue persists. I have reinstalled my dolibarr twice already and I still face the same issue.

@eldy Can you please comment on this?

James.Amett · December 16, 2024, 7:08pm

@dndwtech4life

i just figured it out… it’s an issue with the PHP Version. I was running on 8.3. I lowered it to 7.3 and it works without issues. You can try other PHP versions.

dndwtech4life · December 16, 2024, 7:23pm

I think i solve mine as well.

The issue I faced was due to the large text I was attempting to enter in the description. Since it doesn’t show a limit, I thought I could use it instead of creating a new product.

eldy · December 17, 2024, 9:18am

No trouble on my side with PHP 8.3 and Dolibarr v20, 20.0.1 or 20.0.2. You probably have something else. May be an external module ?
I recommend to have a look at your apache error.log to get more information.

James.Amett · March 31, 2025, 4:59pm

Hi @eldy, I am using namecheap shared hosting and I have not been able to view any of the logs. I have upgraded to 21.0 and this issue persists.

eldy · March 31, 2025, 5:51pm

I’m afraid without the error.log file of the server, we can’t find any reason as this seems specific to your case.
May be you have installed an external module ?

James.Amett · April 1, 2025, 9:43am

Finally, after enabling error reporting, I was able to locate the issue where PHP 8…x is stricter with sprintf() formatting, and some translation strings contain % without proper format specifiers (e.g., %s , %d ).

Fatal error: Uncaught ValueError: Missing format specifier at end of string in /core/class/translate.class.php:691

So I replaced line 688 - 695 on the translate.class.php with the following.

if (strpos($key, ‘Format’) !== 0) {
try {
// @phan-suppress-next-line PhanPluginPrintfVariableFormatString
$str = sprintf($str, $param1, $param2, $param3, $param4);
} catch (ValueError $e) {
// Handle PHP 8’s strict sprintf errors
if (strpos($e->getMessage(), ‘Missing format specifier’) !== false) {
return $str; // Return unformatted string if formatting fails
}
throw $e; // Re-throw other ValueErrors
} catch (Exception $e) {
// Keep existing exception handling
}
}

Please do let me know if there’s a better way to handle this as it works now and could be incorporated into future changes.

eldy · April 1, 2025, 5:01pm

Which language code do you use ? (xx_XX)

James.Amett · April 1, 2025, 7:35pm

I use php. (Xx_xX)

eldy · April 2, 2025, 2:37pm

Yes but your language code ?
It must be something like xx_XX for example fr_FR for french language, or es_MX for mexican language. You can see the information in the popup on your user name once logged.

James.Amett · April 2, 2025, 2:48pm

Oh you mean the default language? I am english speaking so I have defaulted to en_US.