Support

Akeeba Backup for Joomla!

#39628 Custom... fields not saved!

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
4.3.4
PHP version
8.2.11
Akeeba Backup version
9.8.0

Latest post by nicholas on Tuesday, 17 October 2023 00:57 CDT

otpfiste

Hi,

 

any value set under:

"Quota management - Obsolete records to keep - Custom..."

or:

"Quota management - Count quota - Custom..."

after saving are not retained. The predefined values from the drop-down are saved correctly.

 

Best Regards,

Oliver

nicholas
Akeeba Staff
Manager

I cannot reproduce your issue. Custom values are saved just fine.

I would normally be asking you if any other settings are saved, but you have said yourself that other predefined values are saved.

Here's why your ticket makes no sense to me. What is actually saved is the number, regardless of whether it's chosen from a drop-down or entered directly in the interface.

The interface is rendered with JavaScript. The code there is really simple. It creates a drop-down with the different predetermined values, and an input box which holds the actual value. When the interface is created it checks the value against the predefined ones. If that's the case, it marks the corresponding drop-down value as selected. Then that happens, the custom value checkbox is hidden.

When you select a predefined value, the JavaScript code updates the value in the custom value box (which is hidden). That is the value which will be saved to the database; the drop-down does not participate, it's just an interface element.

When you select the Custom option in the drop-down, all the JavaScript code does is unhide the input box which holds the value and revert said value to what was selected when you first loaded the page.

This code has been there since December 2009. It's been used on millions of sites over the last 14 years.

If no value, predefined or custom, was saved I could understand the problem: it would be a matter of saving the settings which we can troubleshoot. But a problem where predefined values work and custom values don't does not make sense. It would mean a bug in the JavaScript code which has not changed in years, nobody else has reported, and I cannot reproduce. Therefore, that's an impossibility. I could also suspect a weird network caching issue which would cause the submitted form to always send the same old data, but then you wouldn't be able to save any of the predefined values either. Therefore, that's an impossibility as well.

Are you ABSOLUTELY SURE (please test again, carefully) that you can save predefined values? If you tell me that this definitely happens I cannot really explain what is going on, because we have run out of logical explanations as to what is going on, and right into the territory of someone having tampered with the JavaScript code we use.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

otpfiste

Hi Nicholas,

I'm also a developer and I agree that I must be more precise: it happens with Firefox (not Chrome) on Windows 10 and only if you change the Custom values with the up/down arrow buttons right of the edit boxes. It does not happen if you type the value with the keyboard or if you paste it. I tested it on three completely different homepages, it always happen, so it's not something about hacked/tampered files. For completeness I could also test that on MacOSX, just tell me and I will install Firefox there.

Regards,
Oliver

nicholas
Akeeba Staff
Manager

Okay, that makes far more sense. The edit box (and the value spinner, what you call arrows) are rendered and handled completely by the browser. It is an input box of the type number. The fact that changing the input box' value with the spinner does not update its value, or at least does not trigger the onchange event, is a browser issue we cannot do about.

All we can tell you to do it not use the spinner buttons on Firefox on Windows 10.

Changing our software for a browser and OS combination that's about 0.5% market share, and especially because said browser has a bug? That's not going to happen. It makes no sense removing client-side validation for such a fringe issue that's not even remotely related to anything we do.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!