Evaluate a Drupal8 upgrade
Scope: evaluate (roughly) how much work would be involved in upgrading civicrm.org to Drupal8. This is only to help make a more informed decision of: do we stay on d7 for a long time, upgrade to d8, or move to WordPress.
Why: we want to enable multilingual, which is a fairly big change in the configurations. We will need to upgrade sooner or later (within 1-3 years). If we enable multilingual now, and invest non-trivial energy in translation etc, we will be further locked-in the current solution.
Activity
added status:doing label
Related #127 (moved)
-
General notes:
- Migrating nodes and content seems pretty OK. The migration had a few glitches, but issues were easy to resolve (ex: fixing input filters, blocks).
- I created a new boostrap-based theme that re-used the same CSS, and most of it seemed to port over. The d8 bootstrap theme uses a fairly similar structure, and I was able to re-add the same custom regions (although I didn't really bother with menus, but seems easy to fix).
- Views: I re-checked, and there does not seem to be a migration path. They will have to be re-created. I counted aprox. 40 views that seemed relevant (assuming we remove stuff like the Contributor Log Views, and Extension releases).
- Panels: will also have to be remade.
Example pages:
- https://d8.www-test.civicrm.org/explore-civicrm
- https://d8.www-test.civicrm.org/blog/neil/civicamp-oakland-is-april-17-18-two-days-multiple-ways-to-engage
If we were to move forward:
- We could work on a staging site without having to freeze the production site, since we will be re-creating views, fixing blocs, etc. All of those things export to Drupal's config-management (CM), so we can re-import those configs once we do the final migration.
- 60h Assuming some views are trivial, I assume it will take an average of 2h of work per view. Assuming we can focus on 30 of the most important views, that's 60h of work.
- 50h? Panels conversions (we can re-do some of the panels using something else, such as Gutenberg, which seems functional enough).
- 20h Theme: Cleanup and have feature-parity, and tweak classes which may have changed in the new design (that might be a bit optimistic of me, but so far so good).
- Porting custom code:
- 10h ccrm_extensionvalidation: Extension directory: only a small parts needs to be ported, assumes Tim works on the replacement, and that it would be ready in time.
- 5h civicrm_org_members: sumfields hook for member program? (only a few lines of code)
- 10h civicrm_org_newsfeed: does a Views hack to generate RSS feeds (not sure if it will be easily portable, although most of the Views d8 code seems very similar to d7)
- 10h civicrm_org_providers: adds badges to parters (in a custom field)
- 10h civicrm_org_stats: Populate the front end with statistics harvested from pingbacks (medium-size code base)
- 10h cividownload: download page, and a fundraising campaign that has long been disabled.
- 10h extdir:
extdir/git-urls.jsonand other services (medium-sized) - most of it should be replaced by Comex, but we may need to do more review.
Total: 60+50+20+(10+5+10+10+10+10+10) = 195 * 55 = 10,725 USD * 1.2 = 12,870 USD
Edited by bgm 
I would like to put forward that WordPress be seriously considered as the next upgrade for civicrm.org.
Compare the investment of a single D8 upgrade with WordPress migration where future WordPress upgrades do not require significant time & money investment.
Put simply, D8 is a cost which can be expected to be repeated when moving to D9, 10 etc. Whereas WordPress does not have this cost and the investment can be put into continually improving the website as opposed to simply doing a software upgrade.
Additionally, migrate to WordPress and choose from a plethora of page builders and design freedom, without having to be restricted to a limited number of Drupal tools.
There are lots of CiviCRM partners with extensive WordPress experience and with a growing user base of WordPress + CiviCRM I think this is an opportunity to show some leadership.
Anyway, just my 2c.
-
All options are on the table.
I added a pros/cons wiki page here, if people want to help evaluate that:
https://lab.civicrm.org/marketing/civicrm-website/wikis/WordPress-vs.-Drupal-8-ComparisonMinor nitpick: Drupal 9 will not be a big upgrade, just a removal of deprecated APIs. However, we don't know for Drupal 10.
Please edit the wiki page, and avoid further WP vs Drupal discussion on this issue. This issue is only about evaluating Drupal 8. If people want to help evaluate the cost for WP based on this ticket, that would be great (please open a new issue for that).
(edit: updated the wiki link)
Edited by bgm
-
@bgm thanks mate, will review the wiki page and provide input where I can.
And will stop spamming this issue.
-
My gut says Views could end up longer than 60h, while Panels would be less. Tho I've not explored it's D8 version much, if they all had to be rebuilt I’d be in favour of ditching Panels for Paragraphs, or Drupal Gutenberg (which seems quite close to stable on a brief test). Some of the CSS work arounds to get Panels to work nicely with Bootstrap and the existing theme are not great.
-
I saw this Views migration module but no idea if it’s any good.
-
Biggest headache Views imho will be Events & Partner/contributor page listings. Maybe the latter can have a bit of thought put into it - not the place to brainstorm here, but there's lots of potential for public pages to promote/present individual contributors as well as partners (and link them). What if you're an agency who needs to find a freelancer for two days quick but quite specialised work?
-
Quite a few views use PHP which I know you'd like to depracate - but in some cases (ie partner badges, which need to be fixed anyway #111 (closed)) that might need a bit of thinking/development.
-
On a smaller level it'd be nice to rejig event sponsorships to use Civi look-ups to bring the logos out, there was an issue with doing this before, but maybe it’s resolved in D8. Someone also once explained to me how Paragraphs could replace Taxonomy for Sponsor levels which might be more intuitive (this is the part of event microsites people seem to get most confused by as it's accomodating lots of different use-cases).
-
CSS migration point: at the moment a lot of CSS is in new.css, which was started I think when Back Office began work on the new site and then continued by me. Midway thru it's creation there was a structural shift from trying to be really specific (ie
.page-name .region-name .div-name) to being as generic as possible, whereever possible, to encourage re-usable and consistant design elements and reduce file size & design time (e.g..blue-box,.250-w-image,.0-padding-top,.green.large.button, etc). But only some of new.css & site layout is like this so it would be nice to use a migration as a chance to create a newer-new.css :) with clear, consistent structure, applying generic classes where possible (obvs sometimes it's impossible) from the start, and then move stuff from new.css with the goal of depracating that file and (and the inheritted css from the even older website). Happy to document that in more depth somewhere. -
In general if things were being rebuilt it'd be nice to use CiviCRM more (e.g. author bio block at the foot of blogs), or at least have that as a goal on a new site roadmap.
-
mentioned in issue extensions/extensions-directory#38
Just wanted to pass an interesting note from @eileen that her usual migration strategy involves setting up two sites (like D7+D8 or D7+WP site) with a shared Civi DB for a period of months (which allows you to deal with some transition elements more incrementally).
changed milestone to %CiviCRM Website Upgrade
-
@ayduns I would be curious as well, but as for WP, we would have to rely on estimates provided by the community (and willing to participate in the development).
How is i18n in Backdrop? Is it better than in Drupal7?
Seconding @ayduns suggestion here! Drupal 7 can be upgraded to Backdrop, with content, comments, users and views all very upgradable, which could certainly help to achieve this upgrade with more limited resources, both time and money.
In https://lab.civicrm.org/marketing/civicrm-website/wikis/WordPress-vs.-Drupal-8-Comparison, I would argue the WordPress Pro's have been overstated:
- the Drupal-CiviCRM community is probably wider than the WordPress-CiviRVM community (certainly not the other way around)
- there also are full-page editors for Drupal, including Gutenberg and the Glazed theme (which I can vouch for)
- the long term maintenance costs are debatable - WordPress plugins are usually less maintained over time, less stable, and less integrated with other plugins than Drupal modules
- improvements to the WordPress integration would probably be made primarely for specific commercial plugins (ie. Caldera, Gravity Forms, ...) rather than for core WP, therefore with much less interest for the Community than D8-Civi improvements that would be made for the core Drupal integration (ie. entity, views, rules, etc).
Not trying to bash WordPress, just bringing some balance in our evaluation. Please also see my other post suggesting that we consider building different parts of our new website with the most adequate system rather than choose one to rule them all (pun intended).
-
Hi Nicolas,
there also are full-page editors for Drupal, including Gutenberg and the Glazed theme (which I can vouch for)
Just to confirm: are you using it in production, and do you think it would work for CiviCRM.org?
And to clarify: even if we went the WP route, we would only use Formbuilder/afform.
If you can help validate the estimates or assumptions I did, that would be great (#130 (comment 18905)).
I am not familiar enough with the existing website to back your estimate one way or another. With respect to Glazed, we have used it for a client's website and have been delighted. We are now rebuilding our own website using this tool as well. There is a 2 minutes overview at https://www.sooperthemes.com/drupal-modules/glazed-builder that really shows how the tool works - I don't know Gutenberg enough for a full comparison, but it seems to be richer with more widgets, and more options for each widget. It is truly drag from a palette, drop and /edit in place with the palette having layout, widgets, icons, effects, etc.
Additional discussion happening here #141 (closed)
-
I updated my cost evaluation comment above with:
- Estimates for custom code (taking into account Comex)
- Proposal to use Gutenberg as a Panels replacement
- I did a fair amount of testing on d8 for a very-picky client project
- It looks like a good solution, stable, feature-complete; it's equivalent to other solutions out there, and has the potential of wider community support, less vendor lock-in, and better portability with WordPress and other CMSes supporting it)
- Although bottom line: there are layout builders for d8 that are less of a pain than Panels, which is great news. The exact choice doesn't really matter at this point, as it should not radically change the estimate.
My overall opinion on this is that it's possible to use either drupal or wordpress and build a site that will meet our needs and probably there is not one 'right' decision. I think either can build a multilingual site that better addresses our marketing needs.
I probably do lean word press - because I feel like WP has better usability on the CMS side & I think there are multiple options on the Civi side including improving our CMS-agnostic-ness and getting feeds off existing drupal views on the 'old' d7 site.
However I think the bike-shedding about technology would be better put into site design
-
If I understand correctly, you are proposing to start a new site from scratch, and let users, civicrm contribution/event forms, on the d7 site? (we may be able to use remoteforms or formbuilder eventually to embed forms)
(I would still prefer to see discussion about WP in a separate issue, with separate estimate, since this issue is about estimating a d8 upgrade)
removed status:doing label
-
OK, thanks for all the feedback.
I will close this issue since the estimate is done.
I'll let the discussion about the choice of CMS happen in another issue. Either #141 (closed) or other. This evaluation can probably be applicable to Backdrop or WordPress, since the process is pretty much the same, and they have tools to migrate users.
While I feel there is a lot of ambivalence out there, there seems to be more preference for WordPress, little support for Drupal8. It might be bike-shedding, but the decision needs to be taken.
Either way, I will evaluate options to run two sites in parallel. I'm really not a fan, but it otherwise seems impossible to do a CMS upgrade, new design, new content, new languages, in a reasonable time frame. If we identify a few features/pages to focus on, we can create an minimum viable product and get it up and running, and have nginx proxy between either site, depending on the URL.
mentioned in issue #141 (closed)
mentioned in issue #152 (closed)
