* release: release 2.7.2
* fix: urgent 2.7.3 release to fix fatal error
* chore: remove un-needed setup script
* ci: remove steps from pre-push command
* chore: remove un-needed PHP-Commitizen config
* chore: put image files in correct folders
* chore: move GitHub image into `.github/` dir
* fix: classic editor button
* fix: call correct jQuery Tools file in dev env
* docs: replace license with Markdown version
* ci: clean up PHP linting commands
If anyone has noticed me playing musical filepaths with these commands
for a while, it's because I kept getting inconsistent results from the
use of double-globs (i.e., `**`). However, I've finally figured out
that this is because Composer is running these scripts in its own shell,
so the double-glob that works when I run the command manually in my
Terminal doesn't work when Composer runs it in its.
* chore: lint PHP files
* build: update JS linting standards
* chore: lint JS file
* build: add node-sass
* build: add additional stylelint rules
* chore: lint stylesheets with new rulesets
* refactor: move ESLint settings to `package.json`
* chore: move Prettier config to `package.json`
It is not yet possible to move `.prettierignore` to `package.json` too,
but this appears to be on the horizon; see [this Issue][prettier-issue].
[prettier-issue]: https://github.com/prettier/prettier/issues/3460
* fix: move WPML config into Plugin folder
* chore: move Stylelint config into `package.json`
* chore: remove unused `.distignore`
It can always be re-added at a later date if it becomes useful.
* chore: format file
* build: add HTML linting
* fix: add image alt tag
* ci: clean up GitHub Actions workflows
* fix: fix workflow
* fix: fix indentation
* ci: add YAML validation
* chore: make valid
* ci: add YAML validation
* chore: lint code
* ci: change dep install back to original
* chore: lint license
* docs: split changelog into separate file
See #137
* docs: add information to Plugin header
Fix#138
* docs: update WP readme
* docs: remove FAQs
* docs: remove installation instructions
These were causing the FAQ section to render incorrectly
when viewed in the [preview validator][validator].
Also, the [WP Plugin Handbook][wp-handbook] says that:
> If your plugin has no custom install settings, it's
> okay to omit this section.
[validator]: https://wpreadme.com/
[wp-handbook]: https://developer.wordpress.org/plugins/wordpress-org/how-your-readme-txt-works/#installation
* docs: update links, versions, add extra changelog items
* docs: lower version to stable ver
<opinion>
Explicit enumeration makes sense in legal documents, but CoCs are
more aspirational so I don't think it makes sense in this context.
You will end up either having to constantly add new things to the
list, or declare that the list is non-exhaustive (in which there's
not much point in enumerating in the first place).
This is doubly true given the inherently woolly realm of appropriate
interpersonal interactions that a CoC is implemented to moderate.
Also, remember the KISS principle. Personally, I think this is the
pinnacle of CoC design: https://github.com/karlgroves/dontbeadick
However, I'm sure there is a slightly-more-professional middle
ground ;)
</opinion>
I had to use some RegEx-fu for this. Specifically:
```bash
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/\(p\|l\|a\)_\(str\|bool\|int\|obj\|flo\|arr\)_//g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/MCI_Footnotes/Footnotes/g' {} \;
find ./{footnotes.php,includes.php,class/} -type f -name "*.php" -exec sed -i 's/C_\(INT\|STR\|FLO\)_//g' {} \;
```
This should have covered all the bases.
In my testing I encountered one error caused by these changes.
In the `add_select_box` function in `/class/dashboard/layout.php`,
there was a function parameter called `$p_arr_options` and a variable
called `$l_str_options`. Removing the Hungarian notation caused an
error as these two variables were both now called `$options`.
This has been fixed, and I like to think that that will have been
the only naming conflict, but I think it is more likely that there
maybe others. Further testing is required before I am happy calling
this release-ready.
Close#34, progress #36
