Newsfeeds

Conditional Memory

New Drupal Modules - 22 November 2018 - 11:28pm

This module allows you to conditionally increase the memory based on URLs.

Often, it is not possible to increase memory for the entire site but we may need extra memory for certain memory-intensive processes. Through this we can configure the URL for those requests and how much memory should be allocated.

Categories: Drupal

Ckeditor Textindent

New Drupal Modules - 22 November 2018 - 8:01pm

Provides integration of the CKEditor Textindent plugin with the Drupal 8 CKEditor.

改进CKEditor使支持首行缩进。

Sponsorship

This project is sponsored by Davyin. We provide specialist consulting services in Enterprise Drupal, Visit us at www.davyin.com.

Categories: Drupal

agoradesign: Bring christmas and winter flair to your Drupal site with the Snowflakes module

Planet Drupal - 22 November 2018 - 1:29pm
We've created a small Drupal module that brings pure CSS animated snowflakes into your Drupal site.
Categories: Drupal

Aegir Hosting StatsD

New Drupal Modules - 22 November 2018 - 7:57am

This module extends StatsD.module to log things from Aegir.

Categories: Drupal

Snowflakes

New Drupal Modules - 22 November 2018 - 7:02am

This module brings christmas and winter flair to your Drupal site by adding pure CSS animated snowflakes.

The module wraps the simple yet amazing CSSnowflakes code to your Drupal
site without the need of touching any template files.

Demo: http://pajasevi.github.io/CSSnowflakes/

Categories: Drupal

OpenSense Labs: Can Drupal Manage My Content?

Planet Drupal - 22 November 2018 - 6:52am
Can Drupal Manage My Content? Vasundhra Thu, 11/22/2018 - 20:22

How Drupal is helping to construct better paths in the journey of content management?

As a content strategist, we know that “Content is the King”. We hustle every day to create splendid content that’s deserving of even getting close to that royal title - because let's face it, we all want our content to be unique and surprising. 


The content can vary from blogs to forms to contact address. The question, however, is - which CMS can help you manage the content that directly impacts the reader's mind, letting the audience engage with your brand the way you want them to? 

The resounding answer has to be - Drupal! 

Drupal provides its users with many types and varieties of content that helps them to manage the website in terms of ranking and traffic.

Drupal provides the users with intuitive modules which allow them to build their own content types that have their own set of fields. But What is a Content-Type?

In order to catch the attention of the user, content is produced in various ways such as in the form of an article, newsletter, polls, listings, landing page, among others. 

Content types provide the website with a list of content that allows the content editors to add new content to the site. In other words, it enables the user to manage the settings for a category of information in a centralized and reusable manner. 


Types of Content Needed  

Drupal is one such CMS which has been providing the content editors with modules to handle all the types of content in a website. These modules provide the website with features and capabilities that can be customized. 

  1. Homepage 

    How many times have you judged a website by its homepage? Well, maybe almost every time. 

    According to the CEO of Klout Fire, to impress and engage the audience on a website, it needs to orchestrate everything, in other words, the first 15 seconds of the website is the most crucial seconds that engage and delight a customer. Homepage, therefore, becomes important. 

    Drupal modules like Panels and Ctool help you bring out a homepage with a customized layout that engages with its audience well.  
     
  2. Blogs

    From students to businessmen, blogging has grown out to be a platform used by millions. One of the popular mediums to promote business, blogging must be part of every business. 

    Part of the core now (as a content type), Drupal’s blog module allows authorized users to build and maintain any type of blog. It provides the content editors with standard blogging functionality to the site, where users with defined permissions can create, edit, and update blogs. 
     
  3. E-newsletters

    Another popular marketing initiative, newsletters are frequently used to keep the audience informed and offer promotional content. Many businesses and marketers use newsletters to promote their products and services. 

    An effective way of maintaining and providing the audience with topics that are current and trending, newsletters offer organizations a unique opportunity to nurture and educate the target audience.  

    There are essentially two ways to build a newsletter in Drupal. 
     
    1. Newsletter module strictly aims at the frequency or number of contents. It is especially recommended for people that need more than one newsletter list for their site. Newsletter module aims to be a full blown newsletter solution for Drupal 7. 
    2. Simplenews module brings the new content type that can be sent via email to all the subscribers of the associated newsletter. 

      Other options in Drupal include MailUp Newsletter Module, mailman, and MailChimp. 
       
  4. Landing Pages 

    A crucial part of the inbound marketing strategy, building, and testing landing pages is one of the top five challenges faced by B2B marketers

    Drupal has paragraph module to create templates for landing page and stacks module to allow content editors to create complex pages without the need of developers.

    Companies see a 55% increase in leads when they increase their number of landing pages from 10 to 15. 
     
  5. And much more

    Other content types involve guides, book pages, tutorials, case studies, and infographics. 

    Drupal consists of modules like book helper, book module that help to build interesting and interactive guides. Apart from this, the charts module provide a good way for the user to visualize a lot of information.
Content, Marketing, and Drupal: What is There for Marketers?

Websites using Drupal 8 has grown up to 51 percent in 2018 in comparison to the previous year.  

Easy content management can easily be one of the reasons for its popularity.  But there is more to it. More as to why you must opt for Drupal.  

  • Reducing the Cost

Drupal does not induce any licensing cost. Old news, but it is free

Other than the software cost, the visual designs of your Drupal website can be completely rebuilt without investing in the backend architecture. Drupal is also completely customizable from the get-go even with respect to the editor tools, workflows, and roles. This involves the money that would go towards the customization of the projects. Thus, benefiting the marketers in terms of budget and funds. 

  • Content and Personalization

According to the Content Marketing Institute, 71% of the content editors customize their content on the basis of audience interest. Content types like blogs, landing pages, newsletter, infographics are important factors that contribute to the ideal way of reaching and interacting with the customers. These content types deliver relevant information to the audience based on their interests and motivations. 

Drupal lets you deliver personalized content

Drupal’s Acquia Lift, a data-driven personalization module that brings content and customer data together from multiple sources, providing customized experiences across any channel or device. 

Most importantly, it allows businesses to construct a consistent personalized experience across digital platforms.

Providing easy integration with third-party tools Drupal further facilitates the personalization process. 

  • Building Custom Content Types with Drupal

As a marketer, if your needs vary from the ones mentioned above or if you are looking to build some new type of content type for your audience to devour, Drupal helps you with that too. 

Build news sections, postcards, manuals with Drupal without coding. 

Without any coding, with the use of content construction kit (CCK) and views modules, you can build new content types and produce advanced custom views for those types. 

  • Ease of Adding  Multimedia Content 

Since we know that people are more likely to remember images and videos, how can we afford to not add them in our blogs? 

Drupal’s Media Library provides a views-based browser for previously uploaded media. You can also add media to content via media field, either by selecting from existing media or by uploading new media. 

Not just this, with oEmbed support now, it allows the embedding of external media, such as YouTube and Vimeo videos.

Using Drupal features and functionalities along with digital media solution enhances the ensured reusability and real-time tracking of media assets. 

Drupal, is the whole framework for administering content on the website.
  • Adding Themes to the Content Types

The one-size-fits-all theory doesn’t work in the internet era. 

While themes ensure that your website looks great your one theme won’t be compatible with the different types of content on your website. 

Drupal has replaced the PHP Template with the all-new Twig Template in its latest update, which not only makes it easy to edit themes but customize the ones according to your needs very easily. 

With the addition of new template engine, Drupal gives you responsive and mobile-friendly themes. 

The main goal is to deliver the audience with the power of overriding all the templates and change the front end for modifications. Therefore the visual design of a website can be entirely rebuilt with the help of Drupal, without actually spending on any back-end architecture differences. 

All the Drupal Themes for 2018

  • SEO Friendly

People trust search engines. In fact, 50% of visitors are more likely to click a result if the brand appears multiple times in search engine results. 

Writing great content will not suffice, your CMS have to have SEO capabilities in order to make your business visible. 

According to a survey by Neil Patel Digital, SEO is the 2nd most used practices of all time that affects the traffic of a website. 

When it comes to Drupal, there are a variety of SEO friendly modules that help the website reach a better rank. The extensive list of SEO modules includes Page Title, SEO Checklist, Meta tags, Taxonomy Title, HTML Purifier, Real-time SEO. 

Drupal’s out-of-the-box schema tags help search engines identify what the page is about, its relevant and how useful will it be for a specific query. 

Drupal presents the users with a comprehensive control over the URL structure with the help of modules like  Pathauto, and maintain a clean understandable URL structure with the help of Global Redirect. 

  • Content  Monitoring

For a content marketing strategy to be successful, it needs to be underpinned by data. After all, how do you decide if some information is tangible or not? Or how else would you know how your content is performing?

Since data never lies, you need to have actual audience insights for your next marketing strategy. 
 
Google Analytics is one of the best tools for monitoring the traffic on a website while providing real-time updates about the number of visitors, how much time they are spending,  popular pages visited by them among other information. 
 
Drupal’s Google Analytics module lets you add the Google Analytics web statistics tracking system to your website, so you can:

  1. Selectively track and exclude certain users, roles and pages.
  2. Monitor different types of links 
  3. Monitor the type of files that are being downloaded from your pages
  • Community and Engagement 

Among all the marketing strategies, fostering customer loyalty brings results. Businesses seeking to build more engagement and repo among its users can’t miss out on community outreach. 

Content, community, and business go hand in hand.  

Community brings engagement. And engagement returning users. 

In order to ensure a splendid digital experience, the ideal CMS must provide value to integrate with community building technologies. 

With a community of more than 200,000 people, Drupal is the best example of what it can do for the community platforms.

You can serve your audience better if you know what they are looking for. Integrating with almost all the acknowledged ERP systems which are available like Alfresco, Salesforce, Bynder, and SugarCRM.

Additionally,

  • Drupal grants marketers with modules like Disqus and HybridAuth Social Login to connect with the audience. It allows them to connect more strongly with customers and transform more prospects into buyers.
     
  • Drupal helps power up the websites with chatbot for an interactive and a guiding experience to the user. It can incorporate the Chatbots and connect with the people giving them a better user experience. 
Conclusion

Increasing traffic, retention and conversion is mostly the main agenda of every website holder, and Drupal contributes vividly in this part as a content manager. It offers a dozen powerful modules for maintaining and creating content. 

Create personalized content with OpenSense Labs, drop a mail at hello@opensenselabs.com and experience the best content management services and solutions.  

blog banner blog image Drupal Drupal 8 Drupal 8 Content Types Drupal modules Drupal Personalization Drupal Themes Content Types Blog Community Blog Type Articles Is it a good read ? On
Categories: Drupal

Oracle Eloqua API Redux

New Drupal Modules - 22 November 2018 - 3:39am
Categories: Drupal

Webform Mail attachments

New Drupal Modules - 22 November 2018 - 1:58am
Categories: Drupal

Block ID

New Drupal Modules - 22 November 2018 - 12:42am
Categories: Drupal

PreviousNext: Be Prepared for the DrupalSouth 2018 Sprint

Planet Drupal - 21 November 2018 - 5:19pm

Update: Re-published for DrupalSouth 2018 edition

The PreviousNext team are sponsoring and helping to run the sprint day on Wednesday, December 5th 2018, and there are a few things you can do now to hit the ground running on the day.

by Kim Pepper / 22 November 2018 What's a Sprint Day about anyway?

Contribution Sprints are a great opportunity to get involved in contributing to Drupal. Contributions don't have to be just about code. Issue triage, documentation, and manual testing are examples of non-code contributions.

If you are new to contributing, you can take a look at the New Contributor tasks on the Drupal.org Contributor Tasks page.

While there will be experienced contributors there on the day to help, keep in mind, this is not a training session. :-)

Set Up a Development Environment

There is more than one way to shear a sheep, and there is also more than one way to set up a local development environment for working on Drupal.

We've create a Drupal project starter kit for sprint attendees which should speed up this process. Head over to https://github.com/previousnext/drupal-project and follow the README.

If you have any issues, feel free to post them in the Github issue queue https://github.com/previousnext/drupal-project/issues and we'll try and resolve them before the day.

Find Issues to Work On

If you want to see what might be an interesting issue to work on, head over to the Drupal.org Issue Queue and look for issues tagged with 'DrupalSouth 2018'. These are issues that others have tagged.

You can also tag an issue yourself to be added to the list.

Being face-to-face with fellow contributors is a great opportunity to have discussions and put forward ideas. Don't feel like you need to come away from the day having completed lines and lines of code.

We look forward to seeing you all there!

Tagged DrupalSouth, Code Sprint
Categories: Drupal

Morpht: Drupal and Composer: Part 2 — Managing a Drupal 8 site with Composer

Planet Drupal - 21 November 2018 - 4:20pm
Drupal and Composer - an In-Depth Look

 

As any developer working with Drupal 8 knows, working with Composer has become an integral part of working with Drupal. This can be daunting for those who don't have previous experience working with the command line, and can still be a confusing experience for those who do. This is the second post in an explorative series of blog posts I will be writing on Composer, hopefully clearing up some of the confusion around it. The four blog posts on this topic will be as follows:

  • Part 1: Understanding Composer
  • Part 2: Managing a Drupal 8 site with Composer
  • Part 3: Converting Management of an Existing Drupal 8 Site to Composer (Coming Soon)
  • Part 4: Composer for Drupal Developers (Coming Soon)

This article will be difficult to understand without first understanding the concepts explained in part 1, so If you have not read it, it would probably be worth your while to ensure you understand the concepts outlined in the summary of that article, before proceeding with this one.

Managing Drupal sites with Composer Beginning a New Project

Fortunately a lot of work has been put into creating a Composer base (called a template) for Drupal projects. This Drupal Composer template can be found on Github at: https://github.com/drupal-composer/drupal-project. Instructions on how to use the template can be found there, and the same instructions are found in the README.md file that comes with the project when installed.

Starting a new project with the Drupal Composer template can be done with the following line of code:

composer create-project drupal-composer/drupal-project:8.x-dev some-dir --stability dev --no-interaction

This command does a number of things, many of which will be addressed below.

1) A new Composer project is created

The first thing the installation does is to create the directory specified as some-dir in the command, and initializes a Composer project in that directory. Change this to the appropriate name for your project. This is now your new project. The project contains the composer.json and composer.lock files that will be used to manage the code base of the project.

Note: The command provided lists the --stability as dev. This can be confusing as developers may think this means they are getting the -dev version of Drupal core. Don't worry, the command given above will always install the current full release of Drupal core, whatever it is at the time when the command is run. 2) Library dependencies (as well as their dependencies) are installed

The Composer template has a number of dependencies included by default, some of which we will take a look at here. These libraries are set by default as requirements in composer.json, and therefore are included when running the install command given earlier.

  • Drush: Drush is cool. If you don’t know what it is, it’s worth some Google-fu. Anything to be written about Drush has already been written somewhere else, so check it out - it will be worth your while!
  • Drupal Console: Drupal Console is also really cool. See comments on Drush.
  • Composer Patches: This one is very cool. This library in and of itself is worth using Composer to manage Drupal projects in my eyes. Even if Composer had no other benefits, this one would be great. First, an explanation of a patch is necessary. A patch is kind of like a band-aid that can be applied to code. Patches allow developers to submit changes, be they bug fixes or new functionality, to the library maintainer. The library maintainer may or may add the patch to the source code, but in the meantime, other developers can apply the patch to their own systems, both to test if it works, as well as use it if it does. However, when the library the patch has been applied to is updated to a newer version, the patches have to be re-applied. What Composer Patches does is allow developers to track patches applied to the project, and have them applied automatically during the update process. This ensures that bugs don't arise from forgetting to re-apply patches after the update. Patches are tracked by adding them to composer.json. Here is an example:
     
  • "extra": { "patches": { "drupal/core”: { “Patch description”: "https://www.drupal.org/files/issues/someissue-1543858-30.patch" } } }

    With the above code, the next time composer update drupal/core is run, Composer will attempt to apply the patch found at https://www.drupal.org/files/issues/someissue-1543858-30.patch to Drupal core. Note that the description of the patch, given above as "Patch description", is arbitrary, and should be something descriptive. If there is an issue for the patch, a link to the issue is good to add to the description, so developers can quickly look into the status of the patch, see if any updated patches have been released, and check if the patch has been incorporated into the library, rendering the patch unnecessary.

  • And Others: There are many other libraries that are included as part of the Drupal Composer template, but the truth is that I haven’t looked into them. Also note that Drupal core alone has multiple dependencies which have their own dependencies. At the time of writing, 123 libraries are installed into the project with the install command.
But wait - I don’t use [fill in library here]

The Composer template is just that - a template. Some people don’t use Drush, some don’t use Drupal console. If these are not needed, they can be removed from a project in the same manner as any Composer library. Example:

composer remove drush/drush

The above command will remove Drush from the code managed by the Composer template.

3) The system folder architecture is created

The file system created by the Composer template deserves a close look.

  • /web: The first thing to notice is that Drupal is installed into the /web directory in the root of the project. This means that the root of the project created with the Composer template is one level above the webroot. When configuring the server, the domain for the server will need to point at the /web directory.
  • /config/sync: The Composer template sets up the project to store Drupal 8 configuration .yml files in this folder. When running drush cex sync to export configuration, the entire site configuration will be exported to this folder. This is folder is best kept out of the webroot for security purposes.
  • /drush: This folder holds a few Drush specific items in it. If multiple environments exist for your project, Drush aliases can be set in /drush/sites/self.site.yml, allowing for interaction with your various environments from anywhere within the project.
  • /scripts: At the time of writing, this folder contains only a single file, /scripts/composer/ScriptHandler.php. This is a really cool file that contains code run by Composer during various processes.

    The composer.json file in the Drupal Composer template contains the following:
      "scripts": { "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold", "pre-install-cmd": [ "DrupalProject\\composer\\ScriptHandler::checkComposerVersion" ], "pre-update-cmd": [ "DrupalProject\\composer\\ScriptHandler::checkComposerVersion" ], "post-install-cmd": [ "DrupalProject\\composer\\ScriptHandler::createRequiredFiles" ], "post-update-cmd": [ "DrupalProject\\composer\\ScriptHandler::createRequiredFiles" ] },

    The code above executes the stated code on pre-install, pre-update, post-install and post-update. Any time either composer install or composer update are executed on the system, the pre and post hook for that call are executed, calling the relevant functions above. Developers can create their own pre/post install and update hooks following the examples shown above.

  • /vendor: The first thing to note is that the location of this file differs from a vanilla Drupal 8 installation. When installing Drupal manually, the vendor folder is part of the webroot by default. This however could lead to security issues, which is why the Composer template installs it above the webroot. The vendor folder contains most of the libraries that Composer manages for your project. Drupal core, modules, themes and profiles however are saved to other locations (to be discussed in the next section). Everything else is saved to the /vendor folder.

4) Drupal File/Folder Installation Locations are set

As mentioned above, Drupal core is installed into the /web folder. The Composer template also sets up installation locations (directories) for Drupal libraries, modules, themes and profiles so that when Composer installs these, they are put in the appropriate Drupal folder locations. This is the code in composer.json that handles the installation locations:

"extra": { "installer-paths": { "web/core": ["type:drupal-core"], "web/libraries/{$name}": ["type:drupal-library"], "web/modules/contrib/{$name}": ["type:drupal-module"], "web/profiles/contrib/{$name}": ["type:drupal-profile"], "web/themes/contrib/{$name}": ["type:drupal-theme"], "drush/contrib/{$name}": ["type:drupal-drush"] } }

The most common library type that a Drupal developer will install will be Drupal modules. So let’s look at the line of code specific to the module installation location:

"web/modules/contrib/{$name}": ["type:drupal-module"],

This line of code says that if the type of Composer library is drupal-module, then install it to the /web/modules/contrib/[MODULE MACHINE NAME] folder.

But how does Composer know that the library being downloaded is type drupal-module? Well, the key to this is in how Composer libraries are managed in the first place. Throughout this article and the one that precedes it, we have repeatedly looked at the composer.json file that defines this project. Well, every Composer library contains a composer.json file, and every composer.json file that comes with packaged with Drupal modules contains a type declaration as follows:

"type": "drupal-module",

When Composer is installing libraries, it looks for a type declaration, and when it finds one, if there is a custom install location set in composer.json for that type, the library is installed to the declared folder. Drupal themes are of type drupal-theme, Drupal profiles are of type drupal-profile, and so on, and they are installed to the folders declared in composer.json.

Managing Custom Drupal Code with Composer

Custom code for a project can be managed with Composer as mentioned in Part 1 of this series. Drupal convention generally separates contributed (3rd party) modules and custom modules into separate folders. To install custom code in the locations according to this convention, the following lines should be added to the installer-paths declaration in composer.json:

"web/modules/custom/{$name}": ["type:drupal-custom-module"], "web/profiles/custom/{$name}": ["type:drupal-custom-profile"], "web/themes/custom/{$name}": ["type:drupal-custom-theme"],

This code adds three additional library types for custom modules, custom profiles, and custom themes.

Next, you’ll need to add a composer.json file to the custom module/theme/profile. Directions for this can be seen here: https://www.drupal.org/docs/8/creating-custom-modules/add-a-composerjson-file. Note that for the step named Define your module as a PHP package, you should set the type as drupal-custom-[TYPE], where [TYPE] is one of: module, theme, or profile.

Continuing on, make sure the composer.json file containing the type declaration has been pushed to the remote private repository.

The last step step is to add your private repository to you project’s composer.json, so that when running composer require my/privatelibrary, Composer knows in which repository to look for the library. Declaring private repositories in composer.json is explained here: https://getcomposer.org/doc/05-repositories.md#using-private-repositories.

With the above steps, when running composer install my/library, Composer will find the private repository declared in composer.json, search that repository for my/library, and download it. The composer.json file in my/library tells Composer that it’s of type drupal-custom-[TYPE], so Drupal will install it into the directory specified for Drupal custom [TYPE].

If using Git for version control on your system, you'll probably want to alter the .gitignore file in the Composer project root to ignore the custom folder locations. If you have created a custom module, and will be managing all custom modules with Composer and private repositories, you should probably add the /web/modules/custom folder to .gitignore. If you will be managing some custom modules with Git and not Composer, then you should probably add the custom module you have created to .gitignore as /web/modules/custom/[MODULE NAME].

Managing site settings: settings.php and settings.local.php

This section isn’t actually directly related to Composer and Drupal, but it’s a good step for setting up a project, and we can use the methodology to work with Composer template and Git.

Each Drupal installation depends on the file settings.php. This file is loaded as part of Drupal’s bootstrap process on every page load. Site-specific settings are added into this file, such as database connection information.

Towards the bottom of settings.php, the following lines can be found:

# if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) { # include $app_root . '/' . $site_path . '/settings.local.php'; # }

These lines are commented out by the # symbol at the start of each line. This means that the code is not executed. If these lines are uncommented, by removing the hash symbol at the start of each line, this code is executed. The code looks for a file named settings.local.php, and if it exists, it includes that file. This means any settings in settings.local.php become part of the bootstrap process and are available to Drupal. After uncommenting the code, it will look like this:

if (file_exists($app_root . '/' . $site_path . '/settings.local.php')) { include $app_root . '/' . $site_path . '/settings.local.php'; }

Why do this? This allows settings to be split into two types: settings that will be the same across all environments (eg. production, staging, local installations etc), and local settings that are only relevant to the current Drupal environment in which this file exists. This is done by committing settings.php to Git so it is shared amongst every environment (note - settings.local.php is NOT committed to Git, as it should not be shared). For example, the majority of Drupal installations have a separate database for each environment, meaning that database connection details will be specific to each environment. Therefore, database settings would be put into settings.local.php, as they are not shared between environments. The connection details to a remote API however may be the same regardless of environment, and therefore would be put into settings.php. This ensures any developer working on the system has access to the API details.

After splitting up the settings this way, settings.php is committed to Git so it is tracked and shared between environments. 

The full process is as follows:

  1. Install the Drupal Composer template as described earlier in this article
  2. Uncomment the code in settings.php as explained above
  3. Install Drupal as normal
  4. Run git diff settings.php to see what has been added to settings.php as part of the installation process. Anything that shows up should be added to settings.local.php, and removed from settings.php. This will definitely be the database connection, but could be other files as well.
  5. Edit .gitignore in the Composer project root, and remove this line: /web/sites/*/settings.php You can now add settings for all environments to settings.php and settings specific to the local environment to settings.local.php.
Setting Up the Private Files Directory

After setting up settings.php and settings.local.php as described above, you can now add the following to settings.php:

$settings['file_private_path'] = ‘../private’;

Next, create the folder /private in the root of your Composer project. Finally clear the Drupal cache, which will create the file /private/.htaccess. At this point you can now add settings.php and the /private folder to Git. Finally, edit .gitignore and add the following:

# Ignore private files /private/ This sets up the private file directories across all installations, saving developers having to set it up for each installation. Note that the .gitignore setting will ensure the contents of this folder are ignored by Git, as they should be. What should I add to Git?

The Drupal Composer template project page states:

You should create a new git repository, and commit all files not excluded by the .gitignore file.

In particular, you will need to ensure you commit composer.json and composer.lock any time composer changes are made.

Is It Safe to Use Composer on a Production Server?

The actual answer to this question is not one I have. I am not a server guy overall, and for that matter, I’m not even that much of a Composer expert. It may be that Composer is entirely safe on a production server, but personally my thoughts are that having a program that can write files to the server from remote servers would seem to open up a potential security risk, and therefore it’s likely better to NOT have Composer on a production server. This comment may lead you to question why I would have wasted the time to write so much on Composer if it’s better to not use it in the first place. But not so fast partner! It really depends on the system architecture and the server setup. Some servers have been set up so that as part of the deployment process, the codebase is built using Composer, but then set up as a read-only file system or a Docker container or some other process ensuring security. This however is a particularly complex server set up. Fortunately there is an alternative for developers who are not working with servers configured in this fashion, which we'll look at next.

Using Composer, without having Composer installed on the production server

There is an in-between solution that allows us to use Composer to manage our projects, even with multiple developers, while not having Composer installed on the production server. In this case, we can use a hybrid of a Composer managed project and the old style of using pure Git for deployment.

First, we need to edit the .gitignore folder in the root of our Composer installation. In particular, we need to remove the following code:

# Ignore directories generated by Composer /drush/contrib/ /vendor/ /web/core/ /web/modules/contrib/ /web/themes/contrib/ /web/profiles/contrib/ /web/libraries/

The above directories are all created by Composer and managed by Composer, which is why they were originally ignored by Git. However, we will not be managing our production server using Composer, and therefore we want to include these folders into the Git repository rather than ignoring them.

After setting up your project, commit the folders listed above to Git. This ensures all the files that are managed by Composer will be part of Git. That waycomposer install never needs to be run on the production server, since any code that command would download will already be part of Git.

What this means now is that any time a developer on the project add/updates code by running either composer update or composer install, they will need to commit not just the composer.json and composer.lock files, but also the added/updated source files that Composer manages, so that all code be available on the production server when checking out the code from Git.

Updating Drupal using Composer

In part one of this series, I discussed library versions. I am not going to go deep into how the versioning works internally, but I’ll explain how updating works specific to Drupal core. At the time of writing, the current version of Drupal is 8.6.3. The dependency set in composer.json is for Drupal 8.6.*. The * at the end of this means that your project uses upon any version of Drupal 8.6, so when a minor version update comes out for 8.6, for example 8.6.4, Drupal core will be updated to Drupal 8.6.4 when composer update drupal\core is run.

However, when Drupal 8.7 is released, it will not be automatically installed, since it does not fit the pattern 8.6.*. To upgrade to Drupal 8.7, the following command is run:

composer update drupal/core:~8.7

The ~/8.7 part of the above command tells Composer to use any version of Drupal 8.7. This means that in the future, when you run composer update drupal/core, minor releases of the 8.7 branch of Drupal core will be installed.

Summary

In this article, we have gone over how Composer is used with Drupal to make project deployment a little smoother, more stable, and consistent between environments. You should have an understanding of:

  • How to set up a new Drupal project using Composer
  • How the following folders relate to the project:
    • /config
    • /drush
    • /scripts
    • /web
    • /vendor
  • How Composer adds Drupal modules and/or themes
  • Drupal library dependencies
  • Managing custom Drupal code with Composer
  • Which items should be committed to Git
  • How to use Composer to manage Drupal projects where the production server does not have Composer
  • How to update Drupal using Composer

In the next post, coming soon, we'll look at how to convert an existing Drupal project to being managed by Composer.

Categories: Drupal

Freelock : What's up on Nerd Mountain? Drupal 8 Means A Lot of Free Stuff

Planet Drupal - 21 November 2018 - 1:33pm
What's up on Nerd Mountain? Drupal 8 Means A Lot of Free Stuff Ben Weagraff Wed, 11/21/2018 - 14:33

Come join us up on Nerd Mountain! 

Drupal 7 Drupal 8 Drupal Planet
Categories: Drupal

Reference Map Advanced Access

New Drupal Modules - 21 November 2018 - 1:32pm
Categories: Drupal

Reference Map

New Drupal Modules - 21 November 2018 - 1:30pm
Categories: Drupal

PBS TV Schedule

New Drupal Modules - 21 November 2018 - 11:45am
About

PBS TV Schedule uses the TV Schedules API to provide a simple, themeable daily/weekly schedule view for PBS member station websites.

Categories: Drupal

NPD: Skipping single player didn't hurt sales for Call of Duty: Black Ops 4

Social/Online Games - Gamasutra - 21 November 2018 - 10:50am

An NPD Group analyst says that sales of Call of Duty: Black Ops 4 weren't hurt 'in the slightest' by the game's multiplayer-only model. ...

Categories: Game Theory & Design

External Link Pop-up

New Drupal Modules - 21 November 2018 - 9:31am

In progress

Categories: Drupal

Community: Community Working Group Update - November 2018

Planet Drupal - 21 November 2018 - 8:04am

The Drupal Community Working Group is happy to announce the addition of Alex Burrows (aburrows). Based in Surrey, United Kingdom, Alex has been contributing to the Drupal project and community for more than a decade. He is one of the lead organizers of Drupalcamp London, and a frequent speaker at other Drupal events. Alex also serves as a volunteer police constable in his local community.

The CWG would also like to announce that both Josef Dabernig (dasjo) and Manjit Singh (Manjit.Singh) have agreed to serve as Subject Matter Experts (SMEs) to the CWG. SMEs are not full members of the group, but can be called upon on an as-needed basis for issues that might require specific knowledge or expertise. SMEs are subject to the same Code of Ethics as full members of the CWG.

Adam Hill and Emma Karayannis are also officially stepping down as members of the CWG. We would like to thank both Adam and Emma for their invaluable contributions to the group and for their ongoing contributions to the Drupal community.

The CWG continues to seek new members and SMEs as it seeks to increase the diversity of its membership. It is our hope that by expanding our membership, the CWG will be able to better serve the community in a more proactive manner. If you think you or someone you know might be a good fit for the CWG and are interested in learning more, please reach out to us via email at drupal-cwg@drupal.org.

In other news, the CWG recently proposed a set of changes to its charter to address feedback and concerns raised by the community over the last year and a half. We are accepting feedback from the community through November 23 before finalizing the proposal.

The CWG is responsible for promoting and upholding the Drupal Code of Conduct and maintaining a friendly and welcoming community for the Drupal project. To learn more about the group and what we’ve been up to over the last year, check out our recently-published annual report.

Categories: Drupal

Wim Leers: State of JSON:API (November 2018)

Planet Drupal - 21 November 2018 - 6:50am

Gabe, Mateu and I just released the second RC of JSON:API 2, so time for an update! The last update is from a month ago.

What happened since then? In a nutshell:

  • Usage has gone up a lot! 2.0-RC1: 0 → 250, 2.x: ~200 → ~330 1
  • 2.0-RC2 released :)
  • RC1 had about half a dozen issues reported. Most are fixed in RC2. 2
  • The file uploads feature: 80% → 100%, will ship in 2.1!
  • The revisions feature: 80% → 90%
  • New core patch to bring JSON:API to Drupal core: #2843147-78
RC2

Curious about RC2? RC1 → RC2 has four changes:

  1. Renamed from JSON API to JSON:API, matching recent spec changes.
  2. One critical bug was reported by brand new Drupalist Peter van Dijk (welcome, and thanks for noticing something we had gotten used to!): the ?filter syntax was very confusing and effectively required the knowledge (and use) of Drupal internals. Now you no longer need to do /jsonapi/node/article?filter[uid.uuid]=c42…e37 to get all articles by a given author, but just /jsonapi/node/article?filter[uid.id]=c42…e37. This matches the JSON:API document structure: the abstraction is no longer leaky! The updated ?filter syntax is still 95% the same. 3
  3. JSON:API responses were no longer being cached by Page Cache. This was of course a major performance regression. Fortunately long-time Drupalist yobottehg discovered this!
  4. Massive performance increase for requests using sparse fieldsets such as ?fields[node--article]=title. Thanks to long-time Drupalist jibran doing quite a bit of profiling on JSON:API, something which Mateu, Gabe and I haven’t gotten around to yet. Moving 2 lines of code made his particular use case 90% faster! We’re sure there’s more low-hanging fruit, but this one was so tasty and so low-risk that we decided to commit it despite being in RC.

So … now is the time to update to 2.0-RC2!

The JSON:API team: 150/150/150

In the previous update, I included a retrospective, including a section about how it’s been to go from one maintainer to three. A month ago this happened:

11:08:15 <e0ipso> https://usercontent.irccloud-cdn.com/file/REdyLpD6/2018-10-24%2011-07-42.png 11:08:27 <e0ipso> Let's get that to 150, 150 and 150 11:08:31 <WimLeers> :D 11:08:46 <WimLeers> that'd be pretty cool indeed 11:09:05 <e0ipso> COMEON gabesullice you're slacking! 11:09:08 <e0ipso> hehe

That image was:

Well, as of yesterday evening, it looks like this:

On top of that, mere hours after previous update went live, Gabe became an official API-First Initiative coordinator, together with Mateu and I:

https://t.co/n9mB2BtKgn

This is up there at the top as one of my proudest Drupal moments :)

— Gabriel Sullice (@GabeSullice) October 25, 2018

Congrats Gabe, and thanks! :)

  1. Note that usage statistics on drupal.org are an underestimation! Any site can opt out from reporting back, and composer-based installs don’t report back by default. ↩︎

  2. Since we’re in the RC phase, we’re limiting ourselves to only critical issues. ↩︎

  3. This was not a regression in 2.x; this also affects JSON:API 1.x! It’s just more apparent in 2.x that this is a problem because we did make 2.x comply with the spec completely (which also was the reason for the 2.x branch: we needed to break backward compatibility to comply). We chose to embrace the feedback and introduce this additional BC break in the 2.x branch. Some of your requests will now return 400 responses, but they all include helpful error messages, providing concrete suggestions on how to change it. ↩︎

Categories: Drupal

InternetDevels: Top E-commerce Themes for Drupal 8

Planet Drupal - 21 November 2018 - 6:42am

What is the first thing that grabs your attention when you visit an E-commerce website? No doubt it is the website’s design and appearance.

Read more
Categories: Drupal

Pages

Subscribe to As If Productions aggregator