Running on Drupal 8 - On Drupal 8 since Alpha 3, a PHP and Drupal developer, thoughts and experiences with D8 en Bursting the Drupal Bubble <span>Bursting the Drupal Bubble</span> <span><span>chrishu</span></span> <span>Sat, 02/25/2017 - 19:16</span> <div><h2>Introduction</h2> <p>I have been working with Drupal for over six years now, for much of that period exclusively working with Drupal as an employee or in a freelance/contract role.</p> <p>Prior to the start of Drupal 8, the nearest thing I manged to <a href="">getting off of the island </a> was periods of doing something completely different (Expression Engine, Django, a custom PHP framework, attending a Silverstripe conference), usually because of an existing or already started/inherited project connected with the Drupally people I was working with.</p> <p>These sabbaticals were reasonably short, however often instructive and enjoyable, in some cases (not all) the feeling was 'could have been better done in Drupal', they were a complete break from Drupal.</p> <p>I have just finished ten months of working on a Symfony based project and things are very different. </p> <h2>Bursting the Drupal Bubble</h2> <p>For almost a year, I have not been doing Drupal, but also so busy and involved learning more about Symfony, Angular 2 and other technologies that I have not had time or capacity to attend Drupal events, meetups etc. </p> <p>Although working with a group of people that had all used Drupal a lot before (amongst other things), Drupal was very rarely mentioned, not one person said 'this could have been done better in Drupal' in fact the only time that really came up at all was in reference to other client systems that were integrating with what we were building.</p> <p>I needed to burst the bubble, forget about Drupal and whilst working on something different spend my time thinking about that.</p> <p>The bubble I am referring to is thinking about everything in the context of Drupal, even the proudly invented elsewhere bits in Drupal 8. This kind of thinking can perhaps have the same bad effects as the echo chambers on social networks where everyone you are connected to has essentially the same or similar references and experiences.</p> <p>There is a possibility that the next contract I do will not be Drupal either.</p> <h2>Drupal is still there</h2> <p>Using Symfony and anything using Symfony components (Laravel may be next) still increases knowledge and skills related to Drupal (before 8 anything elsewhere just meant Drupal relevant knowledge was fading over time). Having used the Symfony console a lot and written commands for it, I will be pouncing on the <a href="">Drupal Console</a> when I do my next piece of Drupal work for example (which is more than I can say for Drush).</p> <p>I am clearer about what I think Drupal strengths are though. I current have two personal projects I want to start/finish, one is a match for Drupal one for Symfony.</p> <h2>Conclusion</h2> <p>Mileage may differ for other people, I found I had to put Drupal to one side for a while, it is all very well getting off the Island but that is not quite so effective if you remain in an Island culture ghetto somewhere on the mainland and don't fully integrate for a while. Some people will have no need to ever get off at all, we all have different stories to tell.</p> <p>However if you do come across some work that would be better done in something else, will you even know? If you do know will you have the courage to burst the bubble?</p></div> <section id="comment-section" > <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=39&amp;2=comment&amp;3=comment" token="830f3ce1"></drupal-render-placeholder> </section> Sat, 25 Feb 2017 19:16:02 +0000 chrishu 39 at Drupal has historically been an abstraction from the front-end <span>Drupal has historically been an abstraction from the front-end</span> <span><span>chrishu</span></span> <span>Sat, 02/20/2016 - 16:34</span> <div><h2>Introduction</h2> <p>For the purposes of this post Drupal is a content management system to produce web-sites (other use-cases are available ;)).</p> <p>Some opposition to the major re-factoring of code for Drupal argued the new code-base contained too much abstraction.</p> <p>The abstraction argument, I didn't get it. Abstraction from what? Abstraction from the internals of Drupal?</p> <p>The main losers in the re-factoring of code from D7 -&gt; D8 are the those of us who have invested a long time learning those internals and 'Drupalisms', I can understand that, I have learned a lot of this information that will become worthless. That is true of so much else over my time as a developer though and I am more than compensated by the expansion of the new things I am learning into other related technologies and being able to bring things I have learned elsewhere into working with Drupal 8.</p> <p>I use Drupal to manage content and build websites, Drupal in itself is not a means to an end.</p> <p>For the longest time however Drupal has been a <strong>major abstraction from the front-end</strong> and that has been both a blessing and a curse.</p> <h2>A blessing</h2> <p>For a <a href="">Site Builder</a> (follow the link to see what I mean) the fact that Drupal outputs HTML, CSS and JavaScript for all the things that you can configure in admin is a huge plus, it may even be possible to obtain a theme that gets you most of the way to what you want.</p> <p>The various complications and varied expectations over layout and content that have evolved over the years with the Web can even be catered with via imaginative use of Views and Panels (with a whole host of magical configurable layout thingies etc.). Or perhaps a theme that implements a framework or a grid layout with a gazillion themes settings.</p> <p>Drupal 8 should make this experience even smoother, although right now you might be missing some of your favourite contrib. modules.</p> <p>With enough enough modules, themes, etc. perhaps you don't even need any front-end development if your requirements are not too custom right? But then Drupal becomes a machine replacing the front-end developer, a big ask, especially with fast pace of evolution in this business.</p> <p>For some back-end developers who are more interested in content structure, transfer, APIs to other systems as well, all is good too, a front-end is better than no front-end and they may not be so focused on front-end anyway.</p> <h2>A curse</h2> <p>If you are a front-end developer, you may well be at the place where evolution is happening fastest. A few years ago you didn't have linters, pre-processors, frameworks, package managers etc. etc. There is always more to learn about UX, accessibility, always new devices and different ways of viewing the same page.</p> <p>In many places there is no longer a ridiculous system of 'drawing webpages' in Photoshop.  Wireframes and HTML prototypes are used and if you have the skills and knowledge the prototype is largely production standard anyway.</p> <p>So when you are looking for a system to manage content, to make that prototype dynamic you want a tool to help you fill in the hard-coded bits. There are frameworks and systems that will let you do that, using the code and techniques that you know to 'frame the content' (they may not be quite as good as Drupal at managing content however).</p> <p>When you come to Drupal you may hit a wall! 'Drupal is the king of content my young Padawan'. 'But how.. what ... uggg I didn't write that...., which hook, sorry HOOK errr hook_this_HOOK, help, theme.. Theme THEME.</p> <p>"Don't worry young Padawan, don't think of the Drupal learning curve as a line, more like a .... cinammon swirl'."Why are you trying to do that by hand anyway? Use a micro, mini, panelizer, panel, view pane, custom page context, it will only take you a day (or three) to configure that bit in the admin section".</p> <p>"It didn't wooooork!".</p> <p>"Tut tut did you pre-process it?".</p> <p>"HOORAY I finally have it!"</p> <p>"Not so fast young Padwan, Drupal coding standards you have ignored!!! tsk tsk tsk".</p> <h2>Somewhere in the middle</h2> <p>And of course there is everything in between, every shade under the sun. Themes and approaches that strip everything back that Drupal so generously gives. Front-end developers clinging precariously to what Drupal outputs, enlightened souls prepared to help all, and jealous guardians of the knowledge they have obtained whilst travelling though the 'cinnamon swirl learning curve'.</p> <h2>And next?</h2> <p>Well Drupal 8 is different, I don't quite have my own personal answer to what comes next yet but getting there. Twig, common approaches, not invented here etc. should make everything different, but a lot of what I am seeing out there still seems to have a pre-d8 mindset behind it.</p> <p>Not very satisfactory I know, I can tell you my goal. It is simply to have an approach, some examples, documentation and a plan that would enable me to introduce D8 into a skilled agency and for people to be productive in days, and for a large project to be succesful with only a minimal amount of 'specialised' Drupal expertise added to the project after that. </p> <p>Not much to ask?</p> </div> <section id="comment-section" > <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=38&amp;2=comment&amp;3=comment" token="2236b80f"></drupal-render-placeholder> </section> Sat, 20 Feb 2016 16:34:02 +0000 chrishu 38 at Twig extends and a D8 Twig Block base theme <span>Twig extends and a D8 Twig Block base theme</span> <span><span>chrishu</span></span> <span>Mon, 02/01/2016 - 12:55</span> <div><h2>Introduction</h2> <p>Twig Blocks and the extend functionality can be used to stop needless repetition.</p> <p>I have posted before about <a href="">Twig Blocks and Drupal</a> and experimented a little with a <a href="">theme on Github</a> used as the base theme for this site, I also <a href="">raised an issue</a> for consideration of Twig blocks to be added to Core templates as I felt that without them D8 theming had slightly missed a trick (admittedly far too close to the release).</p> <p>Fortunately the late addition of the <a href="">Stable theme</a> to D8 makes it much easier to experiment with alternative approaches to theming plus allows Core mark-up to evolve much faster than the Drupal release cycle (without arbitrarily breaking existing themes).</p> <h2>Copy of Stable with Twig blocks</h2> <p>Stable is/was a copy of the Drupal core templates that will not change, it is the default base theme for every theme that does not define a specific base theme unless <code>base theme: false</code> is set in the info file (which would leave you vulnerable to any changes in core templates, CSS and JS over the D8 life-cycle).</p> <p>I have made <a href="">a copy of Stable called Blocky</a> and marked up some of the templates with Twig Blocks, which doesn't change the functionality of the theme at all but does allow more selective override of templates directly, after inspecting what blocks are available. For a simple example an alternative node template can just override the mark-up of the title leaving the rest of the parent template mark-up alone (no need to slavishly copy all the bits you don't want to change).</p> <pre> {% extends "@blocky/content/node.html.twig" %} {% block node_title %} {{ title_prefix }} {% if not page %} &lt;h3{{ title_attributes }}&gt; &lt;a href="{{ url }}" rel="bookmark"&gt;{{ label }}&lt;/a&gt; &lt;/h3&gt; {% endif %} {{ title_suffix }} {% endblock node_title %} </pre> <p>Of course Blocky could always just be used as the basis of another copy, providing a more customised theme with the ability to use <a href="">Twig extends</a> (do read the official documentation for extends if you haven't used it before). You may have many variations of node templates, any change to boilerplate mark-up that is not generally overridden in child templates only has to be modified once in the parent template that all the others are extending.</p> <h2>Extends is not just for Twig Blocks</h2> <p>Extends allows for adding variables via the child that are then available in the parent template. A child template can affect the parent template or provide new variables to the parent opening up new possibilities for Drupal 8 theming strategies even without using Twig Blocks.</p> <p>Classy already does this in one or two places now, for example the meat of the Classy field--field-text.htm.twig is as follows:</p> <pre> {% extends "field.html.twig" %} {% set attributes = attributes.addClass('clearfix', 'text-formatted') %} </pre> <p>In this case a more specific template is adding a class to it's general parent template without having to repeat mark-up. Is your brain starting to whir? Potential new approaches to theming? Excited?</p> <h2>Taking it further</h2> <p>Unfortunately I have not found a client project that is suitable for Drupal 8 yet so experimentation is in free-time. I am hoping to move another blog to Sculpin and then work on a better theme for that and this site that share as much as possible.</p> <p>Even with Twig Blocks Drupal still has a fairly linear approach to building the front-end, so approaches sometimes used by other frameworks with Twig or Twig like template syntax will need a bit more head-scratching. For example a common approach used elsewhere would use parent layout templates that are never directly rendered, just extended. These layout templates may well have empty Twig Blocks (the main events) that are filled in further down the chain. A Drupally equivalent might be an html.html.twig template that has an empty 'page' block rather than kicking off the rendering of the page by outputting $page. This template could then be extended by multiple variations of page. <strong>Note: </strong>this approach will not currently work in Drupal but 'should' be possible digging around in pre-processing etc. (well it feels like it should).</p> <p>Twig has some other tricks like <a href="">embed</a> and the simpler <a href="">include</a> and these along with extends can utilise conditionals and variables.... OMG the potential approaches to theming Drupal have increased exponentially!!! :).</p> <p> </p> </div> <section id="comment-section" > <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=36&amp;2=comment&amp;3=comment" token="5bda9a5e"></drupal-render-placeholder> </section> Mon, 01 Feb 2016 12:55:12 +0000 chrishu 36 at Upgrading ancient Drupal 8 sites via SQL <span>Upgrading ancient Drupal 8 sites via SQL</span> <span><span>chrishu</span></span> <span>Sat, 01/02/2016 - 09:02</span> <div><h2>Introduction</h2> <p>Ok perhaps 'ancient' is somewhat of an exaggeration, however the first post on this blog was back in 2013 (where did the time go??). Early engagement with Drupal 8 was a mixed blessing, it is hard to maintain energy for such a time, in late 2013 it seemed just around the corner, however although my investigations have been sporadic I have learned a lot during the evolution.</p> <p>Now it is finally here though I thought starting 2016 with an upgrade to 8.01 was a good start, having a stable set of APIs makes a huge difference, looking forward to 2016 and some more exciting developments.</p> <p>One thing you quickly discover chasing D8 through the early days is that commits and changes to the core code would break your site on a daily basis ('chasing head' is not viable), also you can't install interesting modules as they come up as on 'your' site they break everything. I found (via painful trial and error) that for me migrating everything via the database with SQL was the best approach to updating the code base.</p> <p>I can't be the only person who started blogging early on D8, maybe this option is viable for somebody else. At the very least it highlights an important lesson about abstraction I think.</p> <h2>SQL to the rescue</h2> <p>Once I got past the point where cut and paste to a new Drupal 8 site was a pain (even more so with comments etc.). I found that interacting directly with the database was the least painful option to get things working on new code, a lot of the back-story behind that and a few pointers are to be found at <a href=""></a>. For the transition to 2016 I just had to migrate from a beta code-base to 8.01 which was a bit simpler and more refined.</p> <p>My basic strategy was to:</p> <ul><li>Make a new empty site</li> <li>Configure the site as before (slogan etc.)</li> <li>Add modules (Honeypot) that I used before</li> <li>Add my theme (took some rework, but that is another story).</li> <li>Import the original database into another database (called old).</li> <li>Get a mysql command line up and start, comparing/investigating/inserting from old database.</li> </ul><p>It makes things much easier if the the new site is empty and you can use the same node ids etc.</p> <p>For example the <a href="">exact SQL</a> I used this time around to go from a late Beta to 8.01</p> <p>All 'ancient' Drupal 8 sites will be different (depending on the exact point of time they are stuck in). For somebody confident with SQL it may offer the best hope of migrating content to a shiny new Drupal.</p> <h2>Alternatives</h2> <p>This approach requires familiarity with SQL, I guess my next approach would have been to look at the migration code already being built to migrate D6 to D8 and build something around that, however as stated in the previous original post linked to above I was in need of a break from doing to much D7 migration, I suspect also that although it would be more elegant, that would be too much work for a one-off.</p> <p>I did briefly look at the <a href="">Head to Head module</a> but it looked like that would require fiddling and hacking to get it to work, whereas I could roughly judge the effort required via SQL, doesn't seem like it offers anything for truly 'ancient' sites either.</p> <h2>Conclusion</h2> <p>One of the reasons given for the <a href="">Backdrop fork</a> was the increasing layers of abstraction appearing in Drupal, however really abstractions are the only way to meet the increasingly complex requirements of software and digital services. SQL and interfacing with the database directly is abstracted away in modern CMS/frameworks. When I was first making content management systems however, you were more likely to be writing your own and it all started with designing the database structure and implementing in SQL.</p> <p>That database layer is still there, in fact the lack of complex foreign key constraints (enforcing data integrity, something delegated to a higher level now) makes it easier to build up a data tables from scratch.</p> <p>Really it is abstractions all the way down but nice to know that ultimately there it always the database to get access to your data......</p> <p>Do test however ;)</p> </div> <section id="comment-section" > <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=35&amp;2=comment&amp;3=comment" token="63e1112d"></drupal-render-placeholder> </section> Sat, 02 Jan 2016 09:02:31 +0000 chrishu 35 at Drupal Site Builder role <span>Drupal Site Builder role</span> <span><span>chrishu</span></span> <span>Mon, 11/16/2015 - 08:59</span> Mon, 16 Nov 2015 08:59:38 +0000 chrishu 32 at Twig Blocks and Drupal <span>Twig Blocks and Drupal</span> <span><span>chrishu</span></span> <span>Fri, 05/29/2015 - 17:16</span> Fri, 29 May 2015 17:16:02 +0000 chrishu 31 at Responsive Breakpoints in D8, the breakdown <span>Responsive Breakpoints in D8, the breakdown</span> <span><span>chrishu</span></span> <span>Mon, 04/13/2015 - 12:00</span> Mon, 13 Apr 2015 12:00:01 +0000 chrishu 29 at D8 theming first impression <span>D8 theming first impression</span> <span><span>chrishu</span></span> <span>Thu, 03/26/2015 - 20:11</span> <div><h2>Introduction</h2> <p>After upgrading this site to a nice shiny Beta, I was itching to try themeing on Drupal 8, I have left off up to now as a few simple experiments showed me that even a simple sub-theme broke quickly under the pace of Drupal change, now though I should be able to upgrade any efforts and improvements without too much difficulty.</p> <p>I theme Drupal every now and again and spend more time doing back-end and server related work, I usually have to have a good understanding of the mechanics of the themeing though even when not actively doing it. </p> <p>Often in the past I have been at odds with the themeing philosophy of teams I am working with (and have had to capitulate when outnumbered ;)) as I am more in the camp and would rather strip out most of the guff that Drupal inserts and break away from the 'rails' that make many Drupal sites turn out kind of samey apparently the <a href="" target="_blank">33% camp</a>.</p> <p>Also when working with talented front-end developers who don't necessarily deal mostly with Drupal it seems such a shame to clip their wings, I would rather try and start with a theme like <a href="" target="_blank">Mothership</a>.</p> <h2>The challenge</h2> <p>The assumption I had was that Drupal 8 will be much easier to customise and "go your own way" than Drupal has ever been before. The mini-challenge I set myself was to re-implement the look from another site <a href="" target="_blank"></a>  which runs on ExpressionEngine and use the same CSS stylesheet verbatim (<s>in the end I changed one line</s> the stylesheets are now identical). </p> <p>The theme is pretty basic, based on Bootstrap 3, but even despite that has a few elements of structure that are not very Drupally, so made an interesting experiment.</p> <p>More than enough for my first attempt.</p> <h2>The result</h2> <p>Well this site no longer looks like a purple Bartik, and does bear more than a passing resemblance to the site I ripped the CSS from.</p> <p>It was pretty easy to restructure things and Twig theming in Drupal is a massive improvement, I am now convinced that Drupal 8 wins hands down over Drupal 7 for themeability.</p> <p>There is still a lot more stuff I could strip out, this was a first pass, I am going to take a breather and come back to it. I have a couple of style-sheets left from Drupal to keep the in-line editing and admin stuff (mostly) working. I would prefer to target those bits more selectively.</p> <p>The <a href="" target="_blank">theme is on Github</a>, just for interest and comparison at the moment, but depending on later experiments might turn into something more generically useful. </p> <h2>Still a few glitches</h2> <p>It is a bit difficult working out if I have done something wrong or whether I am encountering bugs in the Beta, I will take the time to find out if issues have been raised when I get the chance. There are problems, for example for an anonymous user the home link is always active and some blocks seem to leave a trace even when turned off for a page (which messes with detecting whether a sidebar is active for example), both of these problems also exhibit in Bartik though.</p> <p>I plucked the theme from my site at and needs a lot of work anyway, I am hoping to improve both sites in tandem now. </p> <h2>Update</h2> <p>Just to make it clear the thing that remained the same from the ExpressionEngine site was the CSS, this is significant in that it was just as easy (well a lot easier really) to change the structure of the HTML to match the CSS as to take the approach I have often seen with Drupal 7 and below which is to abuse CSS over the top of whatever Drupal is outputting by default and then attempt to find out how to alter the last few bits (the title is being displayed somewhere odd on the page etc.) always numerous and sometimes arcane ways to do this. </p> <p>So it for example you were supplied with accessible, useable html templates, or a implementation based on a new frontend framework; that no longer needs to be a show stopper or time-sink, you should be able to easily rework Drupal to use them just through the Twig template and perhaps a little pre-processing in your .theme file.</p> <p>The comment about Craft below is extra interesting though as Craft uses Twig. Wordpress can also be easily made to use Twig, Django uses something that is very similar (in fact the inspiration for Twig). There should and could be a lot more mobility of frontend work across all these environments and anything similar. There won't be a direct one to one mapping of templates (although an agency could in theory put effort in to make that almost a reality for a couple of their favorite CMS solutions).</p> <p> </p> </div> <section id="comment-section" > <h2>Comments</h2> <a id="comment-12202"></a> <article class="comment"> <header class="comment-header"> <p><strong><span>Chris Weber (not verified)</span></strong><br /> Fri, 03/27/2015 - 04:03</p> </header> <div class="content"> <h4><a href="/comment/12202#comment-12202" class="permalink" rel="bookmark" hreflang="en">Retry with Craft</a></h4> <div><p>You should try the same experiment with EE's "next generation", Craft. It would be interesting to see if you could reuse some what what you did with Drupal's 8 templates in Craft. </p> <p>Can you share the code for your templates. I work with folks that are really into Craft and it would be great to show them that jumping onto Drupal 8 projects will be doable in the future.</p> </div> </div> <footer class="comment-footer"> <nav><drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=12202&amp;1=default&amp;2=en&amp;3=" token="9538f86e"></drupal-render-placeholder></nav> </footer> </article> <div class="indented"><a id="comment-12203"></a> <article class="comment"> <header class="comment-header"> <p><strong><span>chrishu</span></strong><br /> Fri, 03/27/2015 - 06:51</p> <p class="comment-parent visually-hidden">In reply to <a href="/comment/12202#comment-12202" class="permalink" rel="bookmark" hreflang="en">Retry with Craft</a> by <span>Chris Weber (not verified)</span></p> </header> <div class="content"> <h4><a href="/comment/12203#comment-12203" class="permalink" rel="bookmark" hreflang="en">Craft looks interesting</a></h4> <div><p>Craft uses Twig I believe, there won't be a one to one mapping of templates (see my update to the post above) but could be a fairly easy transitioning, ultimately the structure of the HTML and CSS is what is important and you shouldn't have too many things getting in the way. </p> <p>I a week or so I will be elaborating a bit more on this, I will also have a close look at Craft.</p></div> </div> <footer class="comment-footer"> <nav><drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=12203&amp;1=default&amp;2=en&amp;3=" token="36aed022"></drupal-render-placeholder></nav> </footer> </article> </div><a id="comment-13165"></a> <article class="comment"> <header class="comment-header"> <p><strong><span>Jazz Kite (not verified)</span></strong><br /> Tue, 12/01/2015 - 12:26</p> </header> <div class="content"> <h4><a href="/comment/13165#comment-13165" class="permalink" rel="bookmark" hreflang="en">Good </a></h4> <div><p>This is good article for learning.</p> </div> </div> <footer class="comment-footer"> <nav><drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=13165&amp;1=default&amp;2=en&amp;3=" token="14c68350"></drupal-render-placeholder></nav> </footer> </article> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=28&amp;2=comment&amp;3=comment" token="65254ef4"></drupal-render-placeholder> </section> Thu, 26 Mar 2015 20:11:06 +0000 chrishu 28 at D8 blog Alpha to Beta migration <span>D8 blog Alpha to Beta migration</span> <span><span>chrishu</span></span> <span>Sun, 03/15/2015 - 15:08</span> <div><h2>Still running on Drupal 8</h2> <p>Somewhat shocked to find that I have been running on Drupal 8 for well over 1.5 years now, not surprisingly the sense of urgency has kind of dropped off, but getting back into Drupal 8 again now. This site was originally based on Alpha 3  D8 and I even tried 'chasing head' for one iteratation, so it was alpha 3 with some crazy ass fixes.</p> <p>Then I got a bit experimental, customised a couple of things etc. and fixed the brokeness that kept happening. Utimately as I focused on it again (whilst having experimented a little on dev site with Beta 3 in preparation for migration), I touched something and it went poof! I am somewhat used to the <em>white screen of death</em> on this site even the <em>white screen of death</em> that doesn't fix itself when you rollback the database, this time I didn't want to roll up my sleaves and attempt a fix, as far as I was concerned my site was the <a href="" target="_blank">Norwegian Blue Parrot</a> of Drupal installs.</p> <p>Note: if working on a non-supported version of D8 kittens don't die if you hack core, in fact coping with Drupageddon etc. they are more likely to die if you don't.</p> <h2>Alpha to Beta problem, Mysql to the rescue</h2> <p>A quick assessment of options, I could look at the migration code already in D8 and attempt something but two things stopped me, firstly I have spent a lot of time working on D6 - D7 and D7 - D7 migrations recently and great though it is I am sick of it, secondly I needed something really quick, I had very little spare time over the next week, I slapped up a new site on a shiny new Ubuntu 14.04 VPS and <a href="/blog/site-down" target="_blank">posted a page </a>to explain what was going on. </p> <p>More annoyingly for speed I need content to have the same node ids etc. not having any automated path functionality I had too many /node/{nid} urls already.</p> <p>It turns out that the thing that has changed the least over the intervening time is the database structure (well there are some important differences but nothing that cannot be fixed on the fly). When I got some time a couple of beers and the following strategy:</p> <ol><li>dump the orginal site from Mysql.</li> <li>prefix all the tables from the original alpha site with prefix (eg. in my case 'node' became 'rr_node'.</li> <li>load the alpha site tables into the beta site database (they are just ignored and do no harm).</li> <li>copy a dev version of the site and move the data from the alpha tables to the beta tables, making changes as needed.</li> <li>move the dev version to live.</li> </ol><p>It worked a charm (although at the point of writing this I still have to do the comments, I was just getting bored). A few hours effort in total to get the old content into the new site.  <strong>Nice to see</strong> that the database tables are pretty clean and fairly easy to interpret by eye if all else fails.</p> <h2>Some Mysql pointers</h2> <p>To replicate this approach you need to be able to fire up a Mysql client and be pretty comfortable looking around moving data around. A few things that may help follow.</p> <p>You can wildcard show tables.<code> show tables like '%node%'; </code> will show you node related tables for example.</p> <p>You can view the structure of a table with describe  eg. <code>describe node;</code></p> <p>Tables that have the same structure are very easy to populate <code>INSERT INTO url_alias SELECT * FROM rr_url_alias;</code> tables where the structure varies (missing fields, field in a different order etc.) require the fields and field order to be specified:</p> <pre> <code>INSERT INTO node_field_revision (nid, vid, langcode, title, uid, status, created, changed, promote, sticky, default_langcode) SELECT nid, vid, langcode, title, uid, status, created,   changed, promote, sticky, default_langcode from rr_node_field_revision;</code></pre> <p>Language codes have to match, my old database was full of 'und' the new one needed 'en'</p> <p>Revisions are better flattened, a lot of the complication in folding the two structures together are around revisions, I did have revisions in my original alpha site (not because I needed them, just to kick the tyres). It was much easier to flatten the revisions, in simple tables just making vid = nid or revision_id = entity_id does the job BUT in tables like field tables where multiple revisions are tracked for the same entity you want to delete all the older revision and then keep the last one, matching the revision_id to entity_id as appropriate. Drupal then just sees the content as having one revision and the last change will match the state as the last revision you had previously.</p> <h2>Give me a shout if you need help</h2> <p>I appeciate all the above is a bit holistic, as I said it took a few hours and a couple of beers from start to finish and was fairly hacky (I was cooking a meal at the same time etc.) I had no time to compile a structured migration guide (which may be different for your particular version of the site anyway), if you are confident with Mysql then a content migration (included taxonomy terms, etc etc. ) is a very feasible way to get ancient D8 content into a new spanking new D8 Beta and <a href="" target="_blank">I FEEL GOOD</a>. </p> <p>Happy to chip in if anyone else needs a hand.</p> <p>Looking forward to trying out themeing now I have an up to date Drupal 8. </p> <h2>UPDATE</h2> <p>I finally sorted out the comments in the same manner, I recorded the steps taken and have pasted an example below, this would have be more complicated if I had not imported all the previous data with the same node ids. </p> <pre> <code> -- Had a lot spam comments to delete but shoved them in a new table so -- I can delete them from other places also CREATE TABLE del_comment AS SELECT cid FROM rr_comment WHERE status = 0; DELETE FROM rr_comment WHERE status = 0; -- The comment table is much more concise now, 14 is because I already have some -- comments in the new site. INSERT INTO comment SELECT cid, 'comment', uuid, 'en' FROM rr_comment WHERE cid &gt; 14; -- Use that table I created to delete all the spam comment bodies DELETE FROM rr_comment__comment_body WHERE entity_id IN (SELECT cid FROM del_comment); INSERT INTO comment__comment_body SELECT * FROM rr_comment__comment_body WHERE entity_id &gt; 14; -- Comment field data is a new one I need to pull things in from a couple of places so easier -- to build initially into a new table, this is an easy way to replicate the structure. CREATE TABLE comment_field_data_shadow AS SELECT * FROM comment_field_data; TRUNCATE comment_field_data_shadow; INSERT INTO comment_field_data_shadow SELECT cid,'comment','en',pid,nid,subject,uid,name,mail,homepage,hostname,created,changed,status,thread,'node','comment','en' FROM rr_comment WHERE cid &gt; 14; -- Populate the real comment field FROM my constructed table. INSERT INTO comment_field_data SELECT * FROM comment_field_data_shadow; -- I was acting under a different user name on the old site. UPDATE comment_field_data set uid = 1 WHERE uid = 2; -- Now need to patch up a few diffences in the way the data was stored UPDATE comment_field_data set pid = NULL WHERE pid = 0; UPDATE comment_field_data set mail = NULL; UPDATE comment_field_data set hostname = NULL; UPDATE comment_field_data set default_langcode=1; -- Finally update the comment statistics for nodes, not just for convenience -- in particular if you don't do this anonymous cannot see the comments. INSERT INTO comment_entity_statistics SELECT nid, 'node', 'comment', cid, last_comment_timestamp, last_comment_name, last_comment_uid, comment_count FROM rr_node_comment_statistics WHERE nid &gt; 1; -- Some comments I made as a user that does not exist on this site. UPDATE comment_entity_statistics set last_comment_uid = 1 WHERE last_comment_uid = 2; </code> </pre> </div> <section id="comment-section" > <h2>Comments</h2> <a id="comment-5"></a> <article class="comment"> <header class="comment-header"> <p><strong><span>Anonymous (not verified)</span></strong><br /> Mon, 03/16/2015 - 10:31</p> </header> <div class="content"> <h4><a href="/comment/5#comment-5" class="permalink" rel="bookmark" hreflang="en">It would be so great if</a></h4> <div><p>It would be so great if people could start working on <a href=""></a> for Drupal 8</p> </div> </div> <footer class="comment-footer"> <nav><drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=5&amp;1=default&amp;2=en&amp;3=" token="7c440898"></drupal-render-placeholder></nav> </footer> </article> <div class="indented"><a id="comment-6"></a> <article class="comment"> <header class="comment-header"> <p><strong><span>chrishu</span></strong><br /> Mon, 03/16/2015 - 11:22</p> <p class="comment-parent visually-hidden">In reply to <a href="/comment/5#comment-5" class="permalink" rel="bookmark" hreflang="en">It would be so great if</a> by <span>Anonymous (not verified)</span></p> </header> <div class="content"> <h4><a href="/comment/6#comment-6" class="permalink" rel="bookmark" hreflang="en">I hadn&#039;t seen this</a></h4> <div><p>That is interesting, I hadn't seen this project, seems like there should have been a version for D8 though, I will have a quick look at what it was doing. </p></div> </div> <footer class="comment-footer"> <nav><drupal-render-placeholder callback="comment.lazy_builders:renderLinks" arguments="0=6&amp;1=default&amp;2=en&amp;3=" token="438f760d"></drupal-render-placeholder></nav> </footer> </article> </div> <h2>Add new comment</h2> <drupal-render-placeholder callback="comment.lazy_builders:renderForm" arguments="0=node&amp;1=27&amp;2=comment&amp;3=comment" token="bdf0e84b"></drupal-render-placeholder> </section> Sun, 15 Mar 2015 15:08:01 +0000 chrishu 27 at This site is being rebuilt!! <span>This site is being rebuilt!!</span> <span><span>chrishu</span></span> <span>Sat, 03/07/2015 - 17:50</span> Sat, 07 Mar 2015 17:50:27 +0000 chrishu 1 at