@gova,
Thank you very much for reporting this bug, that comes between 2.5.10 and 2.5.11 so it’s probably due to the code reformatting. Several other bugs have been introduced that way. My teammate @lolzim has found bugs. Some uninformed changes were made in the process of making the PHP part of the codebase WordPress Coding Standards conformant. Another bug has been introduced by converting a JavaScript function to snake_case while its name was in camelCase and is used in the templates too, that didn’t get synced. I always opposed to wasting time on such low-priority tasks while Footnotes still had bugs, some of which got fixed lastly.
Thanks for drawing our attention on this new bug, that I’ll now be going to try hunting down.
Frankly, working on the WPCS compliant PHP code as it is now—the JS part hasn’t been considered at all, despite WordPress has a coding standard for JavaScript too!!—as opposed to the code as it was before (not so bad after all) is not worth all the hassle. (And I’d never try again to hand the plugin over recklessly.)
I’m sorry that you have been impacted too; thanks for your help in fixing!
@gova,
The bug is fixed in the just released v2.6.5.
It was due to changing two function names from mixed snake-case-camel-case to snake-case only in class/dashboard/wysiwyg-editor.php without syncing the related string in js/wysiwyg-editor.js and templates/dashboard/editor-button.html.
WordPress has a coding standard for PHP that requires snake case, but it has also a coding standard for JS that requires camel case. The former was followed, the latter was ignored when WPCS compliance was forced on Footnotes’ code base.
We apologize to you and all other users who have been impacted by the editor button’s outage.
Thank you very much for reporting!
Need to mention that instead of reverting the change in class/wysiwyg.php (not class/dashboard/wysiwyg-editor.php, sorry please), we should perhaps rather sync the two other files, but we currently try to do the least and IMO we should postpone renaming, reformatting and refactoring until all bugs are fixed and the plugin’s usability is enhanced.
Of course we all are grateful that @rumperuu went to the trouble to increase the Footnotes plugin’s compliance with the WordPress Coding Standards.
Best regards.
@pewgeuges
