Agrégateur de flux

OSTraining: Using Drupal Message Notifications

Planet Drupal - mer, 30/11/2016 - 13:20

An OSTraining member asked us how to setup the message notifications stack in Drupal.

In this particular case, he wanted to know how to set up the message notifications.

Once you install the required modules, you will notice a working notification example already exists, making the setup process easier. Let's start...

Catégories: Elsewhere

Liip: A fairly complex Drupal Commerce site: freitag.ch

Planet Drupal - mer, 30/11/2016 - 13:03

Our latest site with Drupal Commerce 1.x went live in July 2016. It is Freitag. Since then we’ve been adding several new commerce related features. I feel it’s time to write a wrap-up. The site has several interesting solutions, this article will focus on commerce.

First a few words about the architecture. platform.sh hosts the site. The stack is Linux + nginx +  MySQL + PHP, the CMS is Drupal 7. Fastly caches http responses for anonymous users and also for authenticated users having no additional role (that is, logged-in customers). Authcache module takes care of lazy-loading the personalized parts (like the user menu and the shopping cart). Freitag has an ERP system to which we connect using the OCI8 PHP library. We write Behat and simpletest tests for QA.

We use the highly flexible Drupal Commerce suite. 23 of the enabled Freitag contrib modules have a name starting with ‘commerce’. We applied around 45 patches on them. Most of the patches are authored by us and 15 of them have already been committed. Even with this commitment to solve everything we could in an open-source way we wrote 30.000+ lines of commerce-related custom code. The bulk part of this is related to the ERP integration. Still, in March 2016 Freitag was the 3rd largest Drupal customer contributor.

The words ‘product’ and ‘product variation’  I’ll be using throughout the article correspond to ‘product display node’ and ‘product’ in Drupal Commerce lingo.

ERP

ERP is the source of all products and product variations. We import this data into Drupal on a regular basis using Feeds. (Now I would use Migrate instead, it’s better supported and easier to maintain.) ERP also lets Drupal know about order status changes, sends the shipping tracking information and informs Drupal about products sent back to Freitag by customers.

There is data flowing in the opposite direction as well. ERP needs to know about all Drupal orders. Also, we create coupons in Drupal and send them to ERP too for accounting and other reasons.

Emails

We send commerce-related emails using the Message stack. This way we can have order-related tokens in our mails and we can manage and translate them outside the Rules UI. Mandrill takes care of the mail delivery.

Payment gateway

It was a client requirement to use the Swiss Datatrans payment gateway. However, at the time of starting  the project, Commerce Datatrans (the connector module on drupal.org) was in dev state and lacked several features we needed. Pressed for time we opted for buying a Datatrans Drupal module from a company offering this solution. It turned out to be a bad choice. When we discovered that the purchased module still does not cover all our needs and looked at the code we found that it was obfuscated and pretty much impossible to change. Also, the module could be used only on one site instance which made it impossible to use it on our staging sites.

We ended up submitting patches to the Commerce Datatrans module hosted on drupal.org. The module maintainer, Sascha Grossenbacher (the well-known Drupal 8 core contribtor) helped us solving several issues and feature requests by reviewing our patches. This process has lead to a stable release of Commerce Datatrans with a dozen of feature improvements and bugfixes.

Additional to Datatrans we use Commerce Custom Offline Payments to enable offline store purchases by store staff and bank transfer payments.

Currencies

The site works with 7 different currencies, some of them having two different prices depending on the shipping country. Prices come from ERP and we store them in a field collection field on the product. We do not use the commerce_price field on the product variation.

Tax

Freitag ships to countries all around the world. VAT calculations are performed for EU, Switzerland, UK, Japan, South Korea and Singapore. To implement this functionality our choice fell on the commerce_vat module. Adding commerce_eu_vat and commerce_ch_vat released us from having to maintain VAT rates for EU and Switzerland ourselves. For the 3 Asian countries we implemented our own hook_commerce_vat_rate_info().

We have two different VAT rates for most of the countries. This is because usually a lower VAT rate applies to books. Drupal imports the appropriate VAT rate from the ERP with the product variation data. This information is handled by price calculation rules in Drupal.

Shipping

Freitag delivers its products using several shipping providers (like UPS, Swiss Post) all around the world. Most shipping providers have many shipping rates depending on the destination country, speed and shipped quantity (weight or volume). On checkout the customer can choose from a list of shipping services. This list needs to be compatible with the order.

We used rules to implement the shipping services in Drupal based on the Commerce Flat Rate module. For this end we trained our client to set up and maintain these rules themselves. It was not easy: shipping rules are daunting even for experienced commerce developers. First we needed to set up the “Profile Address” rules components. Then we configured the “Place of Supply” components. We applied these in turn in the condition part of the shipping rules components themselves.

The weakest point of any  implementation based on Rules is the maintenance. It’s not easy to find a specific rule after you created it. Having 250 rules components for only shipping made this feeling stronger.

The shipping line item receives the VAT rate of the product with the highest VAT rate in the order.

Coupons

Freitag has 6 different coupon types. They differ in who can create them, who and where (online/offline) can redeem them, whether partial redemption is possible, whether it’s a fixed amount or percentage discount and whether Freitag accounting needs to know about them or not.

Based on these criteria we came up with a solution featuring Commerce Coupon. Coupons can be discount coupons or giftcards. Giftcard coupons can only have a fixed value. Discount based coupons can also apply a percentage discount. The main difference between them is that customers can partially redeem giftcards, while discount-based coupons are for one-time use.

To make coupons work with VAT was quite tricky. (To make things simpler we only allowed one coupon per order.) Some coupon types work as money which means that from an accounting point of view they do not actually decrease the order total (and thus the VAT) but work as a payment method. Other coupon types however do decrease the order total (and thus the VAT). At the same time Drupal handles all coupons as line items with a negative price and the Drupal order total does decrease in either case.

The solution we found was to use Commerce proportional VATAxel Rutz maintains this brilliant little module and he does this in a very helpful and responsive manner. All the module does is adding negative VAT price components to coupon line items to account for VAT decrease. It decreases the order total VAT amounts correctly even if we have several different VAT rates inside the order.

Conclusion

Although there’s always room for increasing the complexity of the commerce part of the site (let’s find some use case for recurring payments!), it’s already the most complicated commerce site I’ve worked on.  For this Drupal Commerce provided a solid foundation that is pleasant to work with. In the end, Drupal enabled us to deliver a system that tightly integrates content and commerce.

I also would like to say thanks to Bojan Živanović from Commerce Guys who provided me with valuable insights on the legal aspects of tax calculation.

Catégories: Elsewhere

SystemSeed: SystemSeed do Minsk

Planet Drupal - mer, 30/11/2016 - 11:41

If you haven’t noticed from our Twitter feed this week we’ve flown the team to Minsk in Belarus to socialise, eat, drink and be merry while maybe taking in a little culture and even some work(!)

One of the first things that we all notice when the team get together is you can’t hug someone over Skype… you can’t make the other person a cup of tea, or complain about the same weather.

While distributed teams can pick the world’s finest global talent as far as timezones and personal or client flexibility allows, meeting in person is a necessary task to undertake on a regular basis. It’s not essential that everyday is spent this way and removing the ability to choose from only your local talent, or those willing to relocate is not the most sensible choice in our modern era of collaborative tools and communication methods. We’d still much rather be distributed but greatly appreciate these times together.

We’ll continue to blog through the week and Tweet some extras as they are happening.

From all of us in our temporary Minsk HQ - have a fun and productive day and if you are sat next to a colleague give them a hug or make them a cup of tea. Not all teams can enjoy this luxury every day of their work life.

Catégories: Elsewhere

jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev

Devel - mer, 30/11/2016 - 11:22
Nov 30, 2016 jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev
  • 814966d test(jenkins): Make sure all errors are reported.
Catégories: Networks

Drupal Modules: The One Percent: Drupal Modules: The One Percent — Configuration Split (video tutorial)

Planet Drupal - mer, 30/11/2016 - 00:04
Drupal Modules: The One Percent — Configuration Split (video tutorial) NonProfit Tue, 11/29/2016 - 17:04 7

Here is where we look at Drupal modules running on less than 1% of reporting sites. Today we'll look at Configuration Split, a module which allows you to export only the D.8x configuration you want to production. More information can be found http://nuvole.org/blog/2016/nov/28/configuration-split-first-beta-release-drupal-ironcamp.

Catégories: Elsewhere

Cheeky Monkey Media: Hacking DrupalCon: A Behind the Scenes Look at the Event Design and Planning Process

Planet Drupal - mar, 29/11/2016 - 22:58
Hacking DrupalCon: A Behind the Scenes Look at the Event Design and Planning Process Spela Tue, 11/29/2016 - 21:58

Ever wonder what goes into a conference or other business event that participants will gush about (in a good way) for years? After an event of these mythical proportions, participants walk away raving about the food, the speakers, the social events, the aura, and the list goes on ...

But pulling off such an event is no easy feat. Thus, I decided to speak with Lead DrupalCon Coordinator Amanda Gonser to find out how she manages to make sure the DrupalCon event design is flawless and fits into the overall event planning process seamlessly.

(This video may cause unexpected bursts of laughter. If you cannot laugh in your current environment, please scroll down for the written version.)

Catégories: Elsewhere

Mediacurrent: Communicating Design to Clients

Planet Drupal - mar, 29/11/2016 - 22:06

What makes a good designer? Well, of course you have to be creative, understand how to solve problems in unconventional ways, and do it all within budget. But wait, there's more to it than being super creative and solving problems. You must be able to make others understand how your design vision solves their problems.

Catégories: Elsewhere

jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev

Devel - mar, 29/11/2016 - 21:14
Nov 29, 2016 jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev
  • 6bbc262 test(jenkins): Spawn the wd process.
Catégories: Networks

Lullabot: Pull Content From a Remote Drupal 8 Site Using Migrate and JSON API

Planet Drupal - mar, 29/11/2016 - 21:02

I wanted to find a way to pull data from one Drupal 8 site to another, using JSON API to expose data on one site, and Drupal’s Migrate with a JSON source on another site to consume it. Much of what I wanted to do was undocumented and confusing, but it worked well, once I figured it out. Nevertheless, it took me several days to get everything working, so I thought I’d write up an article to explain how I solved the problem. Hopefully, this will save someone a lot of time in the future.

I ended up using the JSON API module, along with the REST modules in Drupal Core on the source site. On the target site, I used Migrate from  Drupal Core 8.2.3 along with Migrate Plus and Migrate Tools.

Why JSON API?

Drupal 8 Core ships with two ways to export JSON data. You can access data from any entity by appending ?_format=json to its path, but that means you have to know the path ahead of time, and you’d be pulling in one entity at a time, which is not efficient.

You could also use Views to create a JSON endpoint, but it might be difficult to configure it to include all the required data, especially all the data from related content, like images, authors, and related nodes. And you’d have to create a View for every possible collection of data that you want to make available. To further complicate things, there's an outstanding bug using GET with Views REST endpoints.

JSON API provides another solution. It puts the power in the hands of the data consumer. You don’t need to know the path of every individual entity, just the general path for a entity type, and bundle. For example: /api/node/article. From that one path, the consumer can select exactly what they want to retrieve just by altering the URL. For example, you can sort and filter the articles, limit the fields that are returned to a subset, and bring along any or all related entities in the same query. Because of all that flexibility, that is the solution I decided to use for my example. (The Drupal community plans to add JSON API to Core in the future.)

There’s a series of short videos on YouTube that demonstrate many of the configuration options and parameters that are available in Drupal’s JSON API.

Prepare the Source Site

There is not much preparation needed for the source because of JSON API’s flexibility. My example is a simple Drupal 8 site with an article content type that has a body and field_image image field, the kind of thing core provides out of the box.

First, download and install the JSON API module. Then, create YAML configuration to “turn on” the JSON API. This could be done by creating a simple module that has YAML file(s) in /MODULE/config/optional. For instance, if you created a module called custom_jsonapi, a file that would expose node data might look like:

filename: /MODULE/config/optional/rest.resource.entity.node.yml: id: entity.node plugin_id: 'entity:node' granularity: method configuration: GET: supported_formats: - json supported_auth: - basic_auth - cookie dependency: enforced: module: - custom_jsonapi

To expose users or taxonomy terms or comments, copy the above file, and change the name and id as necessary, like this:

filename: /MODULE/config/optional/rest.resource.entity.taxonomy_term.yml: id: entity.taxonomy_term plugin_id: 'entity:taxonomy_term' granularity: method configuration: GET: supported_formats: - json supported_auth: - basic_auth - cookie dependency: enforced: module: - custom_jsonapi

That will support GET, or read-only access. If you wanted to update or post content you’d add POST or PATCH information. You could also switch out the authentication to something like OAuth, but for this article we’ll stick with the built-in basic and cookie authentication methods. If using basic authentication and the Basic Auth module isn’t already enabled, enable it.

Navigate to a URL like http://sourcesite.com/api/node/article?_format=api_json and confirm that JSON is being output at that URL.

That's it for the source.

Prepare the Target Site

The target site should be running Drupal 8.2.3 or higher. There are changes to the way file imports work that won't work in earlier versions. It should already have a matching article content type and field_image field ready to accept the articles from the other site.

Enable the core Migrate module. Download and enable the Migrate Plus and Migrate Tools modules. Make sure to get the versions that are appropriate for the current version of core. Migrate Plus had 8.0 and 8.1 branches that only work with outdated versions of core, so currently you need version 8.2 of Migrate Plus.

To make it easier, and so I don’t forget how I got this working, I created a migration example as the Import Drupal module on Github. Download this module into your module repository. Edit the YAML files in the /config/optional  directory of that module to alter the JSON source URL so it points to the domain for the source site created in the earlier step.

It is important to note that if you alter the YAML files after you first install the module, you'll have to uninstall and then reinstall the module to get Migrate to see the YAML changes.

Tweaking the Feed Using JSON API

The primary path used for our migration is (where sourcesite.com is a valid site):

http(s)://sourcesite.com/api/node/article?_format=api_json

This will display a JSON feed of all articles. The articles have related entities. The field_image field points to related images, and the uid/author field points to related users. To view the related images, we can alter the path as follows:

http(s)://sourcesite.com/api/node/article?_format=api_json&include=field_image

That will add an included array to the feed that contains all the details about each of the related images. This way we won’t have to query again to get that information, it will all be available in the original feed. I created a gist with an example of what the JSON API output at this path would look like.

To include authors as well, the path would look like the following. In JSON API you can follow the related information down through as many levels as necessary:

http(s)://sourcesite.com/api/node/article?_format=api_json&include=field_image,uid/author

Swapping out the domain in the example module may be the only change needed to the example module, and it's a good place to start. Read the JSON API module documentation to explore other changes you might want to make to that configuration to limit the fields that are returned, or sort or filter the list.

Manually test the path you end up with in your browser or with a tool like Postman to make sure you get valid JSON at that path.

Migrating From JSON

I had a lot of trouble finding any documentation about how to migrate into Drupal 8 from a JSON source. I finally found some in the Migrate Plus module. The rest I figured out from my earlier work on the original JSON Source module (now deprecated) and by trial and error. Here’s the source section of the YAML I ended up with, when migrating from another Drupal 8 site that was using JSON API.

source: plugin: url data_fetcher_plugin: http data_parser_plugin: json urls: http://sourcesite.com/api/node/article?_format=api_json ids: nid: type: integer item_selector: data/ fields: - name: nid label: 'Nid' selector: /attributes/nid - name: vid label: 'Vid' selector: /attributes/vid - name: uuid label: 'Uuid' selector: /attributes/uuid - name: title label: 'Title' selector: /attributes/title - name: created label: 'Created' selector: /attributes/created - name: changed label: 'Changed' selector: /attributes/changed - name: status label: 'Status' selector: /attributes/status - name: sticky label: 'Sticky' selector: /attributes/sticky - name: promote label: 'Promote' selector: /attributes/promote - name: default_langcode label: 'Default Langcode' selector: /attributes/default_langcode - name: path label: 'Path' selector: /attributes/path - name: body label: 'Body' selector: /attributes/body - name: uid label: 'Uid' selector: /relationships/uid - name: field_image label: 'Field image' selector: /relationships/field_image


One by one, I’ll clarify some of the critical elements in the source configuration.

File-based imports, like JSON and XML use the same pattern now. The main variation is the parser, and for JSON and XML, the parser is in the Migrate Plus module:

source: plugin: url data_fetcher_plugin: http data_parser_plugin: json

The url is the place where the JSON is being served. There could be more than one URL, but in this case there is only one. Reading through multiple URLs is still pretty much untested, but I didn’t need that:

urls: http://sourcesite.com/api/node/article?_format=api_json

We need to identify the unique id in the feed. When pulling nodes from Drupal, it’s the nid:

ids: nid: type: integer

We have to tell Migrate where in the feed to look to find the data we want to read. A tool like Postman (mentioned above) helps figure out how the data is configured. When the source is using JSON API, it’s an array with a key of data:

item_selector: data/

We also need to tell Migrate what the fields are. In the JSON API, they are nested below the main item selector, so they are prefixed using an xpath pattern to find them. The following configuration lets us refer to them later by a simple name instead of the full path to the field. I think the label would only come into play if you were using a UI:

fields: - name: nid label: 'Nid' selector: /attributes/nid Setting up the Image Migration Process

For the simple example in the Github module we’ll just try to import nodes with their images. We’ll set the author to an existing author and ignore taxonomy. We’ll do this by creating two migrations against the JSON API endpoint, first one to pick up the related images, and then a second one to pick up the nodes.

Most fields in the image migration just need the same values they’re pulling in from the remote file, since they already have valid Drupal 8 values, but the uri value has a local URL that needs to be adjusted to point to the full path to the file source so the file can be downloaded or copied into the new Drupal site.

Recommendations for how best to migrate images have changed over time as Drupal 8 has matured. As of Drupal 8.2.3 there are two basic ways to process images, one for local images and a different one for remote images.  The process steps are different than in earlier examples I found. There is not a lot of documentation about this. I finally found a Drupal.org thread where the file import changes were added to Drupal core and did some trial and error on my migration to get it working.  

For remote images:

source: ... constants: source_base_path: 'http://sourcesite.com/' process: filename: filename filemime: filemime status: status created: timestamp changed: timestamp uid: uid uuid: id source_full_path: plugin: concat delimiter: / source: - 'constants/source_base_path' - url uri: plugin: download source: - '@source_full_path' - uri guzzle_options: base_uri: 'constants/source_base_path'

For local images change it slightly:

source: ... constants: source_base_path: 'http://sourcesite.com/' process: filename: filename filemime: filemime status: status created: timestamp changed: timestamp uid: uid uuid: id source_full_path: plugin: concat delimiter: / source: - 'constants/source_base_path' - url uri: plugin: file_copy source: - '@source_full_path' - uri

The above configuration works because the Drupal 8 source uri value is already in the Drupal 8 format, http://public:image.jpg. If migrating from a pre-Drupal 7 or non-Drupal source, that uri won’t exist in the source. In that case you would need to adjust the process for the uri value to something more like this:

source: constants: is_public: true ... process: ... source_full_path: - plugin: concat delimiter: / source: - 'constants/source_base_path' - url - plugin: urlencode destination_full_path: plugin: file_uri source: - url - file_directory_path - temp_directory_path - 'constants/is_public' uri: plugin: file_copy source: - '@source_full_path' - '@destination_full_path' Run the Migration

Once you have the right information in the YAML files, enable the module. On the command line, type this:

drush migrate-status

You should see two migrations available to run.  The YAML files include migration dependencies and that will force them to run in the right order. To run them, type:

drush mi --all

The first migration is import_drupal_images. This has to be run before import_drupal_articles, because field_image on each article is a reference to an image file. This image migration uses the path that includes the related image details, and just ignores the primary feed information.

The second migration is import_drupal_articles. This pulls in the article information using the same url, this time without the included images. When each article is pulled in, it is matched to the image that was pulled in previously.

You can run one migration at a time, or even just one item at a time, while testing this out:

drush migrate-import import_drupal_images --limit=1

You can rollback and try again.

drush migrate-rollback import_drupal_images

If all goes as it should, you should be able to navigate to the content list on your new site and see the content that Migrate pulled in, complete with image fields. There is more information about the Migrate API on Drupal.org.

What Next?

There are lots of other things you could do to build on this. A Drupal 8 to Drupal 8 migration is easier than many other things, since the source data is generally already in the right format for the target. If you want to migrate in users or taxonomy terms along with the nodes, you would create separate migrations for each of them that would run before the node migration. In each of them, you’d adjust the include value in the JSON API path to pull the relevant information into the feed, then update the YAML file with the necessary steps to process the related entities.

You could also try pulling content from older versions of Drupal into a Drupal 8 site. If you want to pull everything from one Drupal 6 site into a new Drupal 8 site you would just use the built in Drupal to Drupal migration capabilities, but if you want to selectively pull some items from an earlier version of Drupal into a new Drupal 8 site this technique might be useful. The JSON API module won’t work on older Drupal versions, so the source data would have to be processed differently, depending on what you use to set up the older site to serve JSON. You might need to dig into the migration code built into Drupal core for Drupal to Drupal migrations to see how Drupal 6 or Drupal 7 data had to be massaged to get it into the right format for Drupal 8.

Finally, you can adapt the above techniques to pull any kind of non-Drupal JSON data into a Drupal 8 site. You’ll just have to adjust the selectors to match the format of the data source, and do more work in the process steps to massage the values into the format that Drupal 8 expects.

The Drupal 8 Migrate module and its contributed helpers are getting more and more polished, and figuring out how to pull in content from JSON sources could be a huge benefit for many sites. If you want to help move the Migrate effort forward, you can dig into the Migrate in core initiative and issues on Drupal.org.

Catégories: Elsewhere

Drupal Association News: Drupal Association Financial Statements for Q3 2016

Planet Drupal - mar, 29/11/2016 - 20:43

We normally share  our financial statements in posts about public board meetings, since that is the time when board members approve the statements. However, I wanted to give this quarter’s update its own blog post. We’ve made many changes to improve our sustainability over the last few months and I am fully embracing our value of communicating with transparency by giving insight into our progress.

First, a word of thanks

We are truly thankful for all the contributions that our community makes to help Drupal thrive. Your contribution comes in the form of time, talent, and treasure and all are equally important. Just as contributing code or running a camp is critical, so is financial contribution.

The Drupal Association is able to achieve its mission to unite the community to build and promote Drupal thanks to those who buy DrupalCon tickets and sponsor the event, our Supporters and Members, Drupal.org sponsors, and talent recruiters who post jobs on Drupal Jobs.

We use these funds to maintain Drupal.org and it’s tooling so the community can build and release the software and so technical evaluators can learn why Drupal is right for them through our new marketing content. It also funds DrupalCon production so we can bring the community together to level up skills, accelerate contribution, drive Drupal business, and build stronger bonds within our community. Plus, it funds Community Cultivation Grants and DrupalCon scholarships, removing financial blockers for those who want to do more for Drupal. And of course, these funds pay staff salaries so we have the right people on board to do all of this mission work.

I also want to thank our board members who serve on the Finance Committee, Tiffany Farris (Treasurer), Dries Buytaert, Jeff Walpole, and Donna Benjamin. They provide financial oversight for the organization, making sure we are the best stewards possible for the funds the community gives to us. I also want to thank Jamie Nau of Summit CPA, our new CFO firm. Summit prepares our financial statements and forecasts and is advising us on long term sustainability.

Q3 Financial Statements

A financial statement is a formal record of the financial activities of the Drupal Association. The financial statements present information in a structured way that should make it easy to understand what is happening with the organization's finances.

Once staff closes the books each month, Summit CPA prepares the financial statement, which the finance committee reviews and approves. Finally, the full Drupal Association Board approves the financial statements. This process takes time, which is why Q3 financials are released in Q4.

You can find the Q3 financial statements here. They explain how The Association used its money in July, August, and September of this year. It takes a little financial background to understand them, so Summit CPA provides an executive summary and they set KPIs so it is clear how we are doing against important financial goals.

The latest executive summary is at the beginning of the September financial statement. In short, it says we are sustainable and on the right path to continue improving our financial health.

“We are working on building an adequate cash reserve balance. As of September a cash balance of $723K is 14% of twelve-months of revenue. Summit recommends a cash reserve of 15%-30% of estimated twelve-month revenue. Since Drupal’s revenue and expenditures drastically fluctuate from month to month [due to DrupalCon] a cash reserve goal closer to 30% is recommended.

Through August we have achieved a Net Income Margin of 4% and a Gross Profit Margin 33%. Our goal is to increase the Net Income Margin to over 10% during the next year.”
- Summit CPA

Improving our sustainability will continue to be an imperative through 2017, so the Association can serve its mission for generations to come. Financial health improvements will be achieved by the savings we gain over time from the staff reductions we did this summer. Another area of focus is improving our programs’ gross margins.

You can expect to see the Q4 2016 financials in Q1 2017. You can also expect to see our 2017 budget and operational focus. We are certainly excited (and thankful) for your support and we look forward to finding additional ways to serve this amazing community in 2017.

Catégories: Elsewhere

Agaric Collective: Redirect users after login to the page they were viewing in Drupal 8

Planet Drupal - mar, 29/11/2016 - 20:13

Have you ever been asked to log into a website while you are viewing a page? And after doing so you get redirected to some page other than the one you were reading? This is an obvious and rather common usability problem. When this happens people lose track of what they were doing and some might not even bother to go back. Let's find out how to solve this in Drupal 8.

In a recent project a client wisely requested exactly that: whenever a user logs into the site, redirect them to the page they were before clicking the login link. This seemed like a very common request so we looked for a contrib module that provided the functionality. Login Destination used to do it in Drupal 7. Sadly the Drupal 8 version of this module does not provide the functionality yet.

Other modules, and some combinations of them, were tested without success. Therefore, we built Login Return Page. It a very small module that just does one thing and it does it well: it appends destination=/current/page to all the links pointing to /user/login effectively redirecting users to the page they were viewing before login. The project is waiting to be approved before promoting it to full project.

Have you had a similar need? Are there other things you are requested to do after login? Please share them in the comments.

Catégories: Elsewhere

Third & Grove: Theming form elements in Drupal 8

Planet Drupal - mar, 29/11/2016 - 17:03
Theming form elements in Drupal 8 ross Tue, 11/29/2016 - 11:03
Catégories: Elsewhere

Xeno Media: Top Thirteen Drupal Twig Helper Modules

Planet Drupal - mar, 29/11/2016 - 16:29

We have been loving learning Drupal 8’s theming system over the last year.  Drupal 8 core now uses the Twig template engine, which is a fast, flexible, and secure system that allows use to create the markup needed for the modern web.

What you can do with Drupal core’s Twig is pretty great, but the Drupal community always brings so much more to the table after real world use.  We don’t use them all, all of the time, but have used many as our design and development needed.  Here are our favorite modules to help build out your Drupal themes.

Twig tweak

The Twig Tweak Drupal module gives Drupal 8 themers additional commonly needed functions and filters to use in templating:

  • drupal_view: Pass arguments to views.
  • drupal_block: Include a Drupal block.
  • drupal_entity: Include a Drupal entity.
  • drupal_field: Renders a field from a specific entity.
  • drupal_token: Use token API to deliver data to your templates.
  • drupal_config: Access and print configuration.
  • token_replace: Place multiple tokens.
  • preg_replace: The easiest way to alter their output.
  • image_style: Provide either path or URI to original image.

It also allows for you to turn PHP filter back on, which isn't recommended, and is off by default.

Twig Field Value

The Twig Field Value Drupal module allows Drupal 8 themers to get partial data from field render arrays.  If you want to have control of the markup on your field’s label and/or value, you can.  If you want to choose the field’s text format, you can.  This great utility module gives us the following filters:

  • field_label: Returns the field label value.
  • field_value: Returns the render array of the field value(s) without the field wrappers.
  • field_raw: Returns raw field properties value(s).
  • field_target_entity: Returns the referenced entity object(s) of an entity reference field.
Twig Extensions

This handy Drupal 8 module adds support for the Twig Extensions library.  The library adds additional filters to Twig itself, and this module allows us to use them in Drupal.

  • Text: Provides useful filters for text manipulation.
  • I18n: Adds internationalization support via the gettext library.
  • Intl: Adds a filter for localization of DateTime objects.
  • Array: Provides useful filters for array manipulation.
  • Date: Adds a filter for rendering the difference between dates.
Twig Extender

The Twig Extender Drupal module adds a plugin system to add new twig extensions.  It includes one filter (truncate), and one function (user_is_logged_in), and promises more in the future.  Looks very promising.

Themable forms

This simple, and extremely helpful Drupal 8 module adds theme suggestions for form elements.

  • form-element--[form-id]--[element-type].html.twig
  • form-element--form-id--[form-id].html.twig
  • form-element--type--[element-type].html.twig
  • form-element.html.twig
Twig Renderable

The Twig Renderable Drupal module is another module that adds Twig functions and filters, this time that work specifically with render arrays.

Function

  • will_have_output('path', 'to', 'render', 'array')

Filters

  • add_class(string|array $class)
  • merge_attributes(array|\Drupal\Core\Template\Attribute $attributes)
Transliterate Twig Filter

This module adds a single Twig filter for transliterating diacritic strings. Transliteration is the conversion of a text from one script to another, and this module converts diacritic characters, those that have accents in them, to their normal counterparts.

The included example shows how it works:

{{ 'Hällo' | transliterate() }} becomes => Hallo

Responsive SVG

The Responsive SVG Drupal module that adds a Twig filter, with quite a few options for SVG Stacks.  SVG Stacks are like image sprites, where you have multiple images in one file, though these images are Scalable Vector Graphics.  Support for regular SVGs forthcoming.

Twig Xdebug

The Twig Xdebug Drupal module adds the ability to use Xdebug within Twig templates.  Add {{ breakpoint() }} into the template where you want to debug, and when the Xdebug processor reaches it, a separate file will open so you can inspect the variables up to that breakpoint. The key values you'll see at the breakpoint are:

  • $context: Variables available to use in the template.
  • $environment: Info about the Twig environment, including available functions.
  • $arguments: You can also add arguments like {{ breakpoint(fields) }}.
Twig Clean Debug

This simple and handy module adds a Twig filter that removes the Twig debugging output, those informative HTML comments that let you know which templates are available, but they can also get in the way of what you are working on!

Update your template to use {{ content.field_image|clean_debug|raw }} when you are developing.  Remember to remove it before pushing to production though, it will error our if twig debug is not on!

Twig Link Attributes

The Twig Link Attribute Drupal module adds a Twig filter that allows you to add attributes to links, which also merges them with existing attributes.  Works well with the Menu Link Attributes module, but safely keeps some attributes in code, while Site builders and administrators can manage attributes in the UI.

Themers Little Helper

Similar to Twig Tweak, the Themers Little Helper (TLH) Drupal module adds a bunch of Twig filters and functions, and promises more!  The current release includes:

  • base_url: the Base URl of the site.
  • Wrap filter: {{ content.title_field|wrap('h3') }} for wrapping markup around fields.
  • drupal_view: Embed a view direct in your template.
  • drupal_block: Embed a block direct in your template.
  • dump(variable): Support for the Vardumper module, which is faster than kint.
Component Libraries

Finally, the Components Libraries Drupal module allows you to register “component libraries” defined by your theme or module as Twig namespaces.  This means that you can specify a different directory, rather than a folder called “templates” for your Twig files.  This is lays the foundation for being able to use component based theming, where each aspect of the design is an individual piece, or component, and allowing integrating the external tools like Pattern Lab and KSS Node, which would also use this Twig templates for living style guides.

Happy theming!

Catégories: Elsewhere

jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev

Devel - mar, 29/11/2016 - 16:22
Nov 29, 2016 jfhovinne pushed to feature/NEPT-380 at ec-europa/platform-dev
  • 6a7b009 test(jenkins): Make the webdriver host configurable.
Catégories: Networks

Acquia Developer Center Blog: Learn Drupal 8 for Free: Special Two-hour Version of FFW’s Drupal 8 Site Building Class

Planet Drupal - mar, 29/11/2016 - 16:09

FFW, the mega digital agency, is offering a free, two-hour course for business technology and marketing decision makers who want a compressed intro to Drupal with the added benefit of a live instructor.

The class focuses on Drupal’s core concepts so organizations can get the most out of the platform and avoid common mistakes. It’s designed to help smooth Drupal adoption by companies and organizations.

It's coming up on Thursday, December 08, 2016, from 1 PM to 3 PM EST.

Tags: acquia drupal planet
Catégories: Elsewhere

ComputerMinds.co.uk: Replacing a vocabulary listing

Planet Drupal - mar, 29/11/2016 - 14:00

In a recent Drupal 8 project, one of the site's vocabularies had several thousand terms in it (representing airports), which caused its admin listing page to run out of memory before it could render. I wanted to solve this without affecting any other vocabularies on the site, and improve the listing itself along the way to be more useful, with filters to make searching it much easier. The original listing is not a view, and loads much more than it needs to. Here's the customised page for airports that I wanted to head towards:

Catégories: Elsewhere

Agiledrop.com Blog: AGILEDROP: Drupal Camps in South America

Planet Drupal - mar, 29/11/2016 - 07:21
Famous beach Copacabana and football are the most frequent associations when we think of South America. Well, there are plenty more things there, that's for sure. Drupal Camps are one of those. In our world tour we already touched continents like Europe, North America, Asia and Africa. In the exact same sequence are continents listed from one with the most Drupal Camps (Europe) to the one with the least Drupal Camps (Africa). We expected to find South America between Asia and Africa, but for the first time, we were wrong. Our assumptions were so wrong, that it was difficult to process… READ MORE
Catégories: Elsewhere

blog.studio.gd: Drupal 8 Views Plugins (Part 2) : The display extender plugin

Planet Drupal - mar, 29/11/2016 - 03:36
Let's see how and why to use a views display extender plugin.
Catégories: Elsewhere

blog.studio.gd: Views Plugins (Part 1) : Simple area handler plugin

Planet Drupal - mar, 29/11/2016 - 03:36
In this series I will show you how to make use of the new Drupal 8 Plugin system, we begin with a simple example : the views area handler plugins.
Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur