Print

Print


Hi, we (Southampton) are in a similar position, but not quite as committed. We have a 3 year project called "oneweb" to try to make a single unified website for external viewers. Our main sites are not on Drupal, but we have a good number of research group, school and project sites on Drupal 7.


We don't yet have a formal plan for D7, but for now my approach is:

- resist creating new D7 sites

- work to transition existing D7 sites to the new world order that is oneweb (which may well be D8, but this isn't set in stone yet)
- work to retire or fossilise* most of the other sites.


* I use fossilise to refer to the process of converting a website into simple .html files which can be served forever unaltered. We now place a BBC-style "this site is archived" on such sites too. http://www2006.org/ (see the bottom of the window)


The majority of public facing uni sites are either for parts of the organisation (group, school, dept, faculty, whatnot) or for research projects which have a "main sequence" and after that need preservation but no longer get updated. I've been looking at the "endgame" for such sites and have a blog post here; http://blog.soton.ac.uk/webteam/2019/01/30/life-cycle-of-a-university-website/ (If you attend my workshop at IWMW19 please pretend to look surprised as this is what I'll be basing part of it on!)


For the few sites that inevitably can't be refreshed (recreated) on the new platform, shut off, or made into static files we need to be more clever. We can reduce the risk a lot by putting in either a proxy which blocks all requests with CGI parameters or using a very aggressive setting on apache's mod_security. However, Drupal plugins can get external information through the URL path itself so that's not 100% solution.


What we don't have is a plan on how to just migrate with a tool or something. We have a mixture of sites just running vanilla D7 templates, custom ones and a number using a corporate brand template we made which uses a node per section which was an OK approach but makes versioning and previewing into a mess. If we had it over we'd use the "paragraph" plugin.


If we have enough corporate sites needing moving over I expect we'll find an import plugin for our new platform and I'll write an export tool to be as lossless as possible, and hopefully pictures and other files can copy from D7 to D8 somehow...



On 22/03/2019 10:20, Jamie Giberti wrote:
[log in to unmask]">
Hi everyone,

Here at Cambridge we have a vast number of Drupal 7 websites (in the 100's). 

We're exploring options for the transition to Drupal 8 as we will still need to be able to host a vast number of sites in a scalable fashion, both for performance and for security upgrades / patching. 

If anyone is already doing this (or is in the middle of planning to do this), it would be great to discuss it with you.

Thanks very much,

Jamie

------------------

Jamie Giberti

Drupal Service Manager

Service Catalogue Service Manager

University Information Services

University of Cambridge



To unsubscribe from the WEBSITE-INFO-MGT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=WEBSITE-INFO-MGT&A=1

-- 
Christopher Gutteridge <[log in to unmask]> 
You should read our team blog at http://blog.soton.ac.uk/webteam/


To unsubscribe from the WEBSITE-INFO-MGT list, click the following link:
https://www.jiscmail.ac.uk/cgi-bin/webadmin?SUBED1=WEBSITE-INFO-MGT&A=1