Chapter Three: Overriding Drupal 8 Configuration Values in settings.php

Planet Drupal - Wed, 2016/03/30 - 8:31pm

In previous versions of Drupal you would see values from settings.php on the coniguration pages. For instance $conf['mymodule_setting_value'] = 'My Value'; would display "My Value" in the text field and whenever you would try make a change to the field and try hit save button the value of the field would reset to the value specified in settings.php . However in Drupal 8 overridinen configuration form values in settings won't reflect in the form.



There is an issue on Drupal.org for that and developers already found a solution and it should be fixed in Drupal core soon.

Categories:

Doug Vann: Delivering Training On Drupal 8 Site Building And Pantheon Workflow At TexasCamp2016

Planet Drupal - Wed, 2016/03/30 - 7:24pm


It's 2016 and pretending like Drupal 8 doesn't exist is not an option. Which is why you will find me in Dallas this weekend spreading the love for Drupal 8! Almost 5 months out from its November 2015 launch it is gaining more traction and visibility at Drupal events.

I am still seeing many many many sites starting in Drupal 7 these days, but when I had the opportunity to provide a day of training at the inaugural TexasCamp, I knew what I had to do. I knew that many ppl would be showing up wanting to understand Site Building in the new world of Drupal 8. I also knew that the biggest game changer in D8 [IMO] is Configuration management. Therefore I HAD to cover that aspect of Drupal 8 and I had to do so WITHIN THE CONTEXT of Site Building.

This is not as far a departure from previous Drupal 7 trainings I have performed in dozens of camps, user groups, LinuxFests, and private clients. Where possible, I have always tried to bring in at least some element of DevOps into the training. With Drupal 8, there simply is no avoiding the topics of DevOps, multi-stage development, or call it what you will.

A Perfect pairing of Drupal 8 and Pantheon! I have always advocated that anyone testing Drupal 7 or Drupal 8 should whip up a quick, free, and easy Pantheon sandbox. For many years I have led many classrooms full of fresh minds through the process of building their first Drupal site on the Pantheon platform. Even though many attendees are beginners, they often come from companies who either have already invested a great deal into Drupal, or soon will. This is thanks largely to the "Ownership Society" that Drupal promotes. It will be exciting to see the response from my 1st full day of Drupal 8 training!

Drupal Planet

View the discussion thread.

Categories:

Drupal Association News: Two new board members for the Drupal Association

Planet Drupal - Wed, 2016/03/30 - 7:00pm

At the Drupal Association, we love to highlight that contribution comes in all forms. We are extremely grateful to the Association board members who contribute an enormous amount of time and are so generous with their knowledge and contacts in building a stronger Drupal community. Anyone who has ever served on or worked with a board knows that it's important, hard, and sometimes fun work. 

We're thrilled that two more folks are joining us on the board. Help us welcome them both:

Steve Francia, Class Director

Steve Francia was just nominated and elected to a Class Director seat on the board, a three year term. Steve Francia is a very active member of the open source community. He has been responsible for two of open source's largest projects as the Chief Operator of the Docker project and the Chief Developer Advocate of MongoDB, as well as creating some of the top community-based open source projects: Hugo, spf13-vim, Cobra and Viper. He has spoken all over the world delivering inspiring talks and workshops and has even organized a few conferences. He's written books for O'Reilly, blogs at http://spf13.com and tweets as @spf13. He's used Drupal since Drupal 4. He lives outside NYC and enjoys having fun outdoors with his wife and four children.

Shyamala Rajaram, At-Large Director

Shyamala Rajaram is the newly elected At-Large Director. With over a decade of experience in designing and developing solutions using open source platforms, Shyamala has acquired a rich and varied expertise in many different technologies related to web, mobile and cloud. She is a co-founder and Director of Social Media Solutions at UniMity Solutions based in Chennai, India. Shyamala manages and builds the Drupal Solutions Practice at UniMity, including their hugely popular Drupal-based Social Workspace platform. Shyamala is an active participant in the Drupal community and has made contributions to the enhancements, usage and adoption of Drupal (Drupal.org redesign and Drupal 8 Mobile initiative being the main ones). She is an Engineer from the Indian Institute of Technology, Madras—one of India’s premier technology institutions.

Categories:

Cheppers blog: Drupal Global Training Day 2016 Budapest

Planet Drupal - Wed, 2016/03/30 - 6:25pm

Global Training Days is an initiative of the Drupal Association organized quarterly in many cities around the globe. The event is a great opportunity to make the attendees familiar with the basics of Drupal, the content management system. The goal of the trainings is to introduce Drupal to a wide audience and teach the attendees 'how to Drupal' on an introductory training. 

Categories:

ImageX Media: ImageX Announces Two New Client Reviews on Clutch.co

Planet Drupal - Wed, 2016/03/30 - 5:29pm

ImageX is pleased to announce the submission of two new client reviews on Clutch.co, a research firm who reviews the top development, design, and marketing companies. ImageX chose to participate with Clutch’s research efforts in an effort to provide transparency to the marketplace, where both Clutch, as well as past and present ImageX clients, would have an opportunity to provide feedback, analysis and general assessments of our work and services.

Categories:

Dries Buytaert: Examples of how to make Drupal outside-in

Planet Drupal - Wed, 2016/03/30 - 4:58pm

The authoring experience improvements we made in Drupal 8 appear to be well-received, but that doesn't mean we are done. With semantic versioning in Drupal 8, we can now make more UX changes in follow-up releases of Drupal 8. So now is a good time to start moving Drupal's user experience forward.

The goal of this post is to advance the conversation we started over a month ago in a blog post called Turning Drupal outside-in. In this blog post, we'll show concrete examples of how we could make site building in Drupal easier by embracing the concept of outside-in. We hope to provide inspiration to designers, core contributors and module maintainers for how we can improve the user experience of Drupal 8.2 and beyond.

What is outside-in?

In Drupal you often have to build things from the ground up. If you want to make a list of events you need to wade through 20 different menu options to a user interface with configuration options like "boolean" and "float", build a content type, content, and then a view. Essentially you need to understand everything before you can build anything.

In an "outside-in" experience – or what Kevin OLeary (Director of Design, OCTO) calls Literal UI – you can click anything on the page, edit its configuration in-place, and watch it take effect immediately.

Over the past few years Drupal has adopted a more outside-in approach, the most obvious example being Drupal 8's in-place editing. It enables you to edit what you see with an uninterrupted workflow, faster preview, and removes the need to visit the administration backend before you can start editing.

To evaluate how outside-in can be applied more broadly in order to make Drupal easier to use, Kevin created a few animated gifs.

Example #1: editing menu items The current inside-out experience

Editing menu options in Drupal has already become more outside-in with contextual links. The contextual links take away some of the guesswork of finding the proper administration UI, but once you arrive at the configuration page there is still a lot of stuff to take in, only some of which is relevant to this task.



The current inside-out experience for editing a menu item: adding a menu link and changing its position involves 2 separate administration pages, 4 page refreshes and more than 400 words of text on the UI.

Anyone familiar with Drupal will recognize the pattern above; you go to an administration UI, make some changes, than you go back to the page to see if it worked. This context switching creates what UX people call "cognitive load". On an administration page you need to remember what was on the site page and vice-versa.

To complete this task you need to:

  1. Find the contextual link for the menu (not simple since it's on the far side of the page)
  2. Choose the correct option "edit menu"
  3. Find and click the "add link" button
  4. Type the menu link name
  5. Type the menu link path beginning with a forward slash
  6. Understand that this change needs to be saved
  7. Scroll to the bottom of the page
  8. Save the link
  9. Find the link in the list of links
  10. Understand that dragging up/down in this abstraction is equivalent to moving right/left in that actual page
  11. Scroll to the bottom of the page
  12. Save the menu

The problem is not just that there are too many pages, clicks, or words, it's that each step away from the actual page introduces new opportunities for confusion, error and repetition. In user testing, we have seen users who were unable to find the contextual link, or to understand which option to choose, or to find the "add link" button, or to add a path, or drag-drop links, or to save before leaving the UI. When these things happen in context feedback about whether you are "doing it right" is immediate.

The proposed outside-in experience



The proposed outside-in experience for editing a menu item. Rather than moving out-of-context to an administration page to get the job done, configuration happens right on the page where you see the effect of each action. You start adding a menu item simply by selecting the menu on the page. Both the menu item and the item's path are in focus to reinforce the connection. As you type a path is proposed from the link text.

Now all you need to do is:

  1. Click the menu on the page
  2. Find and click the "add link" button
  3. Type the name of the menu item
  4. Revise the menu item's path if needed
  5. Drag the link to its new location
  6. Close the drawer

One important aspect of this approach is that all actions that produce a visible change have bi-directional control and bi-directional feedback. In other words, if you can drag something in the configuration drawer you should also be able to drag it on the page, and the changes should happen simultaneously.

Example #2: adding a block to a page The current inside-out experience

The process of adding a block can be difficult. Once you discover where to go to add a block, which is in itself a challenge, the experience requires a lot of reading and learning, as well as trial and error.



The current inside-out experience for adding a block. Not all steps are shown.

To complete this task you need to:

  1. Figure out where to go to place a block
  2. Go to /block-layout
  3. Go to /display-regions to find out where the region is on the page
  4. Go back to /block-layout
  5. Find the region and click "add block"
  6. Find the block you want to place and click "place block"
  7. Configure the block
  8. Read about how blocks can appear on multiple pages and for different content types and roles
  9. Read what content types are
  10. Read what roles are
  11. Read what a "path" is
  12. Read how to find the path for a page
  13. Go back to the page and get its path
  14. Go back to /block-layout and add the path to the visibility settings
  15. Drag your block to the position where you want it
  16. If your blocks are arranged horizontally, learn that "up and down" in the block layout UI will mean "left and right" on the actual page
  17. Find the"back to site" link
  18. Go back to the page to see if you did it right

Eventually you'll use what you just learned, but Drupal makes you learn it first instead of just showing what is immediately necessary. Both the task and the learning can be simplified by bringing the configuration closer to the object you are configuring.

The proposed outside-in experience



The proposed outside-in experience for adding a block. Everything happens on the actual page rather than on an administration page. Places where things can be added appear on hover. On click they show thumbnails that you can filter with autocomplete.

Now all you need to do is:

  1. Choose where to place the block
  2. Find the block you want to place
  3. Place the block
  4. Close the drawer

The "plus" button, the drop target (blue dotted rectangle) and the autocomplete are all commonly understood patterns used by other software. The task requires no or little explanation as the interactions reveal the process. By starting with selecting the location of where to place the block, we avoid the need for drag-and-drop and the complexity of dragging a block on a page that requires scrolling.

Principles and patterns

These examples show the principle that rather than taking the site builder to a separate administration backend, the experience should begin with the actual page and show how the changes will be seen by the end-user. The patterns shown here are less important. For example the animated gifs above show two different approaches to the options panel and there are certainly others. The important thing is not yet where the panel comes from or how it looks, but that the following criteria are met:

  • An option panel is triggered by direct interaction.
  • When triggered it only shows options for what you selected.
  • It primarily shows configuration options that produce a visible change to the page. More complex options could be accessed through an 'Advanced options' link.

The ideas in this post are meant to provide some food for thought and become the seed of some patches for Drupal 8.2. Rather than dive right into development, we're looking to the Drupal community to take these designs as a starting point to prototype and user-test more outside-in experiences in Drupal.

The next post in this series will cover outside-in experiences with more complex contexts and the problem of "leaky abstractions". If you don't want to miss the next blog post, make sure to subscribe.

Special thanks to Kevin OLeary for advocating outside-in thinking. Thanks to Preston So, Gábor Hojtsy, Angie Byron, Bojhan Somers and Roy Scholten for their feedback.

Categories:

Four Kitchens: Meet Aquifer: A build system for easier Drupal development

Planet Drupal - Wed, 2016/03/30 - 4:36pm

Using a build system streamlines the development process, reduces errors in repetitive steps, and keeps the code repository lean and well organized. Aquifer—a command line interface that makes it easy to scaffold, build, test, and deploy your Drupal websites—has become a valuable part of the Four Kitchens development process. …

Categories:

Valuebound: How to write the custom Drush Commands in Drupal 8?

Planet Drupal - Wed, 2016/03/30 - 3:27pm

Writing custom drush commands in Drupal 8 is not exactly like Drupal 7 but it is similar. Here also, we are implementing hook_drush_command().   

The only difference is in the file structure.  As we all know In Drupal 8 ‘.module’ file is not mandatory in the module root folder. Hence In Drupal 8 for creating custom drush commands, we only need two files.

  1. MyModuleName.info.yml
  2. MyModuleName.drush.inc

Where,description will be listed under Other commands: (custom_drush_command)

'description' => 'Echo the name you type with Say…

Categories:

Lullabot: Injecting services in your D8 plugins

Planet Drupal - Wed, 2016/03/30 - 9:51am

Drupal 8's plugin system is one of the most flexible and widely used subsystems in Drupal. If you are a developer, chances that you will write plugins in Drupal 8 are high.

A couple of months ago I made a case in favor of unit tests in a series of articles. Today I have good news for you, your plugins are good candidates for testing! Before you get carried away by overexcitement, it's likely that your plugins depend on other parts of the system, and that complicates things a little bit. In these cases, it is a good idea to inject the services that include the dependencies you need. Dependency injection is an alternative to the static \Drupal::service. If you don't inject your services you will have a hard time writing unit tests for your plugin's code.

There are, at least, two widely spread patterns in Drupal 8 in order to inject services into your objects. The first uses a service to inject services. The second uses a factory method that receives Drupal's container. Both of these involve the dependency injection container, although you can still inject services using other manual techniques.

Injection via services

When you declare a new service you can also specify the new service’s dependencies by using the arguments property in the YAML file. You can even extend other services by using the parent property, having the effect of inheriting all the dependencies from that one. There is thorough documentation about writing services on drupal.org. The following example defines a service that receives the entity manager:

services: plugin.manager.network.processor: class: Drupal\my_modyle\Plugin\MyPluginManager arguments: ['@container.namespaces', '@cache.discovery', '@module_handler', '@entity.manager']

You cannot use this pattern directly to inject services to a plugin, since your plugin cannot be a service. This is because services are one-instance classes, a global object of sorts. Plugins are –by their definition– multiple configurable objects of a given class. However, the plugin manager is a great candidate to be a service. If you declare your plugin manager as a service, and inject other services to it, then you are only one step away from injecting those services into the actual plugin instances. To do so you only need to do something similar to:

class MyPluginManager extends DefaultPluginManager { protected $entityManager; … public function createInstance($plugin_id, array $configuration = array()) { $instance = parent::createInstance($plugin_id, $configuration); $instance->setEntityManager($this->entityManager); return $instance; } }

As you can see (aside from the lack of docblocks for brevity), every time that your plugin manager creates an instance of a plugin it will set the entity manager for that particular instance. in this scenario you only need to write setEntityManager in your plugin. This strategy is a mix of service injection and setter injection.

Factory injection

The other big injection pattern in Drupal 8 involves adding all your dependencies as arguments in the constructor for your class (also known as the constructor injection pattern). This pattern is very straightforward, you just pass in all the dependencies upon object creation. The problem arises for objects that Drupal instantiates for you, meaning that you don't get to do new MyClass($service1, $service2, ...). How do you pass the services to the constructor then? There is a convention in the Drupal community to use a factory method called create. To implement it you need to write create static method that will receive the dependency injection container as the first parameter. The create method should use the container to extract the services from it, and then call the constructor. This looks like:

class MyOtherClass { … public function __construct($service1, $service2, ...) { // Store the services in class properties. } public static function create(ContainerInterface $container) { // new static() means "Call the constructor of the current class". // Check PHP’s late static binding. return new static( $container.get('service1'), $container.get('service2'), … ); } }

There is the remaining question of "who calls the create method with the container as the first parameter?". If Drupal is instantiating that object for you, then the system should know about the _create method pattern_ for that particular object.

The default plugin manager (\Drupal\Core\Plugin\DefaultPluginManager) will use the container factory (\Drupal\Core\Plugin\Factory\ContainerFactory) to create your plugin objects. It is very likely that your new plugin manager extends from the default plugin manager –via code scaffolding or manual creation–. That means that by default if you add a create method to your plugin, it will be ignored. In order to have your new plugin manager use the create pattern, the only thing your plugins need is to implement the ContainerFactoryPluginInterface. In that case your plugin will look like:

class MyPluginBase extends PluginBase implements PluginInspectionInterface, ContainerFactoryPluginInterface { protected $entityManager; … public function __construct(array $configuration, $plugin_id, $plugin_definition, EntityManagerInterface $entity_manager) { parent::__construct($configuration, $plugin_id, $plugin_definition); $this->entityManager = $entity_manager; } public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) { return new static( $configuration, $plugin_id, $plugin_definition, $container->get('entity.manager') ); } }

The plugin manager will detect that the object that it's about to create implements that interface and will call the create method instead of the basic constructor.

The plugin system is so extensible that you may run into corners where those techniques are not enough. Just know that there are other ways to achieve this. Some of those, for instance, involve using a different factory in the plugin manager, but that is out of the scope of this article.

Sometimes the create factory method pattern can be considered a bit more robust, since it does not involve injecting the services to an object that doesn't need them –the plugin manager– only to pass them down to the plugin. Regardless of the approach that you use, you are now in a good position to start writing unit tests for your plugin class.

Categories:

Unimity Solutions Drupal Blog: Elected to Board of Drupal Association

Planet Drupal - Wed, 2016/03/30 - 9:16am

Excited to share I have been elected to the Board of Drupal Association, https://assoc.drupal.org/blog/holly.ross.drupal/2016-drupal-association-.... The support and campaigning of all my friends and well-wishers and the Drupal community has helped me get to this prestigious post! Thanks all for your confidence in me! Looking forward to my contributions to Drupal in this new role.

Categories:

Gizra.com: Docker and Travis-CI

Planet Drupal - Tue, 2016/03/29 - 11:00pm

If you have ever had to setup Travis-CI, I'm sure you know where the biggest pain point is - debugging the machine.

We have lost so many hours on intermediate commits, waiting for Travis to spin up a new box, run the scripts only to see it fail on the last command. Not to mention how hard it is to debug a webapp on a machine you don't have direct access to, and there is no browser.

But there's a new and better way - we can use Docker inside Travis.

What does that mean? In short, it means that setting up Travis, and debugging your test scripts has just become much easier. You can do all the setup, and the debugging from your own local computer!

Behat tests running from within the container

Continue reading…

Categories:

Web Wash: Lightning Talk: Page Manager and Panels in Drupal 8

Planet Drupal - Tue, 2016/03/29 - 9:34pm

At March's Sydney Drupal user group, I did a lightning talk on Page Manager and Panels in Drupal 8. In the talk, I demonstrate both modules and show you how to create a custom homepage with a few clicks. You can watch the whole talk in the video above.

Panels in Drupal 8 has changed considerably. The UI for building pages is now offered by Page Manager, with Page Manager UI installed, and not Panels itself. The UI also changed, but I think it's much easier to use than in Drupal 7, but that's my opinion.

Categories:

Annertech: Decoupling Features (so your support time sleeps easier at night)

Planet Drupal - Tue, 2016/03/29 - 9:31pm
Decoupling Features (so your support time sleeps easier at night)

You're working on a client's existing site, and they ask for some new functionality. Your first thoughts are: "Yay, some work!" Quickly following that you think: "What do they want? How am I going to build it?" The often unasked question, however, is "How can I integrate this new functionality with what they already have, without making maintenance a nightmare, or even worse, impacting existing functionality?"

This is a tough ask, as the new feature has the potential to reach across multiple pages, content types and styles.

Categories:

Four Kitchens: Trip Report: MidCamp 2016

Planet Drupal - Tue, 2016/03/29 - 8:15pm

MidCamp 2016 was just over a week ago in Chicago. For those unfortunate folks who couldn’t make it to the Second City, here are some highlights. …

Categories:

Acquia Developer Center Blog: Drupal 8 Module of the Week: Search API

Planet Drupal - Tue, 2016/03/29 - 7:58pm

Each day, more Drupal 7 modules are being migrated to Drupal 8 and new ones are being created for the Drupal community’s latest major release. In this series, the Acquia Developer Center is profiling some of the most prominent, useful modules, projects, and tools available for Drupal 8. This week: Search API.

Tags: acquia drupal planetsearchapache solracquia searchSearch API
Categories:

Drupal core announcements: Drupal 8.1.0-rc1 on April 6 and what it means for 8.0.x

Planet Drupal - Tue, 2016/03/29 - 7:35pm
Start:  2016-04-05 12:00 - 2016-04-07 12:00 UTC Organizers:  xjm catch Event type:  Online meeting (eg. IRC meeting)

Drupal has adopted semantic versioning and a scheduled release cycle starting with Drupal 8.0.0. This means that it is possible within a major Drupal version to add new functionality in a backwards-compatible way, and there is no need to wait for Drupal 9 for improvements. The first such version, Drupal 8.1.0, is going to be released on April 20th 2016, including such improvements as the experimental Drupal Upgrade UI module (for migrating from Drupal 6 and 7) and the BigPipe module (to enhance perceived site performance).

To prepare for Drupal 8.1.0, we released two beta versions in March. Announcements for beta1 and beta2 detail the significant changes made since Drupal 8.1.0. Now, we are ready to create Drupal 8.1.0-RC1, the first release candidate, on April 6, 2016. This means several things in terms of support for Drupal 8.0.x versions and allowed patches in Drupal 8.1.x:

  • Starting April 6, the 8.1.x branch will be subject to release candidate restrictions, with only critical fixes and certain other limited changes allowed.
  • To ensure a stable and timely release candidate, a commit freeze for the 8.1.x branch will begin April 5 at 12:00 UTC.
  • April 6 is also the final scheduled patch release window for 8.0.x, and it will not receive further development or support after that date aside from its final security release window on April 20 (which will not include bug fixes). Site owners and module or theme authors should prepare to update to 8.1.x.
  • As a consequence, all outstanding issues filed against 8.0.x will be automatically migrated to 8.1.x after the final 8.0.x patch release. Future bug reports should be targeted against the 8.1.x branch.
  • 8.2.x will remain open for new development during the 8.1.x release candidate phase.

See the Drupal core release cycle overview, Allowed changes during the Drupal 8 release cycle, and Drupal 8 backwards compatibility and internal API policy for more information.

Minor versions like Drupal 8.1.0 may include changes to user interfaces, translatable strings, themes, internal APIs like render arrays and controllers, etc. (See the Drupal 8 backwards compatibility and internal API policy for details.) Developers and site owners should test the release candidate to prepare for these changes.

Categories:

DrupalCon News: Government Joins the Summit Lineup

Planet Drupal - Tue, 2016/03/29 - 7:29pm

Are you currently working for the government in some way, shape, or form? Maybe you're a fed or are contracting for a government project or agency, or you want to work with the government and are interested in using Drupal to do it. If you fall into any of these categories, we have a great opportunity for you!

Categories:

ImageX Media: The Accidental Project Manager

Planet Drupal - Tue, 2016/03/29 - 6:43pm

Categories:

SitePoint PHP Drupal: Drupal 8 Entity Validation and Typed Data Explained

Planet Drupal - Tue, 2016/03/29 - 6:00pm

Data validation is a very important part of any application. Drupal 7 has a great Form API that can handle complex validation of submitted data, which can then be turned into entities. However, form level validation is problematic. For example, it becomes difficult to handle entity (data) validation programmatically. We have to either reimplement validation logic or mimic form submissions in code. This makes any data interaction dependent on the form system and this is a bad idea.

With the introduction of subsystems such as the REST API, Drupal 8 needed something better to handle this problem. The Symfony Validation component was chosen and Drupal 8 builds on top of it to tailor for the realties of the Typed Data and plugin based Entity system. So now, form submissions validate entities just like REST calls do or any other programmatic interaction with the entities easily can.

In this article, and its followup, we will explore the Drupal 8 Entity Validation API, see how it works, and how it can be extended. To better understand this, we will also take a look at the Typed Data API which underpins the entity system in Drupal 8. There will be some code examples that already exist in core but we will also write a bit of our own code which can be found in this git repository within the demo module.

Typed Data

Typed Data is the Drupal 8 API that was built to provide a consistent way of interacting with data or metadata about the data itself. Why is this important for our topic? Because validation is defined and invoked on typed data objects.

Two important components of this API stand out: the data definition and the DataType plugins. The role of the former is to define data and how interaction works with it (including things like settings or validation constraints). The role of the latter is to provide a way to get and set values from that type of data. When they are instantiated, data type plugins make use of data definition instances passed on by the plugin manager. The latter can also infer which data definition needs to be used by a DataType plugin type.

Let’s see an example:

$definition = DataDefinition::create('string') ->addConstraint('Length', array('max' => 20));

We created a string data definition and applied the Length constraint to it. Constraints are a key part of the validation API and they define the type of validation that will run on the data. They are coupled with a validator that actually performs the task, but we will see more about constraints and validators in the second part of this series.

Continue reading %Drupal 8 Entity Validation and Typed Data Explained%

Categories:

Acquia Developer Center Blog: APIs in Drupal 8: the Services Module

Planet Drupal - Tue, 2016/03/29 - 5:02pm

Web services and APIs (application programming interfaces) are hot topics among Web developers -- for two good reasons.

  1. Many developers now want to expose content and features on their site via Web services or APIs.
  2. It's getting easier to take advantage of these services. Drupal 8, for example, now has this capability in core. And some contributed modules are attempting to make it even better.

This is why Acquia and Palantir.net, the Chicago-based Web strategy, development, and design firm, have been working together on a Web services series.

Tags: acquia drupal planet
Categories: