#3929 - Big code audit

According to line_count.sh, we currently have 860,160 lines of our own code in the git repository (third party code or generated code is excluded from this count, although its not perfect). That can be expected to grow. v10 has 789,092 lines (~ 9% less).

Maybe we can set a target for v11 (+ non-bundled addons) to contain a maximum of 850,000 lines.

That's completely arbitrary, but sometimes any kind of target is a good incentive to think harder about things. It doesn't matter if we don't hit it, but we can try.

Current thoughts about dropping stuff...

Drop RSS cloud support
EDIT: Enhanced it instead. WebSub is not an appropriate substitute, which I've discussed on its issue.

ssl addon - now browsers warn about visiting any HTTP pages, SSL certificates are free, SSL is not a performance issue, and everything supports SSL. There's no reason to support per-page configuration of SSL.
EDIT: Removed

transcoding - I think nowadays it is reasonable to ask users to export as .mp4, all tooling is going to support that, and phones etc are going to save straight to .mp4 I believe.
EDIT: Was already removed

News blocks 'historic' feature - it's very obscure to want to be able to say "things that happened on this date, on other years"
EDIT: Minor feature can stay

Submitter banning - I don't see why you need to specifically ban someone as a submitter, when you can ban them entirely, or put them on probation
EDIT: It's for non-Conversr forums. Keep.

iotds addon - galleries can do what IOTDs do, using awards. There's an argument IOTDs is an example of a new content type being implemented. But I think bundled content types are just as clear an example.
EDIT: Removed

zone_logos addon - if people want per-zone logos they can just use template editing to achieve that.
EDIT: Removed addon, theme image overrides can still be used

Drop msn addon - the whole notion of editing "network links" is very specific, and can just be done with menu editing and some custom sync code
EDIT: Removed

Drop side_language block (who wouldn't want flags in header, or menu links?)
EDIT: Actually it may be useful for some, keep

Drop main_only_if_match block (can just be Tempcode)
EDIT: Removed

Drop main_cns_involved_topics block (we have a vforum for it)
EDIT: Actually it's the back-end of a member tab, keep

Drop main_personal_galleries_list (should just be a part of your member profile)
EDIT: Actually it's the back-end of a member tab, keep

Drop main_pt_notifications (who would not just use top_notifications?)
EDIT: Removed

Merge all the following blocks into main_multi_content:
main_gallery_embed
main_gallery_mosaic
main_image_fader_news
main_news_grid
main_news_slider
main_hero_slider
main_image_slider
main_downloads_carousel
side_news_categories
bottom_latest_news
main_cc_embed
side_galleries
EDIT: Working on this. Will handle outside this issue.
EDIT2: That never happened for some of these blocks.


Things I have should move to non-bundled...

google_appengine addon - It's not even supported and is vendor-specific
EDIT: Needs to be bundled as integrated with installer.

sms addon - It's not even supported and is vendor-specific
EDIT: Leave, as people may have working SMS when they have no working mobile data.


Things that are questionable but I think we should keep...

Trackbacks - Ultimately this would be better upgraded to support newer standards like pingback. I don't want to drop it as federation between sites is a fundamental hedge against the hegemony of social networks, and I think we shouldn't close the avenue to future improvement.


Other notes...

I think the top/bottom/side/main prefixes should be removed from blocks. Then we are also merging code, e.g. side_news and main_news will merge. We can introduce a new render_mode parameter (equivalent to what main_multi_content is getting) to determine what kind of render-style to use. Each render style can get its own set of templates.
EDIT: No change, discussed further below

I'd happily see more core features (Galleries, News/Blogs, Downloads, etc) become non-bundled allowing a simpler starting point. Assuming the current level of interactivity and integration between core features is maintained a future version of Composr could be pretty lightweight and offer all the extra bells and whistles at a click (perhaps as part of the setup wizard). As long as the nightmare that is WordPress Market isn't repeated and the main addons are provided or verified by the Core Team I believe it would work a treat. If someone submits an addon it could be on the basis that it may be altered by the devs before inclusion to maintain the standards. Composr out-of-the-box is perhaps too overwhelming for some who would find it easier to theme with less to consider initially. Sometimes I want to strip things back a bit for certain projects and that can take quite some time to achieve (it's not really needed, but I do uninstall the core addons I don't require). Or perhaps a Lite and Full version could cater for each extreme. Just a thought.

I much prefer the approach in #3856. Keep stuff bundled (which is a clear indication it's the official supported way of doing things in Composr and has to be well-integrated), but isolate addons to different directories and allow them to mostly be disabled at the point of installing.

That way you're not messing with secondary versioning, communicating whether a non-bundled addon is the sanctioned addon for something or not, forcing people to download extra stuff, doing separate upgrades, and once we have too many addons being forced into the untenable position of having to work across a couple of hundred different git repositories to make any kind of sweeping changes.

I was thinking more about "I think the top/bottom/side/main prefixes should be removed from blocks".
I no longer think we should remove the distinction, even though it's problematic.

Side blocks may be more lightweight than main blocks in terms of performance. For example, main_news would load up news summaries while side_news would not.

Also clearly communicating intended positioning to the user, including in the Setup Wizard, has a lot of value to it. If the user wants to place a block elsewhere that's great, but they'll know they may need to do extra themeing work.

Instead we should make sure that when we have multiple implementations of similar blocks we should make sure they are sharing as much code as possible. Maybe also have some way where the language strings for the parameter documentation can be shared.

Ahh yes, that sounds like a much better approach (as does multiple blocks and keeping the location prefixes). It would be great if more non-essential addons were disabled at install. That way, even if you're not doing anything custom, you still get to build your site up in a way that works.

Discussed with Patrick.

We agreed on all with a couple of changes:
- Zone logos can be simplified to just a theme image naming convention under a symbol, there's no need for any setup when adding/editing zones or an addon for it
- Historic news ("on this day in history" kind of thing) is a cool feature with very little overhead (of any kind), so we can keep - so long as we do a good job of merging away block (and associated language string) duplication