Scope
Blog posts / updates
Design philosophy
Tasks
Custom code
Content updates during the migration, or in what sequence to we update content
Content-type stats
Webforms
Regular resyncs (disabled since 2020-04-05)
Extension directory
Time tracking

Scope

~~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.

Blog posts / updates

2020-04-05 : https://civicrm.org/blog/bgm/progress-civicrmorg-drupal8-upgrade
2019-09-05 : https://civicrm.org/blog/bgm/upgrade-and-translation-plan-for-the-civicrmorg-website

Design philosophy

Keep using a Bootstrap-based solution (v3 or v4) - because everyone knows it, and it's CMS-neutral.
Avoid CMS-specific plugins
- Promote the CiviCRM Contact dashboard, instead of a CMS user dashboard
- All forms must be managed by CiviCRM or CiviCRM extensions (ex: formbuilder, but not webform).
Avoid creating CMS-specific plugins for custom code. Migrate them to CiviCRM extensions as much as possible. Reduce the quantity of custom code as much as possible.
Multi-lingual - it should be possible to easily translate all content.
Adding content should be easy (not require knowledge of HTML, easy to upload images).
Document features - main features must have a short wiki page describing how it was built, for the next contributor.
Keep it simple - minimal use of plugins.
Make it easy to add blog, comments, civicamp content, but strong gate-keeping of content (request updates via the website issue queue).
Identify a page/layout builder that offers fixed layouts (define a layout for content "a", "b" and "c", enforces some consistency)

Tasks

Custom code

ccrm_extensionvalidation: Mostly removed by removing the possibility to release manually. See also: extensions/extensions-directory#45
civicrm_org_members: sumfields hook for member program? (only a few lines of code)
#185 (closed) civicrm_org_newsfeed: does a Views hack to generate RSS feeds. Incorporated into the civiorg8 custom module.
civicrm_org_providers: adds badges to parters (in a custom field)
civicrm_org_stats: d7 tokens for content - deprecated / not ported
civicrm_org_stats: extensions/extensions-directory#14 (closed) updates extension usage stats
cividownload: download page, and a fundraising campaign that has long been disabled. It's now a blog that is incorporated in a Gutenberg page. Code is in civiorg8.
extdir: extdir/git-urls.json and other services (medium-sized) - most of it should be replaced by Comex, but we may need to do more review.

Content updates during the migration, or in what sequence to we update content

Content-type stats

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)

Webforms

Todo:

CRM for non-profits, what drives uptake?, 2019-04 survey
Beyond English: improving internationalization in CiviCRM, last responses in 2019-08, survey

Done:

#209 Register a site, very active
Keep in touch with CiviCRM, newsletter/security signup form, still used. - Now redirects to /civicrm/mailing/subscribe.

Queued for deletion, deleted, or redirected:

Regular resyncs (disabled since 2020-04-05)

This was happening every 2h so that we could sync the blog/users to Drupal8. It was disabled on 2020-04-05, now that the Drupal8 site is the canonical version for content.

drush migrate-import upgrade_d7_user --update
drush migrate-import upgrade_d7_node_blog --update
drush migrate-import upgrade_d7_url_alias --update

NB: there is a node using the alias /blog and it's breaking the blog view. We should delete it on the d7 site once /blog is served from d8, so that the resync does not break the d8 view.

Extension directory

Drupal7 setup to port to Drupal8:

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.

Short-term changes:

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.

Time tracking

use: civi/w8 (website drupal 8 upgrade)

website tech revamp