Drupal

Twig Field Value

New Drupal Modules - 8 July 2016 - 2:29pm

Twig Field Value allows Drupal 8 themers to print field labels and field values individually. It provides two Twig filters one that prints the field label and one that prints field value(s).

Single field value

<strong>{{ content.field_name|field_label }}</strong>: {{ content.field_name|field_value }}

Multiple field values

Categories: Drupal

Embedded Node Form API

New Drupal Modules - 8 July 2016 - 2:17pm

Have you ever needed to stitch together several node forms into one giant form, perhaps as part of a multistep form workflow?

Look no further! This module provides an API for:

Categories: Drupal

Drulenium GitLab

New Drupal Modules - 8 July 2016 - 1:36pm

Gitlab Support for Drulenium module.

Categories: Drupal

ImageX Media: Higher Education Notes and Trends for the Week of July 4, 2016

Planet Drupal - 8 July 2016 - 12:22pm

The landscape of higher education continues to shift toward changing student demographics, evolving different learning approaches and what seems like a perpetual shortfall of funding for post-secondary institutions. These trends mirror that of our client website aspirations which are now more than ever are focusing on engagement with key audiences such as prospective students and alumni due to greater competition in the marketplace with less dollars to spend. 

Categories: Drupal

Chromatic: Digging In To Drupal 8: Code Snippets for Site Builders

Planet Drupal - 8 July 2016 - 10:36am

The more I work with Drupal 8, the more I realize how much has changed for developers in the Drupal community. While the transition to a modern, object-oriented system is what's best for the longevity of the platform, it certainly doesn't come without challenges. As someone who doesn't come from an OOP background, I've found the transition difficult at times. In many cases, I know exactly what I want to do, just not how to do it the "Drupal 8 way". On top of this, tutorials and blog posts on D8 are all over the map in terms of accuracy. Many posts written during D8's development cycle are no longer applicable because of API changes, etc.

Below is a list of snippets that might be helpful to site builders or developers more familiar with D7 hooks and procedural. It might also be useful to OOP folks who are new to Drupal in general. My goal below is to add to and update these snippets over time.

Routes & Links Determine the Current Drupal Route

Need to know what the current Drupal route is or need to run some logic against the current route? You can get the current route like so:

$route = \Drupal::routeMatch()->getRouteName();

To some, the \Drupal::routeMatch() syntax might look foreign (it did to me). Here's a rundown of what's happening here:

First, \Drupal. This is calling the global Drupal class, which, in Drupal 8, is a bridge between procedural and OO methods of writing Drupal code. The following comes from the documentation:

This class acts as a unified global accessor to arbitrary services within the system in order to ease the transition from procedural code to injected OO code.

Right. Moving on to ::routeMatch(). Here we're using the routeMatch() method which "Retrieves the currently active route match object." Simple enough. But what is "::" all about? This StackOverflow answer helped me to understand what that's all about.

From there, the getRouteName() method returns the current route name as a string. Here are some example routes: entity.node.canonical, view.frontpage and node.type_add.

Is this the Front Page Route?

Need to check if the current route is the front page route? There's a service and method for that:

// Is the current route/path the front page? if ($is_front = \Drupal::service('path.matcher')->isFrontPage()) {}

Here we're calling the path.matcher service (defined in /core/core.services.yml) and using the isFrontPage() method. For more on services, check out the "Services and Dependency Injection Container" documentation on api.drupal.org which helped me understand how all of these bits work together and the why of their structure.

Get the Requested Path

Need to know what the current page's requested path was, as opposed to the route? You can do this:

$current_uri = \Drupal::request()->getRequestUri(); Redirect to a Specific Route

Need to redirect to a specific page? In Drupal 7, you would likely handle this with drupal_goto() in your page callback function. In Drupal 8, you can use RedirectResponse() for that. Here is the relevant changelog.

Here are some examples, borrowed heavily from said changelog. First, in procedural PHP:

use Symfony\Component\HttpFoundation\RedirectResponse; function my_redirect() { return new RedirectResponse(\Drupal::url('user.page')); }

Here is how you would use a Drupal 8 controller to accomplish the same thing:

use Drupal\Core\Controller\ControllerBase; class MyControllerClass extends ControllerBase { public function foo() { //... return $this->redirect('user.page'); } } Links on the Fly

Drupal 7 and prior relied heavily on the l() function. (In fact, I would wager this was my most used function over the years. In Drupal 8, if you need to create links on the fly, utilize the Link class

$link = \Drupal\Core\Link::fromTextAndUrl($text, $url); Working with Entities Query Database for Entities

If you need to query the database for some nodes (or any other entity) you should use the entityQuery service. The syntax should be pretty familiar to most D7 developers who have used EntityFieldQuery:

// Query for some entities with the entity query service. $query = \Drupal::entityQuery('node') ->condition('status', 1) ->condition('type', 'article') ->range(0, 10) ->sort('created', 'DESC'); $nids = $query->execute(); Loading Entities

If you need to load the actual entities, you can do so a number of ways:

While the following will technically work in Drupal 8:

$node = entity_load_multiple('node', $nids);

This method has been deprecated in Drupal 8 and will be removed before Drupal 9, in favor of methods overriding Entity::loadMultiple(). To future-proof your code, you would do something like the following:

$nodes = \Drupal::entityTypeManager()->getStorage('node')->loadMultiple($nids);

Here's how you would do similar for a single node:

$node = \Drupal::entityTypeManager()->getStorage('node')->load($nid);

Here are a few other entity snippets that might be useful:

// Link to an entity using the entity's link method. $author_link = $user->toLink(); // Do the same thing, but customize the link text. $author_link = $user->toLink('Some Custom Text'); // Given a node object, here's how to determine its type: $type = $node->getType(); // To get the full user entity of the node's author: $author = $node->getOwner(); // To get the raw ID of the author of a node: $author_id = $node->getOwnerId(); Image Styles

Need to whip up an image using a particular image style on the fly? This will work for that:

// Create an instance of an image using a specific image style, given a path to a file. $style = \Drupal\image\Entity\ImageStyle::load('yourStyle_image'); $img_path = $user->field_profile_some_image->entity->getFileUri(); $img_style_url = $style->buildUrl($img_path);

That's it for now. I intend to keep this post updated as we learn more and more about the new world of Drupal 8. If you have a snippet worth sharing, drop us a line via Twitter and we’ll add it to this post (with credit of course).

Categories: Drupal

Chromatic: Be Promiscuous with Drush's core-quick-drupal

Planet Drupal - 8 July 2016 - 10:36am
Aren't you a cutie?

Here at Chromatic HQ, the team is encouraged to give back to the open-source community. (And on company time!) One way to do this is by reviewing and contributing Drupal patches. For me, this can be both rewarding and frustrating. When things go well, I feel good about contributing and I might even get a commit credit! But there are times when patches don't apply, I have no clue what's wrong and I need to start fresh. First, I curse mightily at the time wasted, then I create a new db, and then re-install a fresh copy of Drupal, and then configure it etc. etc. Using drush site-install makes this process relatively easy, but what if it could be easier? (Hint: It is!)

Hooray for promiscuity!

I recently had a fling with Drush's core-quick-drupal command. I had known about it for years, but I hadn't realized what it could really do for me. This has now changed, and together we're having an open affair!

For the uninitiated, drush core-quick-drupal takes advantage of PHP's built-in web server (PHP >= 5.4) and uses a sqlite database to get a fresh, stand-alone copy of Drupal up and running, all in about a minute. It has two aliases: drush qd and, my personal preference, drush cutie.

Out-of-the-box overview
  • In about a minute it installs a full instance of Drupal.
  • Runs a web server at http://127.0.0.1:8888 (no apache config).
  • Uses a self-contained sqlite file as the db (no mysql db to create and configure).

It's so much fun, you may want to follow along. From the command line, just cd to a folder of your choosing and run drush cutie --yes. (You'll need to have drush installed.)

Behind the scenes, a folder is created called quick-drupal with a timestamp appended to the end. (One of my older cutie folders is quick-drupal-20160214193640... a timestamp from a Valentine's evening with Drush that my wife won't soon forget!) Inside the new quick-drupal folder are subfolders with the latest D8 files and the sqlite db file. (There are lots of options to customize the Drupal version and environment, but the default nowadays is Drupal 8.)

Running it looks something like this drush cutie --yes Project drupal (8.0.3) downloaded to ... Installation complete. User name: admin User password: EawsYkGg4Y Congratulations, you installed Drupal! Listening on http://127.0.0.1:8888

(The output above has been edited to highlight the tastier bits!)

And with that I have the latest version of D8 running at http://127.0.0.1:8888. As you can see from the shell output above, the superuser is admin with a password of EawsYkGg4Y.

Okay, okay, very cool, but what can I do with it? Here's a breakdown:
  1. Review patches with minimal fuss, thereby giving back to the Drupal community.
  2. Investigate new modules without sullying your main dev environment.
  3. Test that new Feature you created to see if it really works.
  4. NOT RECOMMENDED! When that friend asks you how long it will take to build him a website, respond with "about a minute" and fire it up.
You thought I was done?

Let's run through the steps to review a patch. This is where drush core-quick-drupal really shines because it's best to have a clean install of Drupal to work with; this minimizes the number of externalities that can interfere with testing. Having a single-command, throwaway copy of vanilla Drupal is the way to go.

You could call this a blog version of a live demo; I have chosen a patch out in the wild to review. I found this one for the core taxonomy module, that had a status of "Needs Review" on D.O.

The patch file itself is here: https://www.drupal.org/files/issues/taxonomy-term-twig-cs.patch

Here are the steps I took on the command line:

# Install a temporary copy of D8 into a folder I named "test2644718" drush cutie test2644718 --yes

With the above command I got my environment running. The patch itself simply fixes the formatting in taxonomy-term.html.twig, which is a default template file for taxonomy terms, provided by the core taxonomy module.

I first tested to see the original template in action. Satisfied with the way it was working, I took steps to apply the patch.

# Move into the root folder of the new site cd test2644718/drupal/ # Use wget to grab the patch from D.O. wget https://www.drupal.org/files/issues/taxonomy-term-twig-cs.patch # Apply the patch patch -p1 < taxonomy-term-twig-cs.patch patching file core/modules/taxonomy/templates/taxonomy-term.html.twig

The patch was applied successfully and a minor change in taxonomy-term.html.twig was made. I quickly tested to ensure nothing had blown up and was satisfied that the patch works as expected.

Back in D.O., I added my two cents and marked the issue as Reviewed & tested by the community. And that's that.

Update

Though the patch originally sat awaiting review for 2 months, I'm happy to claim that my review got things moving again! After I posted RTBC, a flurry of activity took place with the scope increasing and new patches being created. I reviewed those too! A day later the patches were committed to 8.1.x. Nice.

Categories: Drupal

Mediacurrent: Friday 5: 5 Quick Ways to Check Your Site&#039;s Health

Planet Drupal - 8 July 2016 - 9:39am

TGIF and welcome back to another exciting episode of The Mediacurrent Friday 5!

Categories: Drupal

Jeff Geerling's Blog: Getting Emoji and multibyte characters on your Drupal 7 site with 7.50

Planet Drupal - 8 July 2016 - 8:43am

Almost exactly a year ago, I wrote a blog post titled Solving the Emoji/character encoding problem in Drupal 7.

Since writing that post, Drupal 7 bugfixes and improvements have started to pick up steam as (a) many members of the community who were focused on launching Drupal 8 had time to take a breather and fix up some long-standing Drupal 7 bugs and improvements that hadn't yet been backported, and (b) there are two new D7 core maintainers. One of the patches I've been applying to many sites and hoping would get pulled into core for a long time was adding support for full UTF-8, which allows the entry of emojis, Asian symbols, and mathematical symbols that would break Drupal 7 sites running on MySQL previously.

My old blog post had a few steps that you could follow to make your Drupal 7 site 'mostly' support UTF-8, but there were some rough edges. Now that support is in core, the process for converting your existing site's database is more straightforward:

Categories: Drupal

Zivtech: How to Grow Your Own Team

Planet Drupal - 8 July 2016 - 6:00am
Lack of available talent is a common refrain of business owners. Give up on looking and complaining! Learn how to create a sustainable business.

Growing your own means hiring smart, motivated people with all the right soft skills and investing in them for the long haul. In return, they'll reward you with loyalty, teach your newer staff, and work in unison with a cohesive vision.

Where is the Talent? It’s not realistic to imagine that you live in a world where there are people that you can just hire for a decent price who already have all the skills you need. Just come in, hit the ground running, and make you a bunch of money. You wouldn't have any problems with them, and you wouldn't have to do much for them other than feed them some pizza and pay them.

So when managers can't find those people, they get upset, and they say, "There's not enough talent. People are not getting educated properly. We don't have the right people and the right programs out there."

The world is full of talent! No, they haven't learned the specific skills that you need, but there are so many intelligent people out there who would thrive with a little help.


What Are You Farming? When I started working in software development, I saw myself as someone who made websites. That was my output: I was making websites, or I was making code. Over the years now I see that my product is people. I'm selling their time, expertise, knowledge, and human capacity.

In web development, who cares about the code when you have the coder? It's like the egg and the chicken. You have to take care of the chicken, and not each little egg, because the chickens just keep making more.

Being a great website maker isn’t really that valuable. What is really valuable is being able to grow more people who can do the work. Then you really scale up. You're only going to do so well as a solo practitioner. If you're able to grow more and more skilled people, not only is your business doing better, but you start to realize that the task of training people is more important than building websites.


Download the full Grow Your Own white paper for free.
Categories: Drupal

OSTraining: How to Display PDFs on a Drupal Site

Planet Drupal - 8 July 2016 - 5:10am

An OSTraining member asked us about attaching PDFs to a Drupal site.

It is possible to use the default File field and allow people to download the PDF. However, this member wanted visitors to read the PDF directly on the site.

Categories: Drupal

Drop Guard: Why we don’t (continuously) update our Drupal websites

Planet Drupal - 8 July 2016 - 4:00am

 

Two weeks ago we decided to run a little survey asking Drupal folks one simple, but provocative question “Why I don’t update my website continuously”. I decided to present you the results - and I can tell that some serious voices got out!

First, I want to speak highly of least 38 of 78 participants, who actually update their website continuously and seem to know exactly what happens if they wouldn’t do it.

Drupal Drupal Planet Security Survey
Categories: Drupal

Leopathu: 6 Essential Drupal Interview Questions*

Planet Drupal - 8 July 2016 - 3:06am
1. Name and describe the five conceptual layers in a Drupal system.
Categories: Drupal

LevelTen Interactive: How to Market a Speaking Tour: Behind the Scenes of the R.O.W. Roadshow

Planet Drupal - 7 July 2016 - 10:00pm

Hey, let’s put on a show!

My colleague Felipa and I felt like we were in a Judy Garland-Mickey Rooney movie. “Let’s put on a show!” said Tom, the CEO here at LevelTen, and we all jumped in to clear out the barn and save the orphanage....Read more

Categories: Drupal

Yuriy Gerasimov: Automated deployments to Acquia. Cloud API

Planet Drupal - 7 July 2016 - 9:45pm

When you set up your Continuous Integration you really would like to set your deployments automatically. If you use Acquia hosting for your website it does make a lot of sense to use all environments in your workflow. But how you can automate deployments to these environments without touching UI (copying database, files, deploying code)?

The answer is in Cloud API


You can call them either with drush command or curl request. We will touch the drush commands approach in this post.

I personally was heavily involved in workflow called CIBox that uses separate from Acquia github repo.

I used 'master' branch to deploy to DEV environment. But both STAGING and PRODUCTION environments are tag based.

DEV environment deployment


First step of deployment for me was to sync the repositories.

cd /var/git/acquia git pull github master git push origin master # Sleep for 30 seconds. We expect Acquia to update the code. sleep 30

Little note: all these commands are run on CI server for me. So you will find plenty of ssh and scp to Acquia servers later.

Repository /var/git/acquia is a clone from hosting repo but with set up remote to our own private repo. If you use hosting repo as primary you probably won't need this step.

In Acquia UI I have set up DEV environment to follow master branch. So code gets deployed automatically.

In my CI set up, I keep copy of project's database on CI server to use it in all builds. So I deploy this db to DEV environment as next step. Workflow diagram looks like this.

Code snippet

# Copy db to DEV server scp /var/www/backup/DBNAME.sql.gz PROJECT.dev@staging-XXXX.prod.hosting.acquia.com:/home/PROJECT/proddump.sql.gz # Deploy db on DEV server ssh -t PROJECT.dev@staging-XXXX.prod.hosting.acquia.com 'rm -rf /home/PROJECT/DBNAME.sql && gunzip /home/PROJECT/proddump.sql.gz && cd /var/www/html/PROJECT.dev/docroot && drush sql-drop -y && `drush sql-connect` < /home/PROJECT/proddump.sql'

Remember in order to run this operation you need to set up your ssh keys so jenkins user (I use Jenkins as CI tool) can go to Acquia servers without password being requested.

And the last step is run all the updates, registry rebuilds and whatever your project requires.

# Run registry rebuild and clear caches ssh -t PROJECT.dev@staging-XXXX.prod.hosting.acquia.com 'cd /var/www/html/PROJECT.dev/docroot && drush php-eval "registry_rebuild();" && drush cc all -y'   # Run hook updates ssh -t PROJECT.dev@staging-XXXX.prod.hosting.acquia.com 'cd /var/www/html/PROJECT.dev/docroot && drush -y updb'

These commands actually can be set up with drush aliases. But I used terminal approach as already using it for deploying database. Just consistency reasons.

Another part I skip here is copying files over. We don't do that. Instead we enable stage_file_proxy on DEV and STAGE environments and point them to PROD so files got copied over upon request. This saves plenty of space.

STAGE environment deployment


As staging environment uses tags we need to change our code deployment part.

In order to use Cloud API you need to set up special private key in Acquia UI. Please review https://docs.acquia.com/cloud/api/auth for more details.

After setting up the key, ssh to DEV server and run command 'drush ac-api-login' and provide your email and key to it. In this way you will set up all your credentials and be able to run Cloud API drush commands.

And now, we can deploy the code.

ssh -t PROJECT.dev@staging-XXXX.prod.hosting.acquia.com 'cd /var/www/html/PROJECT.dev/docroot && drush @PROJECT.dev ac-code-deploy test --verbose'   # Sleep for 30 seconds. We expect Acquia to update the code. sleep 30

This will deploy the code from DEV environment to STAGE and adds the tag automatically. Basically it mimics the operation of dragging the code bar in Acquia UI.

All other steps (database deployment and cache clear) are the same as with DEV environment.

PROD environment deployments


Production deployment is going to be the same as STAGE with only difference we need to ssh to STAGE server to deploy the code. And of course we do not to deploy database anywhere.

I am sure in your projects you might need to add some more steps. Maybe reindexing solr, or clearing varnish caches. All these can be done with drush commands.

How do you do deployments? Please share your experience in comments.

Tags: drupal 7drupal planet
Categories: Drupal

Appnovation Technologies: Drupal 8 and the User Experience Upgrade

Planet Drupal - 7 July 2016 - 5:27pm

Drupal and user experience can sometimes be at odds.

Categories: Drupal

Drupal Blog: Drupal 7.50 released

Planet Drupal - 7 July 2016 - 11:28am

Drupal 7.50, the next release in the Drupal 7 series, is now available for download. It contains a variety of new features, improvements, and bug fixes (no security fixes).

Wait... Drupal 7.50?

Yes, there is a version jump compared to the previous 7.44 release; this is to indicate that this Drupal 7 point release is a bit larger than past ones and makes a few more changes and new features available than normal.

Updating your existing Drupal 7 sites is recommended. Backwards compatibility is still being maintained, although read on to find out about a couple of changes that might need your attention during the update.

Download Drupal 7.50 Notable changes

There are a variety of new features, performance improvements, security-related enhancements (although no fixes for direct security vulnerabilities) and other notable changes in this release. The release notes provide a comprehensive list, but here are some highlights.

New "administer fields" permission added for trusted users

The administrative interface for adding and configuring fields has always been something that only trusted users should have access to. To make that easier, there is now a dedicated permission which is required (in addition to other existing administrative permissions) to be able to access the field UI.

For example, you can now assign the "administer taxonomy" permission (but withhold the new "administer fields" permission) to allow low-level administrators to manage taxonomy terms but not change the field structure. Read the change record for more information.

Protection against clickjacking enabled by default

Clickjacking is a technique a malicious site owner can use to attempt attacks on other sites, by embedding the victim's site into an iframe on their own site.

To stop this, Drupal will now prevent your site from being embedded in an iframe on another domain. This is the default behavior, but it can be adjusted if necessary; see the change record to find out more.

Support for full UTF-8 (emojis, Asian symbols, mathematical symbols) is now possible on MySQL

If content creators on your site have been clamoring to use emojis, it's now possible on Drupal sites running MySQL (it was previously possible on PostgreSQL and SQLite). Turning this capability on requires the database to meet certain requirements, plus editing the site's settings.php file and potentially other steps, as described in the change record.

Improved support for recent PHP versions, including PHP 7

Drupal core's automated test suite is now fully passing on a variety of environments where there were previously some failures (PHP 5.4, 5.5, 5.6, and 7). We have also fixed several bugs affecting those versions. These PHP versions are officially supported by Drupal 7 and recommended for use where possible.

Because PHP 7 is the newest release (and not yet used on many production sites) extra care should still be taken with it, and there are some known bugs, especially in contributed modules (see the discussion for more details). However anecdotal evidence from a variety of users suggests that Drupal 7 can be successfully used on PHP 7, both before and after the 7.50 release.

Improved performance (and new PHP warnings) when Drupal is trying to find a file that does not exist

When Drupal cannot find a file that it expects to be in the filesystem, it will no longer continually search for it on a large number of page requests (previously, this could significantly hurt your site's performance). Instead, it will record a PHP warning about the problem.

Read the change record for more information, and make sure your production site is not configured to show warning messages like this on the screen, since it is not desirable for site visitors to see them. (In order to configure this, go to "Administration" → "Configuration" → "Development" → "Logging and errors" and set the "Error messages to display" option to "None".)

Improvements to help search engines index your site's images/CSS/JavaScript

Modern search engine web crawlers read images, CSS and JavaScript (just like a regular web browser) when crawling a site, and they use this information to improve search results.

Drupal's default robots.txt file now includes rules to allow search engines to access more of these files than it previously allowed them to, which may help certain search engines better index your site. See the change record for additional details.

More information
  • You can find the full list of changes between the previous 7.44 release and the current 7.50 release by reading the 7.50 release notes.
  • Also see the release notes for additional update information and known issues discovered after the release.
  • You can find a complete list of all changes in the stable 7.x branch in the git commit log.
  • Translators should be aware of a few administrative-facing translatable string changes and additions in this release.
Security information Future releases
  • Drupal 7 is being actively maintained, so more maintenance releases will be made available, according to our monthly release cycle.
  • We will consider continuing to do larger Drupal 7 releases like this one every six months or so (where the next larger release will be 7.60, in keeping with Drupal's new release cycle) if there is interest and continued contributions from the community. See the ongoing discussion for further details.
New Drupal 7 co-mainainers

In case you missed the news earlier, we recently added two new Drupal 7 co-maintainers: Fabianx (@fabianfranz) and stefan.r (@stefan_arrr)! Despite only having been official maintainers for the past two weeks, they put in an enormous amount of effort and skill into Drupal 7.50, which was essential in getting it out the door with all the improvements mentioned above.

Credits

Overall, 230 people were credited with helping to fix issues included in this release:

akoepke, alanburke, Alan D., alberto56, Albert Volkman, alexmoreno, alexpott, amontero, andypost, ar-jan, arosboro, askibinski, attiks, basvredeling, beejeebus, benjy, Berdir, bmateus, borisson_, botris, bradjones1, brianV, broeker, c960657, Carsten Müller, catch, checker, chintan.vyas, chirhotec, Christian DeLoach, ChristophWeber, chx, cilefen, ciss, ckng, colinmccabe, corbacho, criz, cspitzlay, cwoky, dagmar, DamienMcKenna, damien_vancouver, darol100, Darren Oh, das-peter, Dave Reid, davic, david_garcia, David_Rothstein, dawehner, dcam, DerekL, donutdan4114, droplet, DuaelFr, e._s, eesquibel, eiriksm, Elijah Lynn, emcniece, Eric_A, EvanSchisler, ExTexan, Fabianx, felribeiro, fgm, fietserwin, forestgardener, gcardinal, geerlingguy, gielfeldt, Girish-jerk, greggles, GrigoriuNicolae, Gábor Hojtsy, hass, Henrik Opel, heyyo, hgoto, hussainweb, idebr, ifrik, imanol.eguskiza, IRuslan, izaaksom, jackbravo, jacob.embree, jbekker, jbeuckm, jduhls, jenlampton, jeroen.b, jhodgdon, jibran, joachim, joegraduate, joelpittet, johnpicozzi, joseph.olstad, joshtaylor, Josh Waihi, jp.stacey, jsacksick, jthorson, JvE, jweowu, kala4ek, Kars-T, Ken Ficara, kenorb, kevinquillen, Kgaut, KhaledBlah, klausi, klokie, kristiaanvandeneynde, kristofferwiklund, ksenzee, k_zoltan, leschekfm, Liam Morland, lOggOl, lokapujya, Lowell, lucastockmann, Lukas von Blarer, maciej.zgadzaj, marcelovani, mariagwyn, Mark Theunissen, marvin_B8, maximpodorov, mayaz17, MegaChriz, mfb, mgifford, micaelamenara, mikeytown2, Mile23, mimran, minax.de, miro_dietiker, mistermoper, Mixologic, mohit_aghera, mondrake, mpv, mr.baileys, MustangGB, Neograph734, nevergone, nicholas.alipaz, nicrodgers, NikitaJain, nithinkolekar, nod_, Noe_, onelittleant, opdavies, orbmantell, oriol_e9g, ParisLiakos, pashupathi nath gajawada, Peacog, Perignon, Peter Bex, peterpoe, pfrenssen, PieterDC, pietmarcus, pjcdawkins, pjonckiere, Polonium, pounard, presleyd, pwaterz, pwolanin, rafaolf, rbmboogie, realityloop, rhclayto, rocketeerbkw, rpayanm, rupertj, Sagar Ramgade, sanduhrs, scor, scottalan, scuba_fly, sdstyles, snehi, soaratul, SocialNicheGuru, Spleshka, stefan.r, stovak, sun, Sutharsan, svanou, Sweetchuck, swentel, sylus, s_leu, tadityar, talhaparacha, tatisilva, tbradbury, therealssj, travelvc, TravisCarden, TravisJohnston, treyhunner, tsphethean, tstoeckler, tucho, tuutti, twistor, TwoD, typhonius, vasi1186, Wim Leers, Xano, xjm, yannickoo, yched, YesCT, zaporylie, Zerdiox, and znerol.

(This list was auto-generated, so apologies if anyone was left out.)

Your name could be on a list like this in the future; see the Ways to get involved page to find out how.

Thank you to everyone who helped with Drupal 7.50!

Categories: Drupal

Administration links access filter

New Drupal Modules - 7 July 2016 - 7:58am

Administration links access filter provides a workaround for the common problem that users with 'Use the administration pages and help' permission see menu links they don't have access permission for.

Categories: Drupal

Drupal Blog: A roadmap for making Drupal more API-first

Planet Drupal - 7 July 2016 - 7:06am

Republished from buytaert.net

In one of my recent blog posts, I articulated a vision for the future of Drupal's web services, and at DrupalCon New Orleans, I announced the API-first initiative for Drupal 8. I believe that there is considerable momentum behind driving the web services initiative. As such, I want to provide a progress report, highlight some of the key people driving the work, and map the proposed vision from the previous blog post onto a rough timeline.

Here is a bird's-eye view of the plan for the next twelve months:

8.2 (Q4 2016) 8.3 (Q2 2017) Beyond 8.3 (2017+) New REST API capabilities
Waterwheel initial release New REST API capabilities
JSON API module GraphQL module?
Entity graph iterator? New REST API capabilities

Wim Leers (Acquia) and Daniel Wehner (Chapter Three) have produced a comprehensive list of the top priorities for the REST module. We're introducing significant REST API advancements in Drupal 8.2 and 8.3 in order to improve the developer experience and extend the capabilities of the REST API. We've been focused on configuration entity support, simplified REST configuration, translation and file upload support, pagination, and last but not least, support for user login, logout and registration. All this work starts to address differences between core's REST module and various contributed modules like Services and RELAXed Web Services. More details are available in my previous blog post.

Many thanks to Wim Leers (Acquia), Daniel Wehner (Chapter Three), Ted Bowman (Acquia),Alex Pott (Chapter Three), and others for their work on Drupal core's REST modules. Though there is considerable momentum behind efforts in core, we could always benefit from new contributors. Please consider taking a look at the REST module issue queue to help!

Waterwheel initial release

As I mentioned in my previous post, there has been exciting work surrounding Waterwheel, an SDK for JavaScript developers building Drupal-backed applications. If you want to build decoupled applications using a JavaScript framework (e.g. Angular, Ember, React, etc.) that use Drupal as a content repository, stay tuned for Waterwheel's initial release later this year.

Waterwheel aims to facilitate the construction of JavaScript applications that communicate with Drupal. Waterwheel's JavaScript library allows JavaScript developers to work with Drupal without needing deep knowledge of how requests should be authenticated against Drupal, what request headers should be included, and how responses are molded into particular data structures.

The Waterwheel Drupal module adds a new endpoint to Drupal's REST API allowing Waterwheel to discover entity resources and their fields. In other words, Waterwheel intelligently discovers and seamlessly integrates with the content model defined on any particular Drupal 8 site.

A wider ecosystem around Waterwheel is starting to grow as well. Gabe Sullice, creator of the Entity Query API module, has contributed an integration of Waterwheel which opens the door to features such as sorts, conditions and ranges. The Waterwheel team welcomes early adopters as well as those working on other REST modules such as JSON API and RELAXed or using native HTTP clients in JavaScript frameworks to add their own integrations to the mix.

Waterwheel is the currently the work of Matt Grill (Acquia) and Preston So (Acquia), who are developing the JavaScript library, and Ted Bowman (Acquia), who is working on the Drupal module.

JSON API module

In conjunction with the ongoing efforts in core REST, parallel work is under way to build a JSON API module that embraces the JSON API specification. JSON API is a particular implementation of REST that provides conventions for resource relationships, collections, filters, pagination, and sorting, in addition to error handling and full test coverage. These conventions help developers build clients faster and encourages reuse of code.

Thanks to Mateu Aguiló BoschEd Faulkner and Gabe Sullice, who are spearheading the JSON API module work. The module could be ready for production use by the end of this year and included as an experimental module in core by 8.3. Contributors to JSON API are meeting weekly to discuss progress moving forward.

Beyond 8.3: GraphQL and entity graph iterator

While these other milestones are either certain or in the works, there are other projects gathering steam. Chief among these is GraphQL, which is a query language I highlighted in my Barcelona keynote and allows for clients to tailor the responses they receive based on the structure of the requests they issue.

One of the primary outcomes of the New Orleans web services discussion was the importance of a unified approach to iterating Drupal's entity graph; both GraphQL and JSON API require such an "entity graph iterator." Though much of this is still speculative and needs greater refinement, eventually, such an "entity graph iterator" could enable other functionality such as editable API responses (e.g. aliases for custom field names and timestamp formatters) and a unified versioning strategy for web services. However, more help is needed to keep making progress, and in absence of additional contributors, we do not believe this will land in Drupal until after 8.3.

Thanks to Sebastian Siemssen, who has been leading the effort around this work, which is currently available on GitHub.

Validating our work and getting involved

In order to validate all of the progress we've made, we need developers everywhere to test and experiment with what we're producing. This means stretching the limits of our core REST offerings, trying out JSON API for your own Drupal-backed applications, reporting issues and bugs as you encounter them, and participating in the discussions surrounding this exciting vision. Together, we can build towards a first-class API-first Drupal.

Special thanks to Preston So for contributions to this blog post and to Wim Leers for feedback during its writing.

Categories: Drupal

A roadmap for making Drupal more API-first

Dries Buytaert - 7 July 2016 - 7:06am

In one of my recent blog posts, I articulated a vision for the future of Drupal's web services, and at DrupalCon New Orleans, I announced the API-first initiative for Drupal 8. I believe that there is considerable momentum behind driving the web services initiative. As such, I want to provide a progress report, highlight some of the key people driving the work, and map the proposed vision from the previous blog post onto a rough timeline.

Here is a bird's-eye view of the plan for the next twelve months:

8.2 (Q4 2016) 8.3 (Q2 2017) Beyond 8.3 (2017+) New REST API capabilities
Waterwheel initial release New REST API capabilities
JSON API module GraphQL module?
Entity graph iterator? New REST API capabilities

Wim Leers (Acquia) and Daniel Wehner have produced a comprehensive list of the top priorities for the REST module. We're introducing significant REST API advancements in Drupal 8.2 and 8.3 in order to improve the developer experience and extend the capabilities of the REST API. We've been focused on configuration entity support, simplified REST configuration, translation and file upload support, pagination, and last but not least, support for user login, logout and registration. All this work starts to address differences between core's REST module and various contributed modules like Services and RELAXed Web Services. More details are available in my previous blog post.

Many thanks to Wim Leers (Acquia), Daniel Wehner, Ted Bowman (Acquia), Alex Pott (Chapter Three), and others for their work on Drupal core's REST modules. Though there is considerable momentum behind efforts in core, we could always benefit from new contributors. Please consider taking a look at the REST module issue queue to help!

Waterwheel initial release

As I mentioned in my previous post, there has been exciting work surrounding Waterwheel, an SDK for JavaScript developers building Drupal-backed applications. If you want to build decoupled applications using a JavaScript framework (e.g. Angular, Ember, React, etc.) that use Drupal as a content repository, stay tuned for Waterwheel's initial release later this year.

Waterwheel aims to facilitate the construction of JavaScript applications that communicate with Drupal. Waterwheel's JavaScript library allows JavaScript developers to work with Drupal without needing deep knowledge of how requests should be authenticated against Drupal, what request headers should be included, and how responses are molded into particular data structures.

The Waterwheel Drupal module adds a new endpoint to Drupal's REST API allowing Waterwheel to discover entity resources and their fields. In other words, Waterwheel intelligently discovers and seamlessly integrates with the content model defined on any particular Drupal 8 site.

A wider ecosystem around Waterwheel is starting to grow as well. Gabe Sullice, creator of the Entity Query API module, has contributed an integration of Waterwheel which opens the door to features such as sorts, conditions and ranges. The Waterwheel team welcomes early adopters as well as those working on other REST modules such as JSON API and RELAXed or using native HTTP clients in JavaScript frameworks to add their own integrations to the mix.

Waterwheel is the currently the work of Matt Grill (Acquia) and Preston So (Acquia), who are developing the JavaScript library, and Ted Bowman (Acquia), who is working on the Drupal module.

JSON API module

In conjunction with the ongoing efforts in core REST, parallel work is underway to build a JSON API module which embraces the JSON API specification. JSON API is a particular implementation of REST that provides conventions for resource relationships, collections, filters, pagination, and sorting, in addition to error handling and full test coverage. These conventions help developers build clients faster and encourages reuse of code.

Thanks to Mateu Aguiló Bosch, Ed Faulkner and Gabe Sullice, who are spearheading the JSON API module work. The module could be ready for production use by the end of this year and included as an experimental module in core by 8.3. Contributors to JSON API are meeting weekly to discuss progress moving forward.

Beyond 8.3: GraphQL and entity graph iterator

While these other milestones are either certain or in the works, there are other projects gathering steam. Chief among these is GraphQL, which is a query language I highlighted in my Barcelona keynote and allows for clients to tailor the responses they receive based on the structure of the requests they issue.

One of the primary outcomes of the New Orleans web services discussion was the importance of a unified approach to iterating Drupal's entity graph; both GraphQL and JSON API require such an "entity graph iterator". Though much of this is still speculative and needs greater refinement, eventually, such an "entity graph iterator" could enable other functionality such as editable API responses (e.g. aliases for custom field names and timestamp formatters) and a unified versioning strategy for web services. However, more help is needed to keep making progress, and in absence of additional contributors, we do not believe this will land in Drupal until after 8.3.

Thanks to Sebastian Siemssen, who has been leading the effort around this work, which is currently available on GitHub.

Validating our work and getting involved

In order to validate all of the progress we've made, we need developers everywhere to test and experiment with what we're producing. This means stretching the limits of our core REST offerings, trying out JSON API for your own Drupal-backed applications, reporting issues and bugs as you encounter them, and participating in the discussions surrounding this exciting vision. Together, we can build towards a first-class API-first Drupal.

Special thanks to Preston So for contributions to this blog post and to Wim Leers for feedback during its writing.

Categories: Drupal

Dries Buytaert: A roadmap for making Drupal more API-first

Planet Drupal - 7 July 2016 - 7:06am

In one of my recent blog posts, I articulated a vision for the future of Drupal's web services, and at DrupalCon New Orleans, I announced the API-first initiative for Drupal 8. I believe that there is considerable momentum behind driving the web services initiative. As such, I want to provide a progress report, highlight some of the key people driving the work, and map the proposed vision from the previous blog post onto a rough timeline.

Here is a bird's-eye view of the plan for the next twelve months:

8.2 (Q4 2016) 8.3 (Q2 2017) Beyond 8.3 (2017+) New REST API capabilities
Waterwheel initial release New REST API capabilities
JSON API module GraphQL module?
Entity graph iterator? New REST API capabilities

Wim Leers (Acquia) and Daniel Wehner have produced a comprehensive list of the top priorities for the REST module. We're introducing significant REST API advancements in Drupal 8.2 and 8.3 in order to improve the developer experience and extend the capabilities of the REST API. We've been focused on configuration entity support, simplified REST configuration, translation and file upload support, pagination, and last but not least, support for user login, logout and registration. All this work starts to address differences between core's REST module and various contributed modules like Services and RELAXed Web Services. More details are available in my previous blog post.

Many thanks to Wim Leers (Acquia), Daniel Wehner, Ted Bowman (Acquia), Alex Pott (Chapter Three), and others for their work on Drupal core's REST modules. Though there is considerable momentum behind efforts in core, we could always benefit from new contributors. Please consider taking a look at the REST module issue queue to help!

Waterwheel initial release

As I mentioned in my previous post, there has been exciting work surrounding Waterwheel, an SDK for JavaScript developers building Drupal-backed applications. If you want to build decoupled applications using a JavaScript framework (e.g. Angular, Ember, React, etc.) that use Drupal as a content repository, stay tuned for Waterwheel's initial release later this year.

Waterwheel aims to facilitate the construction of JavaScript applications that communicate with Drupal. Waterwheel's JavaScript library allows JavaScript developers to work with Drupal without needing deep knowledge of how requests should be authenticated against Drupal, what request headers should be included, and how responses are molded into particular data structures.

The Waterwheel Drupal module adds a new endpoint to Drupal's REST API allowing Waterwheel to discover entity resources and their fields. In other words, Waterwheel intelligently discovers and seamlessly integrates with the content model defined on any particular Drupal 8 site.

A wider ecosystem around Waterwheel is starting to grow as well. Gabe Sullice, creator of the Entity Query API module, has contributed an integration of Waterwheel which opens the door to features such as sorts, conditions and ranges. The Waterwheel team welcomes early adopters as well as those working on other REST modules such as JSON API and RELAXed or using native HTTP clients in JavaScript frameworks to add their own integrations to the mix.

Waterwheel is the currently the work of Matt Grill (Acquia) and Preston So (Acquia), who are developing the JavaScript library, and Ted Bowman (Acquia), who is working on the Drupal module.

JSON API module

In conjunction with the ongoing efforts in core REST, parallel work is underway to build a JSON API module which embraces the JSON API specification. JSON API is a particular implementation of REST that provides conventions for resource relationships, collections, filters, pagination, and sorting, in addition to error handling and full test coverage. These conventions help developers build clients faster and encourages reuse of code.

Thanks to Mateu Aguiló Bosch, Ed Faulkner and Gabe Sullice, who are spearheading the JSON API module work. The module could be ready for production use by the end of this year and included as an experimental module in core by 8.3. Contributors to JSON API are meeting weekly to discuss progress moving forward.

Beyond 8.3: GraphQL and entity graph iterator

While these other milestones are either certain or in the works, there are other projects gathering steam. Chief among these is GraphQL, which is a query language I highlighted in my Barcelona keynote and allows for clients to tailor the responses they receive based on the structure of the requests they issue.

One of the primary outcomes of the New Orleans web services discussion was the importance of a unified approach to iterating Drupal's entity graph; both GraphQL and JSON API require such an "entity graph iterator". Though much of this is still speculative and needs greater refinement, eventually, such an "entity graph iterator" could enable other functionality such as editable API responses (e.g. aliases for custom field names and timestamp formatters) and a unified versioning strategy for web services. However, more help is needed to keep making progress, and in absence of additional contributors, we do not believe this will land in Drupal until after 8.3.

Thanks to Sebastian Siemssen, who has been leading the effort around this work, which is currently available on GitHub.

Validating our work and getting involved

In order to validate all of the progress we've made, we need developers everywhere to test and experiment with what we're producing. This means stretching the limits of our core REST offerings, trying out JSON API for your own Drupal-backed applications, reporting issues and bugs as you encounter them, and participating in the discussions surrounding this exciting vision. Together, we can build towards a first-class API-first Drupal.

Special thanks to Preston So for contributions to this blog post and to Wim Leers for feedback during its writing.

Categories: Drupal

Pages

Subscribe to As If Productions aggregator - Drupal