| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
There seems no need to allow selecting a location when creating a page this
way; the user should always want it to appear in the inline whose form they
submitted.
|
| | |
|
| |
|
|
|
|
| |
Use the included page name rather than the including page name. This
allows us to allow feeds in nested inlines without duplicating feeds
with the same content under different (and stupid) names.
|
| | |
|
| |
|
|
|
|
|
|
| |
and support all elements that HTML::Tagset knows about.
(Which doesn't include html5 just yet, but then the old version didn't either.)
Bonus: 4 times faster than old regexp method.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
plovs reported a crash when templates were not installed properly,
with a non-useful error about the template object not being defined.
I've audited all uses of template_depends(), and template(), and it makes
sense for them to throw an error if the template cannot be found. All code
with a user-supplied template catches errors already, to handle template
parse failures.
It did not make sense for template_file to throw errors, as some code uses
it to probe if a template file is available.
|
| | |
|
| |
|
|
| |
second parameter, to allow for plugins that needs access to this information earlier than the delete hook.
|
| |
|
|
| |
indexed for searching.
|
| |
|
|
|
|
|
| |
Note that I put comment-header in a <header> despite it being
below the comment. Using a <footer> would be confusing given
the class name. Also, the content is semantically closer to
a header than a footer.
|
| |
|
|
| |
mode, use time tag.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This entailed changing template_params; it no longer takes the template
filename as its first parameter.
Add template_depends to api and replace calls to template() with
template_depends() in appropriate places, where a dependency should be
added on the template.
Other plugins don't use template(), so will need further work.
Also, includes are disabled for security. Enabling includes only when using
templates from the templatedir would be nice, but would add a lot of
complexity to the implementation.
|
| | |
|
| |
|
|
|
|
| |
This makes them consistent with the rest of the meta keys. A wiki rebuild
will be needed on upgrade to this version; until the wiki is rebuilt,
double-escaping will occur in the titles of pages that have not changed.
|
| |
|
|
| |
plugins from the setup file.
|
| | |
|
| |
|
|
|
|
| |
discussionpage setting.
Specifically, fixes discussion actions on discussion pages, and unbreaks the opendiscussion plugin.
|
| |
|
|
| |
show.
|
| |
|
|
|
| |
%links is populated even for just-deleted pages, so %pagesources
should be used for such tests instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
include feeds.
Speedup of about 25% for small inlines; could be much larger for inlines of
many, or complex pages.
Not bloating memory with excessive memoization data was the key to this.
The method chosen does not squeeze out every erg of speed possible when
inlines are nested, but that's rare. It uses less memory than other
optimisation hacks (I'm looking at you,
f937c1fb8074a512d8bb788fa275f5e90595cd47 !) already used in inline.pm.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
My experience is that when inlines are nested, the old behavior of
generating feeds for the nested inlines was never really desired. Since the
feeds were numbered sequentially, the numbers could easily change, and it did
not make sense to subscribe to or use those feeds. And generating those nested
feeds often meant a lot of unnecessary calculation, and data being written.
So, I dropped them.
Looking back, nested feeds originally were a free side effect of properly
handing multiple feeds on one page. Of course, that is still supported.
|
| | |
|
| | |
|
| |
|
|
| |
Don't generate inlined page content if the template does not use it.
|
| | |
|
| |
|
|
|
| |
To avoid breaking plugins, also support the old pagespec_match_list
calling convention, with a deprecation warning.
|
| |
|
|
|
|
|
|
| |
This dependency was missing before switching to use_pagespec.
It is correct to add it, but it needs to be combined with the regular
"pages" dependency to ensure that it does not match extra pages.
(Also fixed its dependency type.)
|
| |
|
|
|
| |
Taking advantage of every single one of its features, of course.
Even had to add one more..
|
| |
|
|
| |
Also, this fixes 2 bugs in dependency info.
|
| |
|
|
| |
that hack is not needed, thanks to pagespec influences calculation
|
| | |
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| | |
The po plugin's injected bestlink must do something special when called by this
exact part of inline's code.
Signed-off-by: intrigeri <intrigeri@boum.org>
|
| |/
|
|
|
|
| |
This is unnecessary and just slows us down (by a factor of 2, in the
pessimal case where every page has an inline with pagenames); it's also
not possible to optimize it into add_depends_exact calls.
|
| |
|
|
|
|
| |
This reverts commit e4cd168ebedd95585290c97ff42234344bfed46c.
There was no benefit to this change.
|
| | |
|
| |
|
|
|
|
| |
The new dependency handling works better (eliminates more duplicates) if
dependencies are split up. On the same wiki mentioned in the previous
commit, this saves about a second (i.e. 4%) on the same test.
|
| |
|
|
|
|
|
| |
This is both faster, and propigates any error in processing the feedpages
pagespec out to display on the page. Which may have been why I didn't use
it before, but currently seems like a good thing to do, since it explains
why your feeds are empty..
|
| |
|
|
|
|
| |
By adding this setting, we get both more configurability, and a minor
optimisation too, since gettext does not need to be called continually
to get the Discussion value.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
If given instead of pages, this is interpreted as a space-separated
list of links to pages (with the same LinkingRules as in a WikiLink),
and they are inlined in exactly the order given. The sort and pages
parameters cannot be used in conjunction with this one.
|
| |
|
|
|
| |
Another benefit is that consistently using gettext("Discussion")
eliminates the need to translate one string.
|