https://framagit.org/hubzilla/core/merge_requests/1270

Just a note withdrawing PR 1270 - some notes are in the PR discussion itself.

1) Hook to change App::$page just prior to page display -- after consideration, I'm not sure at all what this adds. At any rate, whatever the reasoning I had for submitting it originally no longer obtains. If someone else thinks it's a good idea, I guess it could be resubmitted.

2) Hook into Articles - It looks like the better solution is for any addon dev who wants to make changes to the articles module is to clone the articles module and just make the changes. The call to status_editor() adds data to App::$page['htmlhead'], and could mess up settings if the jot editor is going to be used. To fix that would require a second hook to change the behavior of status_editor(). And by that point, any dev would be recreating significant portions of the current module anyway and may as well just go that route. It's not that big/scary or complicated. So either an addon on it's own endpoint - or even using the facility for Zotlabs/SiteModules/Articles.php (see Zotlabs/Web/Router.php) is probably the correct solution.

3) HTMLPurifier - It was a first stab to lessen restrictions in certain cases for articles, web pages, wiki entries, maybe cards while still allowing the use of nomadic identity and automatic cloning of those items. Digging more deeply, it's clear that the the way things are transmitted (see include/zot.php::process_delivery()) means that any modificatons to HTMLPurify configuration would need to be universal (all item types) and site-wide (actually ALSO be implemented on all sites where channel clones reside) in order to work. So now I see the overall concern with changing it as proposed - to work, it would not only have loosened restrictions for the desired item types on the local machine, it would have needed to be a univeral loosening of restrictions. In that way, I agree. Bad idea.

I have an different approach/alternative that I'd like to float - but I want to sleep on it and see if any gotcha's come to the fore in the morning.

Anyway - thanks @Mike Macgirvin and @Mario Vavti for your patience... you have a much better handle on the code base than I do. I trust you both enough to know that when you give resistance to an idea, there are reasons - even if they aren't readily apparent. I imagine sometimes for you there isn't more than an initial "gut feeling" that it's a bad idea - but it would take you quite a bit of digging back through to figure out exactly why - which isn't a reasonable expectation for others to impose on you. At any rate, I wanted to put these notes here - mostly for explanation, posterity, and as an apology if I came off a bit pushy.
  
No need to apology. It was certainly a "gut feeling" for me. Allthough i am not opposed to have those hooks (you certainly have a point with "anyone can fork and do his own thing anyway"), i think it needs a broader discussion.
  
Ultimately, the only hook of the list worth considering, IMHO, is the HTMLPurifier hook. And the way that items are filtered during distribution and the fact that you can't assume that all the hubs involved (even of cloned channels) will have the addons installed, an addon that hooks in and changes the HTMLPurifier settings will have it's data munged when it gets passed on to other hubs (even cloned) - at least that's what I see in the code. That being the case, the data transmission will be unreliable and introduce major headaches for addon devs and/or hub admins and/or users. So I don't see that as even a reasonable solution. I just hadn't dug through ALL the ramifications with regard to transmission and only considered the local hub as I was making the proposal.

A better solution, I think, is a nomadic aware arbitrary storage solution for addons (see proposal in the Dev forum. MOST of the needed things are already there (or exist in other parts of the infrastructure). So I've redirected consideration to that solution at this point.