Default content is a helpful way to orient a site builder/owner when first installing a distribution. This is a ticket to determine how we are providing that default content and what content to provide.
Content to Provide Proposal
About page (in Drutopia Page and with menu link "About")
Yes, I am a big fan of default content, especially default content that can help guide users in using the site effectively. Thanks for bringing this up!
Agreed that we'll want to provide default content. Some notes on how/where.
A complexity of default content is that it's very dependent on the particular use case--which in our case translates as the particular distribution. So for example, the default news content we'll want for Solidarity isn't going to be something that ships by default with the Drutopia Article feature.
But where in Solidarity? In a given distribution, we might have a more specific version of a Drutopia feature--in this case, Solidarity Article. But this won't always be the case. If we're using Drutopia Article directly in Solidarity (that is, without creating a Solidarity Article feature), we would need to provide the default content directly in the Solidarity install profile.
So, minimally, we need a way to provide default content at the install profile level. This is probably our least-work approach: all default content is provided by the install profile.
If, in addition, our feature modules ship with default content, we would need a way to override this. For example, Drutopia Article might provide some fallback default content, but this would be overridden in Solidarity.
But however we do it, we have dependency challenges. In a given distribution, a particular feature will usually be optional. So the install profile needs to be able to provide default content for (in the case of our example) articles--but conditionally. If and when Drutopia Article is installed, the accompanying default content is installed.
We faced just this problem in Drupal 7 with the Open Outreach distribution. Our features were generic (part of a Debut feature set) and didn't themselves provide default content. We handled dependencies through a custom module (openoutreach_migrate) built on the Migrate module. Specifically, we responded to feature modules being enabled by running migrations we had mapped to those features.
For D8 the most-used default content solution is Default Content for D8. But we should also have a close look at Migrate Default Content. From a quick glance, Default Content for D8 looks to lump all (for example) node content into a single export file, while Migrate Default Content uses a separate file per node type, which could be a better fit--though we'd likely still need to submit patches before it would fully meet our use cases.
@rosemarymann and I did some successful prototyping today and will work on getting initial default content in place as a model to work from. We'll report back here when that's ready.
Following up on Nedjo's demo today, I have updated the install profile to include the Better Normalizers module and then done a demo commit for article so that can serve as a model.
@cedewey
Following up on Ben's suggestion I'm going to go ahead and export some of the test content I've been using so we can start seeing that on the home page. Then if you want to tweak you can go ahead and re-export.
Hit lots of issues yesterday with exporting default content. We have now solved enough so that installing should not be totally broken. The key issue is that default content is exporting with a term ID and since the content has been developed on more than one site, we had a duplicate. Clearly, our eventual solution is to not export with a tid but for now not broken is the goal.
@cedewey
In looking at the action default content I'm realizing that it references functionality (link actions to other content) that we will only do for Solidarity, so once we are sorted with the errors, we should remove that section from that piece of default content.
It's great if there's a fix to default content to allow IDs to be ignored, but making sure new default content is added after a fresh site install, and in rare cases when there's a conflict manually changing IDs, should also be a fine workaround going forward.
@cedewey
We may need to review and slightly revise the About page as some of the items referenced are not yet in place, like a reference to Drutopia Chat or a membership form.
We may find that while having a bit of an overview here is good and provides a model for an About page, it may be too detailed for the use case and we don't want to have to change this every time some piece of our work changes. What do you think?