Ben Goldsworthy
0a34e96450
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>
78 lines
3.2 KiB
Markdown
78 lines
3.2 KiB
Markdown
|
|
|
|
# footnotes
|
|
|
|
## Description
|
|
|
|
Featured on [wpmudev](http://premium.wpmudev.org/blog/12-surprisingly-useful-wordpress-plugins-you-dont-know-about/) — cheers for the review, folks!
|
|
|
|
**footnotes** aims to be the all-in-one solution for displaying an automatically generated list of references on your Page or Post. The Plugin ships with a set of defaults while also empowering you to control how your footnotes are being displayed.
|
|
|
|
**footnotes** gives you the ability to display well-formatted footnotes on your WordPress Pages and Posts — those footnotes we know from offline publishing.
|
|
|
|
## Getting Started
|
|
|
|
1. Read the contributing guidelines
|
|
1. Clone this repository (`git clone git@github.com:markcheret/footnotes.git`)
|
|
- We recommend that you use [VVV](https://varyingvagrantvagrants.org/) for your local testing environment
|
|
1. Install [Composer](https://getcomposer.org/download/), if you don't have it already
|
|
1. Install dependencies (`composer install`)
|
|
- You will have to install `php-mbstring` manually if you do not already have it.
|
|
|
|
## Code Formatting
|
|
|
|
1. Run `composer run lint-php` to lint all PHP files
|
|
1. Run `composer run lint-php:fix` to attempt to automatically fix errors and warnings
|
|
|
|
## Releasing
|
|
|
|
1. Run `composer run release`
|
|
|
|
## Building
|
|
|
|
1. Run `_tools/build-stylesheets.sh -c` to concatenate stylesheets
|
|
1. Manually minify the output files in `css/tmp/`, saving them as `.min.css` files
|
|
- The intention is to replace this with automated minification, meaning that
|
|
all of these steps can be rolled into a single `build` command.
|
|
1. Run `_tools/build-stylesheets.sh -d` to deploy the minified files to `dist/`
|
|
- **this will delete any existing `dist/` folder**
|
|
1. Run `composer run build` to move over the remaining files to `dist/`
|
|
- Currently, the files to include in a distribution are hard-coded in `_tools/build.sh`
|
|
- The intention is to replace this with a proper parsing of the `.distignore` file
|
|
|
|
## Updating Documentation
|
|
|
|
1. Run `composer run docs`
|
|
|
|
## Testing
|
|
|
|
Unit tests are TODO.
|
|
|
|
## Main Features
|
|
|
|
- Fully customizable **footnotes** start and end shortcodes;
|
|
- Styled tooltips supporting hyperlinks display **footnotes** or a dedicated text;
|
|
- Responsive *Reference Container* at the end or positioned by shortcode;
|
|
- Display the **footnotes** *Reference Container* inside a Widget;
|
|
- Wide choice of numbering styles;
|
|
- Freely configurable and optional backlink symbol;
|
|
- Configure the **footnotes'** appearance by dashboard settings and Custom CSS style rules;
|
|
- Button in both the Visual and the Text editor to add shortcodes around selection.
|
|
|
|
## Example Usage
|
|
|
|
These are a few examples of possible ways to delimit footnotes:
|
|
|
|
1. Your awesome text`((`with an awesome footnote`))`
|
|
2. Your awesome text`[ref]`with an awesome footnote`[/ref]`
|
|
3. Your awesome text`<fn>`with an awesome footnote`</fn>`
|
|
4. Your awesome text`custom-shortcode`with an awesome footnote`custom-shortcode`
|
|
|
|
## Where to get footnotes?
|
|
|
|
The current version is available on the [WordPress.org Plugin Directory](https://wordpress.org/plugins/footnotes/).
|
|
|
|
## Acknowledgements
|
|
|
|
Huge thanks to every **footnotes user**, contributor, bug reporter, feature requester and fan!
|