Parent links in sitelinks_alt::sitelinks_alt_shortcode() now have their
button image URI parsed by e_parse::replaceConstants(), bringing it into
consistency with the children, which are already parsed the same way.
There is no corresponding test for this in e107-test because hard-coded
dependencies in sitelinks_alt::sitelinks_alt_shortcode() are difficult
to monkey-patch without crippling the performance of e107-test.
This "inline token" is generated 30 times in my test, but it's the same
session_id() being hashed. This is wasteful and can be mitigated in two
ways:
* Reducing the time cost like so: return password_hash(session_id(),
PASSWORD_DEFAULT, ['cost' => 04]);
* Storing the hash as an instance variable the first time it's
generated
This commit applies both mitigations.
Fixed irreversible data loss bug when preparing the app path repo
for tests
OLD BEHAVIOR
Remove untracked files from the working tree before and after
every test suite. The intention was to remove files that could
have been created by the tests, but this also removes all other
untracked files, including third-party plugins and themes.
NEW BEHAVIOR
There is now a triple locking mechanism protecting the state of
the app repository before tests are run so that after tests have
run, all file contents are restored to how they were before the
tests have run.
There are three locks, each guarding a different part of the
original repo:
* file
* commit
* stash
When the file lock is present, E107Base knows that any other file,
tracked, untracked, or ignored, was created by the tested code.
The file lock is checked into the commit lock, which saves all
tracked and untracked files in the form of a commit. This way,
uncommitted code can be tested without manually making a commit that
includes the untracked files.
The stash lock saves all ignored files in a Git stash. Ignored files
go in a stash instead of in the commit lock because they can be a
confounding variable affecting the outcome of tests. They are usually
user-configurable only and may not represent tested states.
When the saving is complete, E107Base will have access to tracked and
untracked files but not ignored files. The tests are run in this
configuration.
After each test suite runs, the repo is reset and cleaned to return
the files to the same state they were in before the test suite began.
Then, the locks are undone first by rolling back the commit lock,
which restores the originally uncommitted tracked and untracked
files. Next, the stash lock is popped, restoring the originally
ignored files. Finally, the file lock is removed, signifying that the
repo is back to its original data before the test suite was run.
In case of an ungraceful exit, at least one of the locks would be
left in the repo. The next time E107Base runs, locks are checked, and
if one or more are present, the repo is restored before the locks are
reestablished.
If the `git` command is inoperative, only the file lock is operative
and does nothing more than signify a test that is in progress or has
exited unexpectedly. Data protection is silently unenforced. This can
lead to unexpected tracked, untracked, and ignored file modifications
that will not be rolled back after a test suite has run.
