We don't know yet which will be the next CMS, but we know that no matter what the solution, some pages/features will need to be worked on.
We chose Drupal8 (see #141 (closed) and #130 (closed)) as the next CMS for civicrm.org. We are avoiding the word "upgrade", because it's a big change that requires a fair amount of planning, changes to features, and the upgrade will happen over a few months, with iterations.
This page defines the upgrade roadmap and tracks changes at a high level. This page is updated regularly as work progresses.
One of the issues with a big upgrade like this, is that we cannot complete freeze the website during the upgrade.
The following types of contents can be added/changed by the community:
blog post comments
job posts (once a month?)
member benefits (last added: 2018)
However, we do want to be able to change some content during the upgrade, on the Drupal8 site directly. Therefore, it should be fine to say that we:
freeze all static content (i.e. any change to pages of types that are not in the above, or at least, assume the change must be changed on the d8 site as well)
freeze all content types
and then the above contents (blogs/users/etc) will be re-imported on a regular basis.
To re-import users:
drush migrate-import upgrade_d7_user
To re-import blog posts:
drush migrate-import upgrade_d7_node_blogdrush migrate-import upgrade_d7_node_revision_blog# or, possibly more dangerous, since it could resync other content types:# drush migrate-import upgrade_d7_node_revision_blog --with-dependencies
This is to help evaluate where to focus:
> select type, count(*) from node group by type;+---------------------------+----------+| type | count(*) |+---------------------------+----------+| advisory | 94 | (done)| blog | 2447 | (done)| ccrm_case_study | 188 | <---- Important| civicamp | 19 || community_highlight | 9 || conference | 5 || demo_site | 12 || download | 4 | ?| event_detail_page | 22 || extension | 407 | (done)| extension_release_civicrm | 1506 | (done)| extension_release_cms | 54 | (deleted, was not used, & we do not allow manual releases anymore, extdir does not support non-civi modules/plugins)| faq | 2 | | feature | 11 || groups | 10 | <--- deprecate? (lists WGs, but we can point to Gitlab)| homepage_slide | 17 | (done, deleted)| homepage_stat | 4 | (done, deleted)| job | 71 | (done)| lang_reg | 2 | ?| make_it_happen | 38 || member_benefit | 15 || option | 9 | <--- simple nodes, probably embedded in some panels..?| page | 158 | (done)| sectioned_page | 5 || sponsor | 68 || story | 4 | (nodes 1147 to 1150 .. delete?)| strategic_initiative | 12 || team | 4 || webform | 42 | (delete?)| working_group | 22 |+---------------------------+----------+30 rows in set (0.00 sec)
Relies on a Drush command in 'extdir' (sudo -u aegir -H drush @civicrm.org extdir-scan)
[ x] Fix field permissions on the Extension node (i.e. do not allow changing the Extension Review Status?)
Stats extraction (for stats.c.o)
JSON feeds for the in-app extension browser / Symfony app
Views for generating the data used by the Symfony app
Now that Drupal8 is the main front-facing CMS on civicrm.org (handling user management), extensions are running from d7.civicrm.org and some requests are proxied. It's not possible to create new extensions or new extension releases, but json feeds continue to work. Need to either fix d7, or quickly port over to d8.
Things to consider:
The most important bit is the drush script that Jenkins run.
There is a fair amount of code for allowing manual creation of releases, and we could probably disable that option (only allow it for admins, for now, without validation, since it's rarely used and clunky).
Porting the views that produces the json feeds should be fairly straight forward. They had not been very much customized?
In mid-2020, as we shift our focus on Comex:
Comex would generate the feed required for Composer
Comex could feed itself off c.o, or it could feed itself from a repo with json files. Adding an extension would require doing a merge-request on the repo to add the json file.
If it helps, adding an extension node on c.o might auto-create the Gitlab project under /extensions. It would ensure that the namespace is reserved there too, and avoid dependency on ext-wg leads for creating those repos.
Remove CMS-specific releases. They haven't been used in over a year, with the exception on one item identified as a Drupal module but is actually an extension that has a WordPress bug (donation receipts).
Remove CMS-specific RSS feeds (ex: /extensions/(drupal|wordpress|backdrop|joomla)/rss) - they have zero traffic, not worth the hassle re-creating/testing them.