Inhalt abgleichen
Drupal.org - aggregated feeds in category Planet Drupal
Aktualisiert: vor 9 Minuten 43 Sekunden

Drupal core announcements: FAQ

28. März 2018 - 18:50

this is a faq

ThinkDrop Consulting: Newest version of DevShop eases Drupal update and release process.

28. März 2018 - 18:15
Newest version of DevShop eases Drupal update and release process. Jon Pugh Wed, 03/28/2018 - 12:15

In just a few hours, the first serious critical security update for Drupal since "Drupalgeddon" will be released.

To make this update easier for DevShop users, we've pushed out a new release with 2 features that allow you to update your sites without ever leaving your web browser: "Update, Commit & Push" and "Tag a Release".

"Commit & Push"

The "Update Drupal" button has been available in DevShop for some time, but now you can automatically commit the results by checking a box.

Acro Media: Custom Product Pages in the UH+ Drupal Commerce 2 Demo

28. März 2018 - 17:18

Acro Media recently launched a demo ecommerce site called Urban Hipster that exhibits the incredible range of out-of-the-box functionality you get with Drupal Commerce 2 (check it out here). To make the demo even more amazing, we've also created a “Plus” version that shows you what's possible with a bit of extra work.

Some background

If you have an ecommerce business or have a product that you're trying to sell online, a product catalog could be just what you need. But if you produce your own product or you only have a few different products, a product showcase is actually a better way to demonstrate and sell your wares. It's like buying something on Amazon vs buying something on Apple: Amazon has an enormous list of products and all the pages look the same, whereas Apple has fully customized, unique pages for each item it sells.

UH Axe builder product page

When you go to buy the UH Axe on the demo, you'll bring up a unique UH Axe builder product page in the Apple style. The page talks about what the UH Axe is and what its purpose is, and then you're able to choose the type of handle you want, the handle length, how heavy the axe head should be, whether you want a sheath, etc. By the time you add it to your cart, it has become a completely unique product with all the variations that you've chosen. But it exists and is configured the same way that any other product would.

It's actually a very similar configuration as the White and Wood Chair example on the demo; it just looks completely different.

The functionality behind a lot of the extra content is a module called Paragraphs. It's similar to Panels (which a lot of people use), but a bit simpler and more streamlined. It doesn't have the same breadth of functionality, but it's easier to work with, and it lets you do all those customizations like deciding where you want to put it on the page and so on. It looks very custom, but it is surprisingly configurable through the back end.

(A note of caution: while it's mostly out-of-the-box functionality, some of the more complex design elements did require a bit of custom code. That’s why it’s on the “Plus” demo.)

Keep in mind that it's not uncommon to have both ways of viewing the product: a fancy customized page as well as a more standard catalog. People can get to the product through either route.

The bottom line

You can make awesome product pages through Drupal Commerce without a lot of effort.

 

More from Acro Media Chat with us

If you'd like a personalized tour to discuss how Drupal Commerce fits into your ecommerce solution, give us a shout. We're happy to show and tell.

Mobomo: Key Drupal Taxonomy: Part 1

28. März 2018 - 16:26

When it comes to considering what is the best CMS for a website, most don’t know up from down or Drupal from WordPress. At Mobomo, we consider ourselves Drupal experts and have guided many of our clients through a Drupal migration. Drupal is a content management system that is at the core of many websites.  Drupal defines itself as “an open source platform for building amazing digital experiences.” These simple definitions make it sound easy, but it can in fact be very confusing. Listed below are some popular terms defined to help make the start of the migration process what it should be, simple and easy:

  1. Taxonomy – classification system.  In WordPress, this system is very similar to the Categories you’ll find in that CMS.
  2. Vocabularies – a category, or a collection of terms.
  3. Terms – items that go inside a vocabulary.
  4. Tags – generic way to start classifying your content (this is the default).
  5. Menus – refers both to the clickable navigational elements on a page, and to Drupal’s internal system for handling requests. When a request is sent to Drupal, the menu system uses the provided URL to determine what functions to call.  
    • There are 4 types:
      • Main
      • Management
      • Navigation
      • User
  6. Theme – look and feel of a site, determined by a combined collection of template files, configuration files and asset files (JavaScript, CSS, images, fonts). A theme contains elements such as the header, icons, block layout, etc. Drupal modules define themeable functions which can be overridden by the theme file. There are additional themes available in the themes section of downloads.
  7. Content Type – Every node belongs to a single “node type” or “content type”, which defines various default settings for nodes of that type, such as whether the node is published automatically and whether comments are permitted. Common “Content Types” that just about any website would have include: blog post and page. Content types can have different fields and modules can define their own content types. The core Drupal Book and Poll modules are two examples of modules that define content types
  8. Fields – Elements of data that can be attached to a node or other Drupal entities. Fields commonly contain text, image, or terms.
  9. Node – A piece of content in Drupal, typically corresponding to a single page on the site, that has a title, an optional body, and perhaps additional fields. Every node also belongs to a particular content type, and can additionally be classified using the taxonomy system. Examples of nodes are polls, stories, book pages and images.
  10. Views – module that lets gives you a click and configure interface for running database queries. It can output the results in a variety of formats.
  11. Views Display – created inside of a view to display the objects fetched by the view in different manners.
  12. Module – Code that extends Drupal features and functionality (but doesn’t provide the HTML markup or styling of a theme). Drupal core comes with required (pre-installed) modules and some which are optional. Thousands of non-core or “contrib” modules are listed in the project directory.
    • Core- features that are available within Drupal by default
    • Custom- modules that are developed for a specific purpose that are not available within Drupal Core
    • Contributed- after custom modules are created by Drupal developer, they are often made available to others within the Drupal community. There are more than 40,000 modules available today.

The post Key Drupal Taxonomy: Part 1 appeared first on .

Acquia Developer Center Blog: Checking for Bad Passwords in Drupal to Avoid Site Compromise

28. März 2018 - 15:42

Easy-to-guess passwords are all too often the means by which intruders gain unauthorised access. It's useful to be able to audit the passwords in use on your site - especially for user accounts with administrative privileges.

Ideally your Drupal site should have a robust (but user friendly) password policy (see my previous post: Password Policies and Drupal). However, this is not always possible.

Tags: acquia drupal planet

InternetDevels: 17 social media integration modules for Drupal 8

28. März 2018 - 15:39

Audience boosters, sales increasers, brand builders… All this and more applies to social networks! Drupal lets you easily integrate these unmatched promotion tools with your website. We have shared a great collection of Drupal social media integration modules in part 1 and 2.

Read more

Specbee: Building Custom Modules in Drupal 8 - Best Practices to Follow

28. März 2018 - 14:42
Recently, I was looking for a module in Drupal and something just crossed my mind. In the Drupal world, when you are looking out or considering for solutions, the first thing you might hear is, "there is a module for that!". While there are close to just 40 core modules in Drupal, it is the additional contributed modules built by the Drupal community that extends the platform's functionality.

Lullabot: A Development Workflow for Drupal 8 Projects

28. März 2018 - 12:43

Every development team has a particular way of working. However, over the years I have noticed that there are a few common practices that, once documented and agreed upon, can help considerably in the team’s productivity. This article aims to serve as a template for new and existing projects.

Assumptions

Feel free to copy the following contents to an internal page in your wiki and start discussing and adjusting it with your team. It’s crucial that everyone in the team is willing to give these practices a go for a sprint and then evaluate and adjust during the next sprint retrospective.

The README and CHANGELOG documents

Each repository must have a README file and may have a CHANGELOG document.

The README describes the project’s nature, lists requirements, and contains installation instructions. This document should contain everything that a developer needs to set up the project locally. If you are looking for a Drupal 8 specific one, here is an example.

The CHANGELOG is the living Release Notes document that allows anyone (developers, product managers, etc.) to understand exactly what changes are affiliated with a specific version of the project. This document is used when creating new releases to describe how should other teams update their current installations.

Working with repositories

It’s useful to receive notifications every time that someone makes changes in a repository. We encourage you to subscribe to pull requests in order to start learning from everyone's code by clicking on the eye icon at the top right corner of each repository's homepage:

undefined

Make sure you have a GitHub account with an SSH key. You can add your SSH key here and, after doing that, you can share it with the team by appending .keys to your profile, like this.

Setting up your environment

Each project is different, so look at the repository’s README for instructions on how to set it up. If you find a repository which does not have a README, use this one as a template.

Setting up your editor

You can use any editor to work on projects, but the one that offers the best integration with Drupal 8 at the moment is PHPStorm. Please take a few minutes to adjust PHPStorm to work with Drupal by reading this guide.

Working on a ticket

Each ticket should have its own branch or branches. A branch name should be prefixed with the ticket number and a one or two-word description (for example, PROJECTNAME-123-foo). Here is how you can do it:

cd /var/www/projectname git checkout master git pull origin master // Merge the current master into your branch. git checkout -b PROJECTNAME-123-foo // create and switch to a new branch 'PROJECTNAME-123-foo'

Once you are ready to push your changes, commit them to the branch with the following commands:

git status // Shows your changes. git add [file] // Add any new or modified files. Supports patterns. git add --patch [file] // Better yet, review changes and stage your hunks. git diff --cached // Shows what is about to be committed. Review it carefully! git commit -m "PROJECTNAME-123 Description shorter than 50 characters"

Aim to make small commits which you can describe easily in your branch. The Erlang project has a good guide for writing good commit messages. If you want to add further info to the commit message, skip the -m parameter and use the default editor to set the title and the description of the commit message.

If your pull request alters the installation process or requires additional steps during the updating process, then adjust the README and CHANGELOG files accordingly.

Writing and updating tests

Bug fixes and new features will be easier to peer review if the project's tests pass and the new code is covered by the tests. To get an idea of what sort of tests you may find, check out this article.

Ok, ship it!

Once you have completed the above section, push the branch to Github:

git push -u origin PROJECTNAME-123-foo // pushes your branch to the origin repository. PROJECTNAME-456 Fix video uploads only allowing mp4 undefined

Post a link to the pull request in the respective ticket and set it's status to "Needs Review" in order to track progress within the sprint.

Peer reviews

The rule of thumb of peer reviews is that nobody can push to master branch. Everything should happen in pull requests which are reviewed and merged by the rest of the team.

After creating the pull request, prepare it for code review by following this guide. Once the pull request is ready for review, add reviewers to it through the web interface. Here is an example:

undefined

When merging a pull request, follow the git standards with a short one-line message, a blank line, and paragraphs if needed. Here are two sample merge commits::

[#pr-number] PROJECTNAME-123: Summary of the work being merged PROJECTNAME-123: Summary of the work being merged #pr-number

Finally, if this pull request completes the Jira ticket, then open it and change its status to the next one, which normally is "In QA", if you have a QA team, or "Done" if not.

How to create a release

If you are distributing code to be deployed by other teams, then your team needs to keep a CHANGELOG which evolves along with the code. Review the section "The README and CHANGELOG documents" for an introduction.

Once the sprint has completed, it is time to create a release. Here are the steps to follow:

  1. If there is Continuous Integration, check that all tests pass and that there is the same or higher coverage that by the end of the previous sprint. If not, request the development team to fix this.
  2. Clone the repository where you want to create the new release.
  3. Create a new branch where you update the module's CHANGELOG by setting a version number at the top. If the module does not have a CHANGELOG file yet, create one using the example further above as a template.
  4. Developers indicate the level bump needed for each change by indicating it with the word "PATCH", "MINOR" or "MAJOR". This takes into account semantic versioning. So, depending on the changes that this release includes you increase either the PATCH, MINOR or MAJOR number for the next version.
  5. Once the pull request has been approved by the team, merge it.
  6. Create a tag: git tag -a [VERSION]
  7. Enter a description of what is being released on this tag.
  8. Push the tag to the repository: git push origin [VERSION].

Note: If you need to double check anything stated in the CHANGELOG while preparing the release, you may use the following command to retrieve all commits since the last release:

git log --oneline --reverse --first-parent <insert last tag version here>.. | cut -c 9- git log --oneline --reverse --first-parent 1.0.0.. | cut -c 9- Ticket review guide

Here are a few tips for both sides: the individual working on the code and the people reviewing the pull request.

For the pull request authors
  • Make sure that the checked in code does what the ticket specifies.
  • Use code sniffer to check and fix violations against Drupal’s coding standards.
  • Add comments on the code as you see fit. This is useful not only for maintenance but also for peer reviewers.
  • Make sure that your set of changes are covered by reasonable PHPUnit or Behat tests.
  • Write a summary of what the code does and other related info such as screenshots. Include manual testing instructions if needed.
  • If there is Continuous Integration, verify that all jobs pass.
For the reviewers
  • Verify that all the jobs executed by the Continuous Integration tool are passing. If there are failures, inspect the logs and notify the pull request’s author.
  • Check that the code is easy to follow, respects Drupal’s Coding Standards, and is documented.
  • If there are no tests, consider suggesting how they could be written.
  • Look for performance and security risks. If you need tips, this guide offers great help.

Further tips can be found at The Peer Review How-To guide.

Acknowledgments

This guide is the result of working with the following clients, which we thank deeply:

Plus, the following folks at Lullabot:

Agiledrop.com Blog: AGILEDROP: What Marketing Tools and Services can Digital Agencies Integrate with Drupal 8

28. März 2018 - 12:32
Automation is a term that probably defines the need of technology most perfectly. Automation not only helps to make menial and repetitive tasks easier but also helps with keeping track of the work that is being done. Due to this fact, there have been a host of marketing automation tools and services that have cropped up in recent history (e.g.: HubSpot). Previously, integrating such platforms in a website was somewhat of a difficult task, but luckily Drupal has realized the need for easier integration with such platforms and starting with Drupal 8, it has become a lot easier to integrate… READ MORE

Dries Buytaert: Matthew's Documentation Initiative Proposal

28. März 2018 - 11:43

Last month, Matthew Grasmick sparked an important conversation surrounding Drupal's evaluator experience and our approach to documentation. It's become clear that we need to evolve our documentation governance model, in addition to formalizing best practices.

After receiving a tremendous amount of support and feedback, Matthew has continued the conversation by publishing a Documentation Initiative Proposal. Matt's proposal includes an evaluation of our current state, a picture of what success could look like, and what you can do to get involved. If you are passionate about improving Drupal's evaluator experience, I would encourage you to read Matt's proposal!