Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. Create a pull request

Expected behavior
No errors

Additional context
PHP Composer check output
- phpdocumentor/flyfinder 1.0.0 requires php ^7.2 -> your php version (8.0.3) does not satisfy that requirement.
- phpdocumentor/phpdocumentor v3.0.0 requires phpdocumentor/flyfinder ^1.0 -> satisfiable by phpdocumentor/flyfinder[1.0.0].
- phpdocumentor/phpdocumentor is locked to version v3.0.0 and an update of this package was not requested.

Extended by #97

Describe the bug
When Post excerpts are displayed, the footnotes icons are still being rendered.

To Reproduce
Steps to reproduce the behavior:

1. Load a Theme that displays Post excerpts
2. Create a test post with footnotes in the first few lines
3. View the excerpt

Expected behavior
Footnote tags should be hidden in Post excerpts.

Screenshots
https://imgur.com/a/eIo9EYI

Desktop (please complete the following information):

• Plugin: 2.5.6

Additional context

• I think this came up in a WP Support Forum thread before, but I can't find it now

wp_register_style() can take an optional fourth argument that will override the use of the current WordPress version number as a URL query param appended to each CSS stylesheet , so that browsers will be forced to download new stylesheets rather that using cached old versions.

You can use whatever you want as the fourth argument. Currently (i.e., on the SVN repo.) a constant string named C_STR_PACKAGE_VERSION is used, representing the current package (development) version number.

A superior approach is to use filemtime() to get the last-modified time of each stylesheet file. This means that, even if a file is modified multiple times during a single version, the cache-busting will still work. This also means we do not have to manually update the string constant, and there is no chance of anyone forgetting to do so.

This change has already been made to the GitHub repo. in a66faae#commitcomment-49511226 — it has not yet been propagated to the SVN repo.

As far as I can tell, there is no compelling reason to prefer the use of the manually-updated package version string constant. If anyone disagrees, please explain why below.

https://github.com/10up/action-wordpress-plugin-deploy

@‌arahmanshaalan reported that there may be a need to easily reset all settings to their default values.

The plugin is lacking the Reset button. It included a reset function run at uninstall, but I disabled this because the setting letting the user decide whether or not they wanted the settings to be cleared is missing too.

The plugin should include this feature (considered a bugfix) in the next release or as soon as we can manage to add it.

Currently, this Plugin is made of 145 files. I ran SLOCCount on it, and got the following results:

SLOC	Directory	SLOC-by-Language (Sorted)
3843	class	php=3843
406	js	javascript=406
219	_tools	sh=219
50	contrib	sh=50
28	top_dir	php=21,xml=7
0	css	(none)
0	img	(none)
0	languages	(none)
0	templates	(none)

Totals grouped by language (dominant language first):
php: 3864 (85.00%)
javascript: 406 (8.93%)
sh: 269 (5.92%)
xml: 7 (0.15%)

Total Physical Source Lines of Code (SLOC) = 4,546
Development Effort Estimate, Person-Years (Person-Months) = 0.98 (11.77)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC1.05))
Schedule Estimate, Years (Months) = 0.53 (6.38)
(Basic COCOMO model, Months = 2.5 * (person-months0.38))
Estimated Average Number of Developers (Effort/Schedule) = 1.84
Total Estimated Cost to Develop = $ 132,481
(average salary = $56,286/year, overhead = 2.40).

This feels substantially larger than should be necessary for a Plugin with as tightly-defined a scope as this one. I suspect that there is a significant amount of unnecessary or outdated code, that would be well worth refactoring out.

Because this will be useful for tackling other issues too, I intend to run over the codebase and produce an 'architectural overview' (which I'll add to the repo. Wiki), which should a) help me and everyone else grasp just what everything does and why and b) help identify duplicated and unnecessary functionality, things that can be consolidated, things that can be separated (i.e., no more inline JS in PHP files), etc.

After adding hard links in 2.3.0 (2020-12-31), Footnotes is now enabled to become fully AMP compatible thanks to @milindmore22 code contribution and @westonruter code contribution. This release is now fast-tracked and shall be followed by submission to AMP PROJECT / WordPress for testing.

[Description restored to its original state. Please see #issuecomment-797859947 for further information.]

This Issue refers to the setting up of automated tests to run as part of the build/release process. The actual test-writing is not included within the scope of this Issue.

Bug description

Hueman Theme loses its widget areas when Footnotes 2.6.6 is used, User reported on Support Forum:

https://wordpress.org/support/topic/last-update-make-sidebar-disappear-on-hueman-theme/#post-14318471

Testing showed that all versions above 2.5.10 have this impact.

Steps to reproduce

Install-activate Hueman theme on WordPress.

Install -activate Footnotes 2.5.10 > works
Install-activate Footnotes 2.5.11 > fails

Expected

Widget areas display.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Describe the bug
Looks like what was holding me up was the “Show legacy custom CSS settings container”; changing that to “No” and then trying to save the new code worked out.

One odd thing, it looks like that may have bumped some other settings, for example the References sections became collapsed; but that was an easy fix by just going to General Settings > Reference Container > Collapse By Default and setting that to “No”.

Additional context
Reported by @rkupadhya

This Issue serves as a record of the accidental release a broken development version of the Plugin to the WP Plugin Directory on 2021-03-01, which caused many users' sites to break. This was a serious error, necessitating an immediate post-mortem and detailing of steps to be taken to avoid it happening again.

A full post-mortem will be posted on the WP Support Forum at 22:00 (UK time).

Bug Reports

• https://wordpress.org/support/plugin/footnotes/
• https://wordpress.org/support/topic/latest-update-broke-my-site-19/
• https://wordpress.org/support/topic/version-2-5-9d1-breaks-wp-down/
• https://wordpress.org/support/topic/crashed-my-site-104/
• https://wordpress.org/support/topic/update-breaks-layout-3/
• https://wordpress.org/support/topic/bug-history/
• direct emails to @markcheret

Initial Response

• Pinned post by @markcheret

Post-Mortem

• Complete
• Abridged

We can host the generated documentation (in docs/) on GitHub using GitHub Pages.

@markcheret looks like only you have access to the ‘Settings’ tab.

jQuery Tools is an ancient, dead library that should be replaced.

See discussion at #72

Describe the solution you'd like
Currently, the Manfisher Footnote containers are banded with gray and white. Is there a quick way to change the gray to either a lighter color or white?

Describe alternatives you've considered
Adding CSS to override the Theme default in the Custom CSS tab.

Additional context
Reported by @barrystrauss on the WP Support Forum.

Currently releasing still requires human input. Once we are happy that the scripts are not prone to errors, we can automate this fully via GitHub Actions.

Blocked by #88

Currently we have a mix of segregated and inline code in various different languages. CSS, JS and PHP code should be kept in separate files, in separate dirs.

Describe the bug
The QTags.addButton is throwing an uncaught reference error of “QTags is not defined” in my Admin area.

Additional context
Reported by @DPartridge on the WordPress Support Forum

The file class/convert.php contains various functions like to_bool() for the purpose of converting variables of one type into another. This is unnecessary and hard-to-read, so we should replace such functions with PHP's built-in type casting (e.g., (bool)).

See #32 (comment)

Related: #35

Describe the bug
The 2.5.6 codebase was migrated, but in the WordPress dashboard it incorrectly reports the Plugin version as 2.5.6d4.

Whilst we're in the process of refactoring the development and release process, it might be worth considering shifting from the use of Semantic Versioning (SemVer) to WordPress Versioning. This would bring us in line with the rest of the ecosystem (i.e., some large Plugins like WooCommerce also follow this style of versioning), but it's not a hard requirement.

Reported by @lolzim

WordPress 5.7 is coming soon, so we should check that nothing in the Plugin will break as a result.

Describe the solution you'd like
I would like to see an XML engine in this software that grabs the following from a link in this format which is standard web citation:

{{Author’s names}};{{}} OR {{Blog Title}} or {{Website Title}} ({{Publication Date}}.) “{{Title}},” {{Company Name.}} {{URL}}; {{today’s date}}

John Doe; Jane Doe (October 30, 2018.) “How to Update WordPress.” WordPress. https://wordpress.org/howtoupdate; 18 Jan 2021.

And then you can store it in the database so it doesn’t have to grab the XML data every time a page loads.

Additional context
Submitted by @andylehti on the WP Support Forum.

Currently, form input does not include nonce verification. This causes PHPCS to raise errors.

I need to:
(a) look into whether this is necessary for a Plugin, or whether the errors should be suppressed at file-level; and
(b) implement nonce verification if required (given that our forms are all on the WP admin side).

Currently, variables are named using Hungarian notation (e.g., $l_str_foo). This is both harder to read and provides no programmatic type guarantees (as as variable with $l_str in the name can just as easily be assigned any type of value, not just a string).

This should be refactored to use the type declarations introduced in PHP 7, ensuring that errors will be thrown if implicit type coercion is detected.

Note: I'm not sure if WP Plugins have to target a specific version of PHP, in which case we may not have access to type declarations

Related: #36

Now that we've got PHP_CodeSniffer set up to use the WordPress Coding Standard, we should also ensure that our codebase is compatible with all versions of PHP that WordPress Core supports.

The sniffs to add are here and here. I don't expect there will be much work (if any) required to get the codebase up-to-snuff and any changes will be less comprehensive that the codebase standardisation (see #38) so it shouldn't act as a blocker.

Sometime in the last few releases, Footnotes started ignoring the manual excerpts I have defined for all of my posts, and instead all excerpts that my theme outputs are the automatic ones generated by WordPress. This was true whether I had DIsplay Footnotes in Excerpts turned on or off.

It's possible to work around this by disabling the the_excerpt hook under Scope and Priority (once you know that Footnotes is the problem.)

Usually, the excerpts were formatted as plain text, which made this harder to debug. Today, formatting was included in the excerpts as well, e.g. an H4 placed at the top of the post as a subhead. (This finally led me to investigate whether Footnotes was the issue, since I had just updated it. After turning the_excerpt off and on, I can't reproduce it, though.)

Proposed fix: if a post has a manual excerpt defined, a) use it and b) pass it through unmodified, since they are plain text without any embedded shortcodes or other markup.

Describe the bug
The only thing I can seem to pinpoint is that it only happens when your plugin is installed. On the plugins menu, if you load the page, you have to click to be able to click on anything. It’s like there’s an invisible wall that you have to click to exit out of. I don’t know if that’s a pop-up, a message, or just an active mouse command that seems to only be active on the plugin menu.

Additional context
Reported by @andylehti on the WP Support Forum.

The project is no longer under the Media Competence Institute org. (which appears to have been deleted), so Class names (and a couple of functions) should no longer be prefaced with MCI_.

Additionally, there is no mention anywhere in the codebase or Plugin directory about the former ‘ManFisher Media ManuFactory’, and the ManFisher dashboard note currently reads ‘the ManFisher menu Will soon disappear as the company name changed and I believe it's overbearing to have that menu for such a simple function as footnotes’.

The dashboard menu item should be moved under the ‘Settings’ menu and reduced to a single footnotes tab rather than the three current ones.

@markcheret to review and approve

Describe the bug

Plugin is great, but I recently encountered issues on two websites where I use it. When activated, it will cause the mobile menu not to work, and prevent pictures from displaying. Since I deactivated it, everything went back to normal.

This was the first time I used the plug-in with this post published today. Looks great on desktop, but on mobile the feature image does not display and the hamburger menu does not work (for any page/post on the site).

I tried [ref] (( and user defined to no avail.

Disabling the plugin fixed everything (but of course my 22 references in the article no longer display properly).

Desktop (please complete the following information):
Site was recently upgraded to WordPress 5.5.1 (but I had not tried the plugin prior to that).

Additional context
Reported by @golazphil and @bowport on the WP Support Forum.

Another pre-commit hook

Describe the bug
includes.php naively identifies PHP files to require_once() by cycling through each directory alphabetically. This means that if two filenames are alphabetised in a different order to how they need to be imported (e.g., an abstract class and a class that extends it) then the Plugin dies.

To Reproduce
Steps to reproduce the behavior:

1. Rename class/layout/abstract-engine.php to engine.php (so that it comes alphabetically after diagnostics.php, which extends it
2. Attempt to activate the Plugin

Expected behavior
Files should be require_once()'d with an eye to their dependencies.

Additional context
See #32 (comment)

Currently, stylesheets must be manually minified during the build process. This should be handled automatically, as a pre-requisite for automated releases via GitHub Actions.

Blocks #89

Is your feature request related to a problem? Please describe.
n/a

Describe the solution you'd like
It should be possible to upload a DOCX file with footnotes and have it be converted to a WordPress Post with inline, Plugin-syntax footnote shortcodes.

Describe alternatives you've considered
This is currently achievable by using NoteStripper, but this software is a few years old now.

Additional context
Suggested by @russianicons on the WP Support Forum.

Error message: Uncaught Error: Call to undefined method MCI_Footnotes_Task::wp_head() in [...]/www/wp-content/plugins/footnotes/class/dashboard/subpage-main.php:1354

Discovered during #70 , confirmed to be present on the SVN repo. too (i.e., not introduced during the process of syncing this repo. back up with the SVN one). Go to the ‘Quick Start Guide’ tab in the settings menu to replicate.

I'm thinking out loud here, but based on what I've seen during the codebase standardisation I think we might be able to refactor out a lot of the JavaScript and probably get rid of the dependency on jQuery entirely.

I've not had a thorough look at everything it's being used for yet, but so far I've seen references container collapsing (which can be replaced with a <details> element and some CSS styling) and the tooltip pop-ups (more complicated, but I'm pretty sure they'll be doable in HTML/CSS as well).

This would both reduce the footprint of the extension and ensure that it continues to work for users who have disabled JS.

Right single quotation marks (i.e., the ’ character) have been mis-encoded as ‘’’ in the file class/dashboard/subpage-main.php. This affects the tooltips displayed on the Plugin settings dashboard.

This appears to have been introduced all the way back in 2.1.0 — I'm not sure how we haven't noticed it until now.

I suspect there may be some sort of underlying file encoding mismatch issue that will be worth looking into later, but for now #78 should fix the immediate problem.

From @pewgeuges:

In community-based, open source projects, it is important to comprehensively recognize, acknowledge and document how developers, testers and users helped build the product.

See development/customized-documentation-schema.txt

Since v2.0.0 (2020-10-27), bugfixing and development were top priority, and documentation was postponed. But soon the need to collect more data and to elaborate a working documentation schema became an evidence and started being incrementally addressed, using summary notes and datestamps added on the fly while debugging and adding missing settings.

After two months of intense development, the time has come to simultaneously build readable and usable docblocks providing full information enabling a user-centred approach to building the software.

Unusually, the changelog in the readme.txt as parsed for the WordPress.org platform is also retroactively corrected and completed.

See #95 for related discussion.

readme.txt, which is required for the WP Plugin Directory, doesn't render properly on GitHub. There should be a GH-flavoured markdown README that will be preferentially rendered on GitHub

During the recent release error (see #55), at least two users made the point that the Plugin updates very frequently (see here and here).

Currently, we push a new release for every bugfix, new feature, etc. with appropriate version incrementing based on the severity of the changes. However, I think it would be worth thinking about how often we want to release going forward.

A couple approaches that I think would make sense:

1. Only release minor version increments (e.g., x.1.x to x.2.x) and above to the SVN. Users could still apply bugfixes provided by us through the Plugin Editor, safe in the knowledge that when the Plugin updates it will included any bugfixes they already have applied to their copy of the Plugin.
2. Keep the ‘Stable Tag’ field on the SVN set to x.x.0 at all times, which would still allow us to push new bugfixes (e.g., x.x.1 to x.x.2) to the SVN for people who want to manually update, whilst also not spamming people with constant fixes for bugs they aren't experiencing.

Thoughts and comments welcomed.

Describe the bug
In any case, based on the example page, it looks like the long text containing the footnotes is the category term description (term_description), not post content (the_content). The plugin isn’t set up to work with taxonomy terms, only for post content.

Additional context
Reported by @vitaefit on the WP Support Forum.