Trashing Drupal

Submitted by Anonymous (not verified) on Fri, 11/09/2015 - 09:20

<p>At heart Drupal is an awesome CMS. The reason I would advise going for Drupal over any other framework is it’s ability to manage a scalable amount of content entities.</p><!-- more --><p>Earlier this week I discussed <a href="…; target="_blank">revisions in Drupal 8</a>. Specifically the use of <a href="; target="_blank">Multiversion</a> module to allow Drupal to use a CRAP (Create Read Archive Purge) workflow for content management.</p><p>Since then I have been working on the archive and purge aspects of this workflow. The <a href="; target="_blank">Multiversion</a> module is pretty astonishing in how it revolutionises the way revisions are handled and content is managed but so far there has been little focus on the archive and purge process. When entities are deleted they are simply flagged as “deleted”, they exist in the Drupal database but are gone from any where on the site’s UI. Until now&hellip;</p><p>The all-new <a href="; target="_blank">Trash</a> module builds on the <a href="; target="_blank">Multiversion</a> module provide a place where users can see all their deleted entities, listed by entity type, then restore them along with all their revisions. The first commit on the 8.x-1.x branch was only done 3 days ago on September 8th, so it’s still early days, but the MVP is available as a dev release to have a play with.</p><p>Now, this is more or less the archive process working, next up is purge. So what do we purge? Well, ideally, nothing. It’d be great if we never need to truly delete any entities, but instead purge specific revisions. This is something that will be getting a lot of thought over the coming weeks.</p><p>Another step to look at is compaction. <a href="; target="_blank">Multiversion</a> has been following CouchDB’s API and coupled with the <a href="; target="_blank">Relaxed web services</a> module it allows entities to be replicated to CouchDB and other platforms following the same API. <a href="; target="_blank">CouchDB has a notion of compaction</a> via the “_compact” endpoint. How harshly should the content be compacted? remove all revisions apart from the current one?</p><p>All of this will be discussed by <a href="; target="_blank">Dick Olsson</a> and I, in our session <a href="…; target="_blank">Planning for CRAP and entity revisions everywhere in core</a> at <a href="; target="_blank">Drupalcon Barcelona</a>.</p>

Add new comment