[meta] Remove unwanted modules

[quicksketch]

We've definitely got our work cut out for use adding modules to Backdrop (Editor, CKEditor, etc.), but one of the first (and fun!) things we should do is remove the baggage of modules past, including:

• aggregator
• dashboard
• forum
• openid
• overlay
• php
• poll
• rdf
• statistics
• tracker
• help
• shortcut

I'd also like to remove the things that don't provide real value and/or haven't been updated in years. More or less, we're looking for suggestions. Anything that requires a significant effort (removing hooks for example) should probably be individual issues.

• book
• color

[maxpearl]

Should help really be removed? That seems like it should be useful.

[quicksketch]

The trouble with help is that it's help isn't located in a place where it's... well... helpful.

Some reasons why it's all wrong:

• You have to try and describe the entire module on a single page, which usually isn't linked from anywhere.
• The "index" of available help pages is such a hodge-podge, because only 1/2 of modules implement it in the first place.
• Because including images is difficult, you usually don't have any.
• Translating is ridiculously difficult, because the strings are so long. And changing one character in the help means it needs to be re-translated.

@merlinofchaos did a bunch of work revamping help module (i.e. Advanced Help in D7), but it never made it into D8. We could take that approach of a centralized help system or (my preferred approach), use a combination of inline-help and links to external documentation.

[oskarcalvo]

The block module should be change by beans + context.

[jenlampton]

Remove help module:
#75

[jenlampton]

Remove shortcut module
#76

[adnasa]

Want to add to the list of remove

• contact
  • Either remove this or update it (will require significant amount of code, I presume).

[saltednut]

Agree with @oskarcalvo that you may want to consider using bean to provide re-usable, fieldable block entities.

I do not agree that context is necessary. Its essentially an extension of the core block system.

A different way to go about this might be to take whats necessary from the bean modules to create a new block module, basically combining bean into block.

[larowlan]

Drupal 8 includes custom-block module, which supersedes bean, fieldable-panel-panes et al.
Here's a screencast from an early patch from the issue where it was added http://www.youtube.com/watch?v=A5zcbAtAKJ0

[oadaeh]

While I certainly agree with many of the module removal decisions, I'm sure every single one of those has fans that would like to see them continue to live on somewhere. Is there a place (a contrib repo) for them to go, provided someone were willing to continue maintenance?

[oadaeh]

Okay, so I found a reference to an issue in another repo (that I wasn't watching) that is currently discussing the where/how of my query: backdrop-ops/backdropcms.org#8

[mkalkbrenner]

I already agreed on maintaining the xmlrpc "module". But there's no decision yet where to host these modules: #67

[quicksketch]

@mkalkbrenner: The issue @oadaeh referenced has all the details: backdrop-ops/backdropcms.org#8

The thing we know for sure is that you'll be able to register a Git repository with the central packaging system. That might require that the repository live on Github but definitely would work with it even if there are other options. So for contrib-land right now, I'd recommend making a repository on Github for hosting projects. Regardless of the system we ultimately choose, all the current options are based around a remotely hosted repository.

[oadaeh]

While I realize the Color module has not seen a lot of attention since it's author went on to other things, I think if the idea of Backdrop is to be a place for people to build sites w/o getting their fingers dirty with code (I can't find where I read the statement just this morning to quote it), then at least some level of that functionality needs to hang around.

[mkalkbrenner]

I created a pull request to remove xmlrpc and created a a new contrib module as replacement: https://github.com/mkalkbrenner/xmlrpc

If someone likes to turn a core module that has been or wil be removed into a contrib module, this instruction helps a lot to preserve the log history: https://help.github.com/articles/splitting-a-subpath-out-into-a-new-repository

[quicksketch]

We've now closed all the sub-issues on this one. 11 modules removed!! Nice job everyone. Now on to the less-fun (but still fun!) job of backporting. :)

I've started a list at #106 of backporting jobs, but it's far from complete. I'll be filling it out more in the next few days, definitely before BADCamp, where we'll be having a code sprint.