We currently have a lot of code duplication for various things such as getting data from the wiki list, figuring out which site in the farm we want/are as well as half a dozen other things.
We could eliminate this by writing an "independent" library to fit the majority of these uses so we can cut that duplicated code out.
(Duplicated code = more work to maintain, potentially outdated copies of a lot of things, etc.)
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | lewiscawte | T98 Write a ShoutWiki library | ||
| Open | None | T26 Create a generic "ApiCreateWikiSuggestions" |
One of the major problems I had with this idea the last time it popped into my mind was that where would the code go? Logically speaking it'd be a part of CreateWiki, as everything and anything is tied into the architecture that CW provides, requires and expects, but CW is enabled only on the English Hub! So we'll likely need to create a new meta-extension for this.
And thus we need a name for it, unless we'll settle for plain "ShoutWiki", and maybe source availability status would need to be considered. There are extensions which use and depend on the CW framework -- i.e. wiki_list and wiki_settings tables in $wgSharedDB -- which are open source (ShoutWikiAPI) and even more which are not, even if they are forked from an open source extension (ref).
Anyway, caching! It must have caching! A lot, if not all of our extensions interacting with wiki_list/wiki_settings (CreateWiki and its components excluded) just skip over that, which is bad for various well-known reasons.
So I was thinking something along the lines of the libraries in vendor/ - which I believe use PHP namespaces (which I'd like to learn more about) and then if we need to write an even smaller meta-extension for that, then we could do that (and a name has disappeared from my head in the time it has taken to reply to this) and then load that globally.
As for caching - 100% agree. We ought to decide what we need to cache while we write this extension. Initially, I expect it to be a few basic, very common functions and we can gradually expand it. We shouldn't rush this, this code will be used all over the place and for various uses so we want to consider all of the use cases and design solutions that will fit them all - even if it means looking into technology that is new to us.
We've implemented a general set of functions so far that form the base of what this task requested. Closing this as resolved and further features can be added when needed or requested using the SWLib project tag.