* 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
This commit adds a release helper script, amongst other workflow improvements.
See `README.md` for instructions, and `_tools/release.sh` for the script itself.
This script:
1. sanity-checks the various version tags;
2. triggers a Plugin build;
3. flags the new version as pre-release;
4. tags the version in Git;
5. creates a local working copy of the SVN repo;
6. copies the new release to the local `trunk/` (whilst keeping the ‘Stable Tag’ field in `readme.txt` pointing to the previous stable version);
7. copies the commit message from the changelog in `readme.txt`; and
8. (if a flag is set) commits the changes to the remote `trunk/`.
Pushing out a new release must still be done manually, once `trunk/` is tested and working. To do so, check out a local copy of `trunk/` and:
1. update the ‘Stable Tag’ field in `trunk/readme.txt` to the new version;
2. update the ‘Version’ field in the comment header of `trunk/footnotes.php` to the new version;
3. remove the ‘p’ from the end of the ‘version’ tag in the `getInfo()` function at the bottom of `js/wsiwyg-editor.js`;
4. copy a new tag for the release from `trunk/` (`svn cp trunk tags/<version number>`); and
5. commit your changes (`svn ci -m "Release version <version number>"`).
The WP Plugin Directory will automatically parse the ‘Stable Tag’ field in `trunk/readme.txt`, and inform users that a new version is available.
At various stages user input is required to validate information. This is not ready for automation with GitHub Actions, but is a useful step on the way — see [this piece](https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-the-key-to-gradual-automation/) for more info.
Unless a `-c` flag is passed (e.g., by running `composer run release:commit`) no changes will take place on the remote SVN repo. If you want to test this out on a branch other than `main`, uncomment lines 31 & 52 of the script.
Version checking enforces the versioning rules stated [here](https://github.com/markcheret/footnotes/wiki/Versioning).
**NB: I have not tested the `-c` mode yet, as I wanted people will more familiarity with the SVN to have a look at it before I risked making any changes and blowing everything up.**
Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
* Adapt after the 2.5.9d1 accident.
* Corrections to changelog.
* Also added @revision and @timestamp PHPDOC tags
@revision and @timestamp used for SVN refs.
Full enumeration of added custom PHPDOC tags:
@accountable, @bib, @biblio, @callback, @commit, @committer, @contributor, @courtesy, @date, @datetime, @lastmodified, @modified, @publisher, @reporter, @revision, @timestamp, @user.Some tags like @reporter and @contributor are more used than others.
* Readme header upgrade.
* Create deploy-to-wordpress.org.yml
* Add distignore
* Comment out `build` command, replace npm with composer
* Remove placeholder comments
* Add build commands
* Fix typo
* Fix version number bug
* Make zip without top-level directory
* Append tag name to plugin zip
* Clean up a bit
* Rename workflow config
* Fix upload paths
* Append tag name to artifact
* Fix paths
* Revert path fix
* Try again
* Add wplm-config.xml to buildfiles
* Fix indentation
* Rename development/csscat.sh to css/csscat.sh
* Rename development/customized-documentation-schema.txt to customized-documentation-schema.txt
* Rename development/customized-template-stack.txt to customized-template-stack.txt
* Version number related fixes before pull request.
* Move csscat script to tools dir
* Rename csscat
* Refactor script
* Update customized-documentation-schema.txt
* Replace empty lines in help output
* Escape empty lines.
* Delete 3 items from `.distignore`
As mentioned, CONTRIBUTING.md and README.md should be included in distributions.
- As an invitation to the Community.
- As a tangible proof of goodwill after the 2.5.9d1 accident.
Also SECURITY.md so Footnotes users see that we’re concerned, and
can reach out without transiting via GitHub.
* Include CONTRIBUTING.md README.md SECURITY.md
* Update sync w/ 5.7 tested.
* Update
* Update composerfiles
Co-authored-by: pewgeuges <73141620+pewgeuges@users.noreply.github.com>
