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.
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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 :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
allura:tv/6393
forge-classic:tv/6393
Looking good. Few things though:
It seems that the
@macrodecorator 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 makeshow_download_buttondefault 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.rstshould 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 atForgeWiki/forgewiki/wiki_main.py +283is 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 forhome_texton 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 inallura/lib/helpers.py.Rebased and force-pushed tv/6393 on allura and forge-classic.