Rumperuu

Great stuff @pewgeuges, and glad to hear things are working again @kristencahill!

Sounds like the conflict is definitely between footnotes and Accordions, then.

The next step is to identify which version of footnotes introduced the issue. Previous versions of the Plugin can be downloaded here, or an archive of all of them is available here. Just replace the files in the wp-content/plugins/footnotes/ directory (on a development site, ideally).

I’d suggest starting with 1.0.0 to rule out the possibility that the issue happens in all versions, and then using a binary search from there.

Hi @kristencahill,

Are you using a premium version of PickPlugins Accordion? If so, we will be unable to test the issue on our end; please contact PickPlugins support. If they are able to identify what the problem is, and that the bug is in this Plugin, they or you can provide further details either here or in a bug report on the project development repo and we’ll look into it.

However, if you are using a free version of the Accordion that we will be able to experiment with, could you please provide more information about the version of both that and this Plugin that you are using? If you know exactly when the issue started to happen that would be great, but even a rough narrowing-down would be helpful.

Seconding what @pewgeuges has said; the missing images are not caused by the footnotes Plugin.

Images are properly rendered in the blog posts on the site you have linked as the sources are correctly set to https://brightonlives.org.uk/<path to image file>. The missing images on the homepage have the source set to https://box5348.temp.domains/~rightop7/<path to image file> instead (perhaps a leftover from some sort of development server?)

You can view the paths associated with each image by going into your WordPress dashboard and going to Media > Library and clicking on the missing file; the file URL will be in the box on the top-right, along with the ‘Update’ button etc. If the URLs are incorrectly pointing at this https://box5348.temp.domains/ location, you will have to go into the posts themselves and re-upload the Featured Images, which should then use the correct path (https://brightonlives.org.uk/) automatically.

This may be helpful too: https://www.bluehost.com/help/article/using-your-temporary-url-with-wordpress

Re: the browser warnings when visiting https://box5348.temp.domains, this just means that there is no SSL certificate available.

Marking as resolved as not caused by footnotes.

• This reply was modified 5 years, 3 months ago by Rumperuu. Reason: Added comment about 'unsafe site' warnings

As this was a serious issue, I have conducted a full post-mortem. A full technical breakdown of what happened is available on the GitHub repo. Issue for this incident here; this is an abridged general-purpose summary.

Issue

As part of refactoring the codebase to comply with the WordPress Coding Standards (the first step in a wider project of migration and workflow automation), the following file and directory renames were made:

• class/dashboard/ → class/layout/;
• class/dashboard/layout.php → class/layout/abstract-engine.php;
• class/dashboard/subpage-diagnostics.php → class/layout/diagnostics.php; and
• class/dashboard/subpage-main.php → class/layout/settings.php.

To account for these relocations, the penultimate line of includes.php was changed from mci_footnotes_require_php_files( dirname( __FILE__ ) . '/class/dashboard' ); to mci_footnotes_require_php_files( dirname( __FILE__ ) . '/class/layout' ); to ensure that the new files were found.

In the v2.5.9d1 commit to trunk/, the updated includes.php was included (see here), but the class/dashboard/ → class/layout/ directory rename was not (see here).

includes.php tried to find files in a non-existent directory, couldn’t, and threw a fatal error.

What Happened

1. I did not realise that the steps given in the WP Plugin Handbook for updating the SVN repo. were only for ‘Editing Existing Files’. class/layout/ was present in my local copy of trunk/, but as the new class/layout/ directory was not yet added to tracking (i.e., through svn add), it was not included in the svn stat or the commit, whilst the updated version of includes.php (which pointed to it instead of class/dashboard/) was;
2. I did not notice this in my test environment because copying the files from my local copy of trunk/ meant that I included my local (but un-committed) copy of class/layout/;
3. as the codebase standardisation changeset covered 45 files, the commit diff filelist was too long for anyone to notice that the class/layout/ directory was missing;
4. this would have been noticed as soon as anyone else pulled the remote trunk/ to their local copy and tested it; but
5. the code in trunk/ was taken by the WP Plugin Directory to be a new release (2.5.9d1):

• per the WP Plugin Handbook (see here), the Directory parses the ‘Stable Tag’ field in trunk/readme.txt first and, if the value is set to something other than ‘trunk’, will look in tags/⟨stable_tag⟩;
• again per the Handbook, ‘If there is no folder for the Stable Tag, then WordPress will default to using the trunk folder’s content’;
• so the Directory parsed trunk/readme.txt, read in the ‘Stable Tag’ of 2.5.9d1, looked for tags/2.5.9d1, couldn’t find it and so pushed the contents of trunk/ our as a new release 2.5.9d1.

What Went Wrong

1. I was unaware that the WP Plugin Directory parsed trunk/readme.txt rather than looking at the latest version release in tags/ — I thought that it was safe to put pre-release code in trunk/, and that the version numbers (two in footnotes.php and one in readme.txt) should be updated to reflect the current version (in this case 2.5.9d1), whereas in fact the ‘Stable Tag’ should remain the latest release version (see example 2.5.6d4 release with 2.5.5 version number here);
2. @pewgeuges did not know that I was not aware of this (see here);
3. unfamiliarity with SVN led to me failing to commit new, untracked files (i.e., class/layout/) whilst correctly committing the edited tracked files that referred to them (i.e., includes.php);
4. my own manual testing failed to detect this due to copying local files into the test environment rather than pulling files from the remote repo; but
5. as the Directory pushed a new release automatically, there was no time for anybody else to test the changes and notice the error; and
6. as the 2.5.9d1 release was quickly followed up with 2.5.10, I did not receive an email notification about my own site upgrading to footnotes 2.5.9d1 and realise that there was a problem earlier; and, finally
7. as I am unavailable this week due to work commitments I have set up an inbox filter automatically moving forum post emails out of inbox, so I was not aware of the flood of forum bug reports.

Impact Assessment

This was entirely my mistake due a misunderstanding of how the SVN repo. behaved. It was swiftly fixed by @pewgeuges, but had a significant impact on users (as evidenced by the number of Support Forum posts). The damage appears to be limited to users who have enabled automatic Plugin updates, although as ~50% of the userbase are using the most recent Plugin version, we can infer that potentially as many as 50% of users have enabled this (though the real figure is likely to be smaller). Thankfully, many of those same users will have automatically upgraded to 2.5.10, but some may have disabled automatic updates whilst the Plugin was broken. Hopefully, they will soon see @markcheret’s pinned post above and upgrade.

Mitigations

1. Do not update the ‘Stable Tag’ field in trunk/readme.txt for development versions to ensure that committing broken code to trunk/ will not accidentally trigger a release;
2. add release instructions for future contributors (see here) to ensure that the same mistakes are not made by others;
3. ensure that commits are kept small to increase the likelihood of errors being spotted (see here);
4. set up an automated release workflow (see here) in order to completely remove the risk of human error.

Thank you for reading, and my sincere apologies to anyone inconvenienced by this issue,
Ben

• This reply was modified 5 years, 3 months ago by Rumperuu. Reason: Fix nested list
• This reply was modified 5 years, 3 months ago by Rumperuu.
• This reply was modified 5 years, 3 months ago by Jan Dembowski.