I have been getting more and more frustrated with drupal lately, it seems like things are changing faster than I would like.
My current frustration is that I can no longer update drupal with drush, it seems as though I have to use composer to update.
I am actually considering switching to wordpress where updates are very very simple.submitted by /u/bloomt1990
During the redesign process of a website, there are many small changes that can ultimately affect the traffic of the new site. The key is to identify any changes that might break SEO, or changes that might affect the way the site looks to search engine spiders ahead of time to avoid traffic drops. In the end, we want the site to look fresh and new while still getting the same traffic, or more, as the old design.
At Zivtech, we look at many factors in the planning phase of a website redesign project and try to identify those that could cause drops in traffic after the new design is launched. Once these have been identified, we ensure all of these tasks have been completed before launch. Let’s take a look at some of these factors and how to avoid traffic drops on your next website redesign project.Meta Tags
We typically build sites with Drupal, so the Metatag module handles much of the meta tag configuration and display on the site. If you aren’t using Drupal though, there could be some changes to your front-end design that could affect your meta tags and confuse search engine spiders. You’ll need to make sure that all of your pages have meta tags and that there aren’t any duplicates.Broken Links
Broken links are a huge problem during website redesigns. This could be a result of changes in the menu structure or in path structures for content types. Broken links mean that users and search engines can’t find the pages they’re looking for, which can really wreak havoc on your site traffic statistics.Read more
In my last post, we discussed why marketers might want to migrate their content to Drupal 8, and the strategy and planning required to get started. The spreadsheet we shared with you in that post is the foundation of a good migration, and it usually takes a couple sprints of research, discussion, and documentation to compile. It’s also a process that’s applicable to all migration of content, no matter the source or destination framework.
I am looking for advice on how people choose to start their custom Drupal 8 themes that include Bootstrap 3. I will want a setup with Gulp, that builds bootstrap from sass so I can include only what I need. I cruised Github and found a few starter kits, and noticed none of them are "subthemes" of the drupal.org/project/bootstrap theme. Which is what I originally was going to do, but now unsure.
I don't really know the pros/cons to using the Bootstrap project theme as a parent-theme OR classy for example.
Starter kits I found (I am looking to do something very similar) * https://github.com/alexandar87/d8bs * https://github.com/xenomedia/xeno_demeter * https://github.com/mlaroy/drupal-8-webpack-starter * https://github.com/kurtisdunn/Drupal-8-Starter-Gulp-SASS
What are the pros/cons to subthemes? I got burned in D7 when a profile maintainer abonded their Distrobution, and I can see the pros to a Vanilla Drupal install now :) So I want to start my theme out correctly!submitted by /u/slaphappie
Lightning Strict Adam Balsam Thu, 01/18/2018 - 10:00
Under certain circumstances, it might be necessary to build a specific version of Lightning with dependencies exactly as they were when it was released. But sometimes building older versions of Lightning can be problematic. For example, maybe a new dependency conflicts with an old one, or a patch no longer applies with an updated dependency.
In that case, you can use the new "Lightning Strict" package to pin all of Lightning's dependencies (and their dependencies recursively) to the specific versions that were included in Lightning's composer.lock file when it was released. (If this sounds familiar, a "Drupal Core Strict" package also exists that does the same thing for core. But note that package is incompatible with Lightning Strict since Lightning uses PHP 7.0 when building its lock file.)
In this example, we want to build Lightning 2.2.4 - which contains the migration to Content Moderation, Workflows, and Lightning Scheduler:$ composer require acquia/lightning:2.2.4 balsama/lightning_strict:2.2.4 --no-update $ composer update
Assuming you were updating from Lightning 2.2.3, you could then follow the update instructions for 2.2.4 found in our release notes. In this case, they are:$ drush updatedb && drush cache-rebuild $ drupal update:lightning --since=2.2.3
Once you've updated to the most recent version, you can remove the dependency on balsama/lightning_strict.
The package will automatically be updated when new versions of Lightning are released. Hopefully this will solve some of the problems people have experienced when trying to build older version of Lightning.
One of the things we do on an annual basis for our clients at Advomatic is an annual site audit – a high level kick-the-tires kind of site inspection. For Drupal sites, we check the logs for any glaring errors, check for overrides in Features, run some SEO and accessibility testing, and, of course, take it... Read more »