Drupal

Fine Image Upload

New Drupal Modules - 19 April 2017 - 1:04pm
Categories: Drupal

Aten Design Group: Migrating Wordpress into Drupal 8

Planet Drupal - 19 April 2017 - 12:17pm

Quite a bit has changed for the Migrate module in Drupal 8: the primary module is part of core and some of the tools have been split into their own modules. Recently, we migrated a Wordpress site into Drupal 8 and this article will help guide you in that process. If you’re looking for information about Wordpress to Drupal 7 migrations, check out Joel Steidl’s article on that here.

At the time of writing this post, the migration modules are considered "experimental" so be aware of that as well. The module's location in core also means that all Drupal core modules also have migration-related code to help out with your Drupal upgrades. We used the WP Migrate module (Migrate Wordpress) as a starting point in bringing this content to Drupal.

This module will give you a good basis for migration, but it is missing a few things that you might want to consider:

  • It will create all vocabularies and taxonomies based on what is in Wordpress but you will need to add some code to connect the taxonomies with posts.
  • Also, it will not bring in featured images.
  • WP content might be using the "line break to paragraphs" functionality, which you need to account for either in your text format for posts or in the migration.

And if you are looking for information about Wordpress to Drupal 7 migrations, check out Joel Steidl's article on that here.

Taxonomy

There's code existing to pull in Wordpress's terms and vocabularies, but you will need to do some work to put them into the right fields with your posts. For this, I ended up taking a more efficient route by querying the source database in prepareRow():

<?php   // place in Posts.php prepareRow()   // get terms for this blog post $tags = $this->select('wp_term_relationships', 'r') ->join('wp_term_taxonomy', 't', 't.term_taxonomy_id=r.term_taxonomy_id') ->fields('r') ->condition('t.taxonomy', 'tags') ->condition('object_id', $row->getSourceProperty('id'))->execute(); $tags = $tags->fetchAll(); $tags = array_map(function($tag) { return intval($tag['term_taxonomy_id']); }, $tags); $row->setSourceProperty('tags', $tags);   // get categories for this blog post $category = $this->select('wp_term_relationships', 'r') ->join('wp_term_taxonomy', 't', 't.term_taxonomy_id=r.term_taxonomy_id') ->fields('r') ->condition('t.taxonomy', 'category') ->condition('object_id', $row->getSourceProperty('id'))->execute(); $category = $category->fetchAll(); $category = array_map(function($tag) { return intval($tag['term_taxonomy_id']); }, $category); $row->setSourceProperty('categories', $category);

And then I updated the migration template with those new values:

# add to the process section field_tags: tags field_category: tags Featured Images

Wordpress stores featured images as attachment posts and stores the relationship in the postmeta table. To bring these in as image fields, we need to make file entities in Drupal which means configuring a new migration.

First, create a migration template called wp_feature_images.yml. Note that I stole some of this from Drupal's core file module:

id: wp_feature_images label: Wordpress Feature Images migration_tags: - Wordpress migration_group: wordpress source: plugin: feature_images destination: plugin: entity:file process: filename: filename uri: uri status: plugin: default_value default_value: 1 # migration_dependencies: # required: # - wp_users

And then create a source plugin:

<?php /** * @file * Contains \Drupal\migrate_wordpress\Plugin\migrate\source\FeatureImages. */   namespace Drupal\migrate_wordpress\Plugin\migrate\source;   use Drupal\migrate\Row; use Drupal\migrate\Plugin\migrate\source\SqlBase; use Drupal\Core\File\FileSystemInterface; use Symfony\Component\DependencyInjection\ContainerInterface; use Drupal\migrate\Plugin\MigrationInterface; use Drupal\Core\State\StateInterface;   /** * Extract feature images from Wordpress database. * * @MigrateSource( * id = "feature_images" * ) */ class FeatureImages extends SqlBase {   public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration, StateInterface $state, FileSystemInterface $file_system) { parent::__construct($configuration, $plugin_id, $plugin_definition, $migration, $state); $this->fileSystem = $file_system; }   /** * {@inheritdoc} */ public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) { return new static( $configuration, $plugin_id, $plugin_definition, $migration, $container->get('state'), $container->get('file_system') ); }   /** * {@inheritdoc} */ public function query() { $query = $this ->select('wp_postmeta', 'm') ->fields('p', ['ID', 'guid']); $query->join('wp_posts', 'p', 'p.ID=m.meta_value'); $query ->condition('m.meta_key', '_thumbnail_id', '=') ->condition('p.post_type', 'attachment', '=') ->condition('p.guid', '', '<>') // this prevents some duplicates to get the count closer to even ->groupBy('ID, guid'); return $query; }   /** * {@inheritdoc} */ public function fields() { $fields = array( 'ID' => $this->t('The file ID.'), 'guid' => $this->t('The file path'), ); return $fields; }   /** * {@inheritdoc} */ public function prepareRow(Row $row) { $url = $row->getSourceProperty('guid'); $parsed_url = parse_url($url); $filename = basename($parsed_url['path']); $row->setSourceProperty('filename', $filename); $public_path = 'public://' . $parsed_url['path']; $row->setSourceProperty('uri', $public_path);   // download the file if it does not exist if (!file_exists($public_path)) { $public_dirname = dirname($public_path);   // create directories if necessary if (!file_exists($public_dirname)) { $this->fileSystem->mkdir($public_dirname, 0775, TRUE); }   // try to download it $copied = @copy($url, $public_path); if (!$copied) { return FALSE; } } return parent::prepareRow($row); }   /** * {@inheritdoc} */ public function bundleMigrationRequired() { return FALSE; }   /** * {@inheritdoc} */ public function getIds() { return array( 'ID' => array( 'type' => 'integer', 'alias' => 'p', ), ); }   }

In Migrate, the template defines what source, processing, and fields are created. The source plugin is used by that migration to allow you to specify what is created. The source plugin above will get the feature images for posts, but also try and download the image into Drupal's files directory.

You can add this as a dependency for the wp_posts migration. A word of warning though: if one migration (Migration A) depends on a different migration (Migration B), all of the content from A must be migrated before B can be run. If there are images that cannot be resolved for some reason (maybe leftover DB references after an image or post is deleted), this might stop the migration because the dependency cannot be resolved.

And finally, you will also need to add "wp_feature_images" to your manifest_wordpress.yml before running the migration.

Converting content

So far we have updated migration source plugins, but there are also process plugins, which can be used to change row values. As mentioned, the WP content often uses the autop filter to create paragraph/line breaks automatically so we need to change those to HTML for Drupal. (You can also just use this functionality in your text format and skip this step if having this on will not cause issues with other content)

First, create a "src/Plugin/migrate/process" directory if one does not exist in the module and add this processor:

<?php   namespace Drupal\migrate_wordpress\Plugin\migrate\process;   use Drupal\migrate\MigrateExecutableInterface; use Drupal\migrate\ProcessPluginBase; use Drupal\migrate\Row;   /** * Apply the automatic paragraph filter to content * * @MigrateProcessPlugin( * id = "wp_content" * ) */ class WpContent extends ProcessPluginBase {   /** * {@inheritdoc} * * Split the 'administer nodes' permission from 'access content overview'. */ public function transform($value, MigrateExecutableInterface $migrate_executable, Row $row, $destination_property) { return _filter_autop($value); }   }

Then, update the "process" section of "wp_posts.yml" to include this processor:

'body/value': plugin: wp_content source: post_content

All of this should put you on the road to getting Wordpress content migrated into a Drupal 8 site, although you’ll probably have to adjust code to your specific circumstances along the way.

Categories: Drupal

Acquia Developer Center Blog: Acquia in action at DrupalCon Baltimore!

Planet Drupal - 19 April 2017 - 9:01am

If you’re coming to DrupalCon Baltimore and you’re curious about Acquia, there are a couple of ways to meet the company and see what we’re about beyond the marketing and sales efforts that get directed at potential clients. One great way is to come to our sessions!

Tags: acquia drupal planet
Categories: Drupal

ThinkShout: Meet the ThinkShout Team at DrupalCon Baltimore

Planet Drupal - 19 April 2017 - 9:00am

We’re packing our bags for Baltimore and polishing up our slide decks for DrupalCon! We’re so excited to join the Drupal community for a full week of Drupal-y things. We’ve got some great content planned for this year’s conference, and we’re very excited to share it with you all - here’s what you need to know:

Exhibit Hall

The ThinkShout Headquarters this year is booth 432! We’ll be giving away free t-shirts and raffling off an Amazon Echo. You can enter to win for the low, low price of one business card. If you have any questions about our work, current available job opportunities, or what the weather’s like in Portland (spoiler: it’s probably raining), stop by - we’d love to chat with you!

ThinkShout Sessions

The ThinkShout team has two sessions in the DrupalCon agenda this year. We’re also very excited to be leading a discussion in our first DrupalCon Nonprofit Summit. Take a look at our lineup and mark your calendars

Rapid Response Campaigns & Digital Tools” - Monday (4/24), 12:30 - 1:15pm, Nonprofit Summit

The news cycle doesn’t stop, and your website must help you respond to emergencies, not act as a barrier. Drupal can help you react quickly, in concert with your other channels, to turn current events into opportunities to spread your message and further your mission. In this breakout session, Brett Meyer and Lev Tsypin will talk about the tools you have at your disposal in Drupal, scenarios that call for rapid response solutions and how to implement them, and strategies that will help you turn these situations into lasting engagement with your constituents.

Demystifying Rendered Content in Drupal 8 Twig Files” - Tuesday (4/25), 3:45 - 4:45pm

Amy Vaillancourt-Sals is going to show you the ins and outs of Twig! Twig is a robust and elegant template engine for PHP. It’s lightweight, fairly quick to pick up, very readable, and it grants users ultimate control over the markup, including wrapping elements and rendering exactly the output you need. In this session, you’ll learn about the debugging process of sorting through twig variables, using xdebug in PHPStorm, the other helpful debugging tools at your disposal, plus common patterns Amy found helpful for rendering content in twig files.

Content Strategy in Popular Culture, Part Deux” - Thursday (4/27), 10:45 - 11:45am

Brett Meyer’s got a sequel to his session from DrupalCon New Orleans. Another year, another array of pop culture obsessions to examine and apply to the work we do. By exploring how crucial aspects of content strategy play out in movies, music, comic books, and video games, we’ll continue to expand the palette of language we can use to explain and convince more people about the importance of content strategy online, and ensure they understand that it’s not just vital, but fun as well.

Let’s Chat

If you’d like to schedule some time to chat with us in advance, drop us a line via our contact form. We’d be happy to meet up with you in Baltimore!

Categories: Drupal

Lullabot: Cross-Pollination between Drupal and WordPress

Planet Drupal - 19 April 2017 - 8:27am

WordPress controls a whopping 27% of the CMS market share on the web. Although it grew out of a blogging platform, it can now can handle advanced functionality similar to Drupal and is a major (yet friendly) competitor to Drupal. Like Drupal, it’s open source and has an amazing community. Both communities learn from each other, but there is still much more to share between the two platforms.

Recently I had the opportunity to speak at WordCamp Miami on the topic of Drupal. WordCamp Miami is one of the larger WordCamps in the world, with a sold-out attendance of approximately 800 people.

undefined What makes Drupal so great?

Drupal commands somewhere in the neighborhood of 2% of the CMS market share of the web. It makes complex data models easy, and much of this can be accomplished through the user interface. It has very robust APIs and enables modules to share one another’s APIs. Taken together, you can develop very complex functionality with little to no custom code.

So, what can WordPress take away from Drupal? Developer Experience: More and better APIs included in WordPress Core

The WordPress plugin ecosystem could dramatically benefit from standardizing API’s in core.

  • Something analogous to Drupal’s Render API and Form API would make it possible for WordPress plugins to standardize and integrate their markup, which in turn would allow plugins to work together without stepping on each other’s toes.
  • WordPress could benefit from a way to create a custom post type in the core UI. Drupal has this functionality out the the box. WordPress has the functionality available, but only to the developer. This results in WordPress site builders searching for very specific plugins that create a specific post type, and hoping it does what they want.
  • WordPress already has plugins similar to Drupal’s Field API. Plugins such as Advanced Custom Fields and CMB2 go along way to allowing WordPress developers to easily create custom fields. Integrating something similar to this into WordPress core would allow plugin developers to count on a stable API and easily extend it.
  • An API for plugins to set dependencies on other plugins is something that Drupal has done since its beginning. It enables mini-ecosystems to develop that extend more complex modules. In Drupal, we see a module ecosystems built around Views, Fields, Commerce, Organic Groups, and more. WordPress would benefit greatly from this.
  • A go-to solution for custom query/list building would be wonderful for WordPress. Drupal has Views, but WordPress does not, so site builders end up using plugins that create very specific queries with output according to a very specific need. When a user needs to make a list of “popular posts,” they end up looking through multiple plugins dedicated to this single task.

A potential issue with including new APIs in WordPress core is that it could possibly break WordPress’ commitment to backwards compatibility, and would also dramatically affect their plugin ecosystem (much of this functionality is for sale right now).

WordPress Security Improvements

WordPress has a much-maligned security reputation. Because it commands a significant portion of the web, it’s a large attack vector. WordPress sites are also frequently set up by non-technical users, who don’t have the experience to keep it (and all of its plugins) updated, and/or lock down the site properly.

That being said, WordPress has some low-hanging fruit that would go a long way to help the platform’s reputation.

  • Brute force password protection (flood control) would prevent bots from repeatedly connecting to wp-login.php. How often do you see attempted connections to wp-login.php in your server logs?.
  • Raise the minimum supported PHP version from 5.2 (which does not receive security updates). Various WordPress plugins are already doing this, and there’s also talk about changing the ‘recommended’ version of PHP to 7.0.
  • An official public mailing list for all WordPress core and plugin vulnerabilities would be an easy way to alert developers to potential security issues. Note that there are third-party vendors that offer mailing lists like this.
Why is WordPress’ market share so large?

Easy: It can be set up and operated by non-developers—and there are a lot more non-developers than developers! Installing both Drupal and WordPress is dead simple, but once you’re up and running, WordPress becomes much easier.

Case in Point: Changing Your Site's Appearance

Changing what your site looks like is often the first thing that a new owner will want to do. With WordPress, you go to Appearance > Themes > Add New, and can easily browse themes from within your admin UI. To enable the theme, click Install, then click Activate.

undefined

With Drupal, you go to Appearance, but you only see core themes that are installed. If you happen to look at the top text, you read in small text that "alternative themes are available." Below that there is a button to “Install a New Theme.”

undefined

Clicking the button takes you to a page where you can either 1) paste in a URL to the tarball/zip, or upload a downloaded tarball/zip. You still have to know how to to download the zip or tarball, and where to extract it, and then browse to appearance, and enable the theme.

So it goes with Drupal. The same process goes with modules and more. Drupal makes things much more difficult. 

So, what can Drupal learn from WordPress?

To continue to grow, Drupal needs to enable non-developers. New non-developers can eventually turn into developers, and will become “new blood” in the community. Here’s how Drupal can do it:

  • A built in theme and module browser would do wonders for enabling users to discover new functionality and ways to change their site’s appearance. A working attempt at this is the Project Browser module (available only for Drupal 7). The catch 22 of this is that you have to download this the old-fashioned way in order to use it.
  • The ability to download vetted install profiles during the Drupal installation process would be amazing. This would go a long way to enable the “casual explorers," and show them the power of Drupal. A discussion of this can be found here.
  • Automatic security updates is a feature that would be used by many smaller sites. Projects have been steered toward WordPress specifically because smaller clients don’t have the budget to pay developers to keep up with updates. This feature has been conceptually signed off on by Drupal’s core committers, but significant work has yet to be done.
Mitigating Security Risks

The downside for this functionality is that Drupal would need to have a writable file-system, which at it’s core, is less secure. Whether that balances out with automatic updates is debatable.

Automatic security updates and theme/module installation would not have to be enabled out of the box. The functionality could be provided in core modules that could be enabled only when needed.

What has Drupal already learned from WordPress?

Cross-pollination has already been happening for a while. Let’s take a look at what the Drupal community has already, or is in the process of, implementing:

  • Semantic versioning is one of the most important changes in Drupal 8. With semantic versioning, bug fixes and new features can be added at a regular cadence. Prior to this, Drupal developers had to wait a few years for the next major version. WordPress has been doing this for a long time.
  • A better authoring experience is something that Drupal has been working on for years (remember when there was no admin theme?). With Drupal 8, the default authoring experience is finally on par with WordPress and even surpasses it in many areas.
  • Media management is the ability to upload images and video, and easily reference them from multiple pieces of content. There’s currently a media initiative to finally put this functionality in core.
  • Easier major version upgrades is something that WordPress has been doing since it’s inception.

Drupal has traditionally required significant development work in between major versions. That however, is changing. In a recent blog post, the lead of the Drupal project, Dries Buytaert said,

Updating from Drupal 8's latest version to Drupal 9.0.0 should be as easy as updating between minor versions of Drupal 8.

This is a very big deal, as it drastically limits the technical debt of Drupal as new versions of Drupal appear.

Conclusion

Drupal and WordPress have extremely intelligent people contributing to their respective platforms. And, because of the GPL, both platforms have the opportunity to use vetted and proven approaches that are shortcuts to increased usability and usage. This, in turn, can lead to a more open (and usable) web.

Special thanks to Jonathan Daggerhart, John TuckerMatthew Tift, and Juampy NR for reviewing and contributing to this article.

undefined
Categories: Drupal

Migrate Joomla

New Drupal Modules - 19 April 2017 - 8:15am

Migrate from Joomla 3.5 to Drupal 8 with this extension of the core Migrate module (requires migrate_plus).

Categories: Drupal

Valuebound: How to create custom Form with CRUD(Create, Delete, Update) operations in Drupal 8

Planet Drupal - 19 April 2017 - 7:38am

Custom form with CRUD Operations is basically building the form with different fields like UID, Name, Mobile Number, Address, Email id etc. The CRUD operations for these fields is Deleting the value of the fields from the database or updating the existing value with new value, and printing the updated value. 

How To Create a Custom form with CRUD Operations?

To create a custom form with CRUD Operations, we need to follow the following folder structure as shown in the image. To perform the same operation of crud in drupal we need to follow the following folder structure.

Categories: Drupal

Chromatic: Chromatic at DrupalCon Baltimore

Planet Drupal - 19 April 2017 - 6:00am

All the ways Chromatic will be representing at DrupalCon Baltimore next week.

Categories: Drupal

Dave Hall Consulting: Drupal, We Need To Talk

Planet Drupal - 19 April 2017 - 5:00am

Drupal has a problem. No, not that problem.

We live in a post peak Drupal world. Drupal peaked some time during the Drupal 8 development cycle. I’ve had conversations with quite a few people who feel that we’ve lost momentum. DrupalCon attendances peaked in 2014, Google search impressions haven’t returned to their 2009 level, core downloads have trended down since 2015. We need to accept this and talk about what it means for the future of Drupal.

Technically Drupal 8 is impressive. Unfortunately the uptake has been very slow. A factor in this slow uptake is that from a developer's perspective, Drupal 8 is a new application. The upgrade path from Drupal 7 to 8 is another factor.

In the five years Drupal 8 was being developed there was a fundamental shift in software architecture. During this time we witnessed the rise of microservices. Drupal is a monolithic application that tries to do everything. Don't worry this isn't trying to rekindle the smallcore debate from last decade.

Today it is more common to see an application that is built using a handful of Laravel micro services, a couple of golang services and one built with nodejs. These applications often have multiple frontends; web (react, vuejs etc), mobile apps and an API. This is more effort to build out, but it likely to be less effort maintaining it long term.

I have heard so many excuses for why Drupal 8 adoption is so slow. After a year I think it is safe to say the community is in denial. Drupal 8 won't be as popular as D7.

Why isn't this being talked about publicly? Is it because there is a commercial interest in perpetuating the myth? Are the businesses built on offering Drupal services worried about scaring away customers? Adobe, Sitecore and others would point to such blog posts to attack Drupal. Sure, admitting we have a problem could cause some short term pain. But if we don't have the conversation we will go the way of Joomla; an irrelevant product that continues its slow decline.

Drupal needs to decide what is its future. The community is full of smart people, we should be talking about the future. This needs to be a public conversation, not something that is discussed in small groups in dark corners.

I don't think we will ever see Drupal become a collection of microservices, but I do think we need to become more modular. It is time for Drupal to pivot. I think we need to cut features and decouple the components. I think it is time for us to get back to our roots, but modernise at the same time.

Drupal has always been a content management system. It does not need to be a content delivery system. This goes beyond "Decoupled (Headless) Drupal". Drupal should become a "content hub" with pluggable workflows for creating and managing that content.

We should adopt the unix approach, do one thing and do it well. This approach would allow Drupal to be "just another service" that compliments the application.

What do you think is needed to arrest the decline of Drupal? What should Drupal 9 look like? Let's have the conversation.

Categories: Drupal

Code Positive: Why Drupal?

Planet Drupal - 19 April 2017 - 3:13am

Drupal is more than a pretty face - it's safe as houses, lets you fit in, and offers bells, whistles.....and maybe bagpipes!

 

 

Categories: Drupal

vuukle comments

New Drupal Modules - 19 April 2017 - 2:56am

-- SUMMARY --

This module provide the vuukle integration with drupal 7 nodes.
Make sure to use vuukle integration for commenting disable node commenting
configuration.

-- REQUIREMENTS --
No

-- INSTALLATION --
* Install as usual, see http://drupal.org/node/895232 for further information.

-- CONFIGURATION --

* Configure user permissions in Administration » People » Permissions:

-- CUSTOMIZATION --
* Access menu from here : admin/config/vuukle-config/settings

Categories: Drupal

Third Party API

New Drupal Modules - 19 April 2017 - 2:44am

Provides an API for managing third party settings.

Categories: Drupal

Switch Page Theme

New Drupal Modules - 19 April 2017 - 2:17am

Switch Page Theme module allows to use different theme than the site default theme on specific pages.

Features
  • Theme can be set for single page or list of pages.
  • Theme can be assigned to specific roles.
  • Wildcard '*' character can be used in drupal paths.

Configuration page path: /admin/config/system/switch_page_theme.

Categories: Drupal

Agiledrop.com Blog: AGILEDROP: Adding another DrupalCon to the list

Planet Drupal - 19 April 2017 - 12:47am
Last week we promised that from now on, we'll be more informative about where you will be able to find us. Therefore, Web Camp was our first described destination. That event is a local thing for us since our headquarters are in Ljubljana, Slovenia. Now, we are proud to say that after Web Camp we are heading towards DrupalCon Baltimore! DrupalCon is organized by Drupal Association three times a year at three different locations. Next week, from 24th to 28th April it's time for the United States to shine. The biggest Drupal event, which brings together thousands of people from all around the… READ MORE
Categories: Drupal

Gábor Hojtsy: Diversity by example

Planet Drupal - 19 April 2017 - 12:33am

(Disclaimer: Dries did not ask/order/suggest/request me to post this neither to make any changes whatsoever.)

Categories: Drupal

Relative to Absolute URL

New Drupal Modules - 18 April 2017 - 11:58pm

This module helps to convert relative paths to absolute URL.

There is also provision in admin to control to convert relative paths of Images, CSS, JavaScript and Hyperlinks to absolute URL. Refer attached screenshot.

Categories: Drupal

Beancount

New Drupal Modules - 18 April 2017 - 11:29pm

The Beancount module provides a entities and taxonomies for bookkeeping, financial, and enterprise-management purposes.

It comes with feeds importers that activate automatically when using the Quickbooks Webconnector and Quickbooks XML modules to import data from Quickbooks.

Categories: Drupal

Extrafield Settings

New Drupal Modules - 18 April 2017 - 8:19pm

The Extrafield Settings module allows module creators and developers to add field-formatter-esq settings to their extra fields created with `hook_field_extra_fields()`.

Configuration

There is no UI configuration form for this module. To use this module a
settings form callback and optionally a render callback must be defined
for your custom extra_fields. See the example below:

Categories: Drupal

Lightning Media Pinterest

New Drupal Modules - 18 April 2017 - 4:55pm
Categories: Drupal

Lightning Media GoogleDocs

New Drupal Modules - 18 April 2017 - 4:26pm
Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal