Right now all of our markdown macros are defined in Allura core, even those that are tool-specific. We should provide a way for plugins to register their own macros with the platform.
Looking good. Few things though:
It seems that the @macro decorator is sufficient to register the macro, but we need an entry point to ensure the module gets loaded and registering happens. But then we don't use the entry points. Seems a little odd, but I'm not sure how to improve.
In test_globals.py it still checks for 'download-button' and no longer passes.
The nbhd macro [[projects display_mode=list]] includes the [[download_button]] macro, which ends up being spit out as plain HTML text. I don't want to go down a rabbit trail on this particular ticket, but perhaps we should just make show_download_button default to 'no' instead of 'yes' for better default behavior (the Neighborhood Help text should be updated with the new default too).
Can we get some docs? extending.rst should cover this.
New commits on both repos.
Looks great. I found one more issue though, the default content for a wiki page includes [[download_button]] which previously ran but showed nothing. Now without that macro, new wikis will have a literal [[download_button]] on the wiki home page. There are a few references in the code but I think the one at ForgeWiki/forgewiki/wiki_main.py +283 is the one that matters.
It'd probably be useful to have the default wiki page content configurable/overridable anyway.
So for this ticket should I just remove the [[download_button]] macro from the default wiki page text?
That'd be sufficient in terms of making this have good functionality for standard Allura installs.
For SourceForge to continue to have a [[download_button]] in the default content of new wikis, though, we'd have to make the default wiki content configurable. An .ini setting might work but would be lengthy and cumbersome. An overridable template might be nice. Neighborhoods can have a "project template" specified for initial tool configuration and that includes support for home_text on a wiki, but then users can't choose their tools at all during project creation, so that's no good. Perhaps a new ticket for this :)
For now, how about making the default page text a property of the WikiApp? Then we could just subclass and override it in sfx.
Seems ok to me, as long as there won't be problems with 2 tools with the same name. I think you figured out some of that before.. disabling the original entry point perhaps? Will the tool name be the same so existing app configs from mongo load the overrided app?
Yeah, a while ago I added code that allows entrypoints to be overridden by subclasses. See the iter_entry_points() docstring in allura/lib/helpers.py.
Rebased and force-pushed tv/6393 on allura and forge-classic.