Passing EmptyBagOStuff will still have same effect, but the deprecated
way of specifying so with boolean is now removed.
Change-Id: I8ec0f54e94b71af9256813f333e615bca1bb8444
* Injecting the cache object makes the class easier to test.
* The $forceRecompile parameter was not used anywhere, not tested,
and only mentioned in one README (fixed in I13fba7314).
Based on past experience I generally expect that when bypassing a
cache, it is neither read from nor written to. Such feature might
be reached out to when testing something, in which case it should
not be stored.
If this was intended as a way to purge it in prod via eval.php,
we generally don't provide dedicated purging commands in code.
We either call BagOStuff or Memc/Apcu directly, or invalidate the
underlying data (e.g. touch the template file, or bump the cache
version).
To use TemplateParser without caching, one can still pass
'new EmptyBagOStuff' instead if needed.
* Set the $ttl parameter in the set() call.
It is generally an anti-pattern to store something without
any TTL as that means it can needlessly compete for space
even after further deployments have changed the key or stopped
using a particular key. For now I used a liberal default
of 1 week.
Change-Id: Ic84b996b46c72e9dc33eed2645204fc2d6c5240c
Template names aren't expected to be globally unique. Template paths are
by construction.
Include the template directory in the cache key in order to avoid the
cache keys of ambiguosly-named templates - e.g. index.mustache -
overriding one another.
Bug: T113095
Bug: T248010
Change-Id: I3196967ec2a7a5cec409a0c7ce4471a7d8773978
Changes:
- Update TemplateParser::compile to return all files read during the
compilation of the template and the hash of those files
- Tweak the cache invalidation logic in TemplateParser::getTemplate
accordingly. This is made trivial due to the friendly design of the
FileContentsHasher::getFileContentsHash.
Bug: T113095
Change-Id: I948fdaecf720d7d16c5ccabb2d7f01b5cbf27c90
Update TemplateParser::compile to return the PHP code and metadata. The
metadata includes details about the compilation that can be used to
validate that PHP code fetched from a cache is fresh without having to
recompile the original template.
TemplateParser::getTemplate did have such an invalidation mechanism but:
- It stored the hash of the template file in the key
- It stored the hash used for checking the integrity of the cached PHP
code in the first 64 bytes of the value
This tight coupling between the compilation result and the contents of
the cache key/value made changing either the compilation or cache
invalidation steps difficult.
After this change, arbitrary metadata can be added or removed from the
compilation result.
Changes:
- Move all filename generation and reading to TemplateParser::compile
and align its signature with ::getTemplate
- Update TemplateParser::compile to generate the file hash with
FileContentsHasher::getFileContentsHash, which is used by
Resource Loader to generate file hashes, and return it as part of its
result
- Update TemplateParser::getTemplate to store the integrity hash in the
compilation result prior to caching it
- Bump the cache key major version as both the key and value have
changed
Note well that TemplateParser isn't expected to be subclassed, and
::getTemplate and ::compile are protected members and are therefore out
of the scope of MediaWiki's deprecation policy.
Bug: T113095
Change-Id: Ifb5e122c6ae238fd300cd60f2b1ab33b7ece8e71
TemplateParser::getTemplate and ::compile both throw exceptions in
certain circumstances. Document those exceptions/circumstances for other
developers.
Also, use the same language and message format in all exceptions thrown.
Bug: T113095
Change-Id: I73fedd2bd66f5f938ac95edfbd78067a776cdff8
This reverts commit 82faff75ee.
Reason for revert: Was not actually necessary to make lightncandy work
Also remove compileForEval(): stripping <?php tags is no longer needed
because the new version of lightncandy doesn't emit them.
Change-Id: I87c3f4842baaf400b532ba4843d66b22bc48e6fb
Needed because we upgraded to a newer version of lightncandy, which
contains breaking changes. Cached compilations from the old versions
won't work with the new version.
Add a cache version variable so that we can bump this more easily in the
future when upgrading lightncandy.
Follows-up 7c4e9f790a
Change-Id: I7c05019df7eb044cff7bb8e67b2835970e1f384d
This allows variables defined in an outer context to be used in inner
contexts. For example:
<h2>{{foo}}</h2>
<ul>
{{#things}}
<!-- bar is a property of each thing, foo is an outer variable -->
<li>{{foo}} is a {{bar}}</li>
{{/things}}
</ul>
Bug: T203209
Change-Id: Ib0ae0fb0b4be6b161f548c79db6fb6f4b831f7c1
This fixes 26 of the phan-taint-check warnings on MW core. Some
are outright fixed, others are false positives that were suppressed.
This really only covers some of the easy ones. There are still
314 warnings to go.
Change-Id: I30463bc3a09fd4324d190de8533f51784764dd3a
Recursive partials are the only way to handle tree-like structures
such as nested lists. Allow setting FLAG_RUNTIMEPARTIAL in LightnCandy
so they can be used.
Since this has a slight performance impact (makes partial invocations
evaluation-time functions calls instead of compilation-time transclusions)
make it optional.
Change-Id: Ie37105a9f1ff92e1a79bfcd9f8578965e3d347f0
Previously, if the cache integrity check failed then it would emit a
warning but then continue to use the code. The integrity check could
genuinely fail if the secret key was changed, if the cache was
truncated, or other edge case scenarios.
Now TemplateParser will recompile if the cache fails the integrity
check, and then update the cache with the newly compiled version.
Bug: T163154
Change-Id: I9a6c8d528f84cfbabf402cfaf6468c162fab1f15
In practise this probably doesn't matter, since template names
are not user controlled, and php isn't stupid enough to fall for
tricks with nulls (afaict). Nonetheless, the code from Title is
only meant to prevent url traversal, it is not meant to prevent
file system path traversal.
Change-Id: Id690576326d03744acc8fbbe78f4b7a4b4c04d7e
Also:
* Use ternary shorthand.
* Remove verbose comment about APC fallback. APC always requires
a fallback and is enforced by the method being called. Stating
the obvious is confusing here.
Change-Id: Ie5cb3bdc60600806b01b57f1f1b352b981818b0d
This is sufficient to make https://gerrit.wikimedia.org/r/#/c/223165/
work. It hardcodes .mustache as the extension, but so does
existing getTemplateFilename().
Bug: T97188
Change-Id: Id588ae9b43b13fcf35ebd285c826dd502ac424ec
All of the other functions expose internal implementation details, which no
external caller should ever need. In fact, no external caller does use these
functions directly.
The TemplateParser::compile() tests were removed as they're simply just
checking LightnCandy functionality, which is something the library should be
doing.
Change-Id: If9003d40315e0e5aa361c174b764b799e3b88c34
Also add regression test, and coverage for more methods.
Was trying to eval the code which had the hmac integrity check in front of it,
which causes a syntax error in valid PHP code.
Follows-up db1866da4, 50c50bea2e.
Bug: T93436
Bug: T93511
Change-Id: Ie90074e4885de7340e53f59fdd479f5384b5eac6
In the unlikely event that no secret key is available, we shouldn't
rely on the cache at all in TemplateParser.
Adding new compileForEval() function and and moving eval() outside
of if statement to prevent code duplication.
Also, if the template fails integrity check, generate a notice
instead of throwing an exception in case we change the secret key.
Change-Id: Id44fdcc9533fc8a9c77e84fcebaa064f602477c6
The TemplateParser class provides a server-side interface to cachable
dynamically-compiled Mustache templates. It currently uses the
lightncandy library to do compilation (which is already included in
the vendor repo).
Also converting NoLocalSettings.php to use it as a proof-of-concept.
Bug: T379
Change-Id: I28cd13d4d1132bd386e2ae2f4f0d1dd88ad9162b
