* provides a hook to alter tabs
* provides a module that keeps uri query strings in tabs: If you are on node/view?destination=foo, you also see a tab node/edit?destination=foo
* provides a module that keeps uri suffixes in tabs: If you are on node/view/foo, you also see a tab node/edit/foo
Square's pitch is pretty straightforward: accept payments anywhere, no coding required. They nailed this first through their simple phone based card readers and their slick in-store tablet interface. They also made it easy to process all major credit cards, guaranteeing deposits as soon as the next business day.
They're now rolling out their same great support for merchants online with the steady release of open APIs for eCommerce applications. With our recently released Commerce Square module for Drupal 7 and Drupal 8, you can now pitch Drupal Commerce to existing Square customers in your area.
Thus far we integrate their payment APIs for full checkout and administrative support in Commerce 1.x and 2.x. We're working with Square to integrate new APIs as they become available in pursuit of our vision to enable the turnkey creation of online stores for Square merchants using Drupal Commerce.
Among the module's primary benefits, especially when used in conjunction with Square for retail sales, are:
- You can sell online, and in person, with all of your sales in one place. Integrating your physical and online retail operations will ultimately simplify the management of your business.
- Accept all major cards, (including Apple Pay and Android Pay in-store) and pay one simple rate per tap, dip, or swipe. (Note: Square also offers custom rates for qualifying stores processing over $250k annually.)
- Integration is simple and seamless for Drupal Commerce on both Drupal 7 and Drupal 8. (Look for new features to come into the D8 branch first and be backported, as additional contributed modules may be required to make up for core features that were added in Commerce 2.x.)
Square’s eCommerce API is on the bleeding edge of integration technology, making PCI compliance easy; customer credit card information never touches your website, so you don’t need to worry or complete a single checklist. Each component of the payment method form is an embedded iframe hosted on Square's server and returns a payment token identifier used to capture payment. We actually designed the Commerce 2.x checkout form to treat these types of payment methods as first class citizens, so expect the integration to just work.Sign up for Square and get free processing on your first $5,000 in sales.
As part of our module launch effort, Square has teamed up with us to offer free processing on your first $5,000 in sales. If you or one of your customers are interested in learning more, review the offer details here and hit us up in the issue queue if you run into any problems!
Reservoir is an experimental Drupal distribution that is an exceptional starting point for any decoupled Drupal implementation. It is also designed to on-board developers of all backgrounds: a decoupled Drupal distribution and optimal back end for every developer.Tags: acquia drupal planet
This is a module for accepting donations via Paypal.
Donation settings form:
Go to "admin/config/user-interface/donation" and set your values.
This module provide a "donation button block". so you can assign this block where you want on site.
Locked Content satisfies a specific access control use case: you want users to be able to see teasers, links, and search results for locked materials, but want them to log in before actually visiting the full page view. It's useful for situations where keeping the existence of information secret isn't critical, but making sure users are logged in before they actully view the complete contents is important.
The monthly security release window for Drupal 8 and 7 core will take place on Wednesday, June 21.
This does not mean that a Drupal core security release will necessarily take place on that date for any of the Drupal 8 or 7 branches, only that you should watch for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).
There will be no bug fix or stable feature release on this date. The next window for a Drupal core patch (bug fix) release for all branches is Wednesday, July 05. The next scheduled minor (feature) release for Drupal 8 will be on Wednesday, October 5.
This module is like a smart queue! You should use this module when you want to create an entityqueue based on a taxonomy. Dont mislead this module with Queue of taxonomy terms. Lets see when you should use module.
In February we spent a weekend in the Arctic Circle hoping to see the northern lights. I've been so busy, I only now got around to writing about it.
We decided to travel to Nellim for an action-packed weekend with outdoor adventure, wood fires, reindeer and no WiFi. Nellim, is a small Finnish village, close to the Russian border and in the middle of nowhere. This place is a true winter wonderland with untouched and natural forests. On our way to the property we saw a wild reindeer eating on the side of the road. It was all very magical.
The trip was my gift to Vanessa for her 40th birthday! I reserved a private, small log cabin instead of the main lodge. The log cabin itself was really nice; even the bed was made of logs with two bear heads were carved into it. Vanessa called them Charcoal and Smokey. To stay warm we made fires and enjoyed our sauna.
One day we went dog sledding. As with all animals it seems, Vanessa quickly named them all; Marshmallow, Brownie, Snickers, Midnight, Blondie and Foxy. The dogs were so excited to run! After 3 hours of dog sledding in -30 C (-22 F) weather we stopped to warm up and eat; we made salmon soup in a small make-shift shelter that was similar to a tepee. The tepee had a small opening at the top and there was no heat or electricity.
The salmon soup was made over a fire, and we were skeptical at first how this would taste. The soup turned out to be delicious and even reminded us of the clam chowder that we have come to enjoy in Boston. We've since remade this soup at home and the boys also enjoy it. Not that this blog will turn into a recipe blog, but I plan to publish the recipe with photos at some point.
At night we would go out on "aurora hunts". The first night by reindeer sled, the second night using snowshoes, and the third night by snowmobile. To stay warm, we built fires either in tepees or in the snow and drank warm berry juice.
While the untouched land is beautiful, they definitely try to live off the land. The Fins have an abundance of berries, mushrooms, reindeer and fish. We gladly admit we enjoyed our reindeer sled rides, as well as eating reindeer. We had fresh mushroom soup made out of hand-picked mushrooms. And every evening there was an abundance of fresh fish and reindeer offered for dinner. We also discovered a new gin, Napue, made from cranberries and birch leaves.
In the end, we didn't see the Northern Lights. We had a great trip, and seeing them would have been the icing on the cake. It just means that we'll have to come back another time.
This module changes default image field widget and formatter to allow use SVG image with the standard Image field.
Using SVG Image module you will not need to use another field to use SVG image instead of the already created Image field.
Don't forget to add a svg file extension into the list of the allowed image extensions in the field settings.
- SVG image field - Provides another field type used for SVG image uploading.
This module use the TOC API module for generating a Table of content for a whole node.
The table of contents is available as an extra field and can be placed anywhere in the node template.
The TOC options are provided by the TOC API module.
You can enable per content type the node's TOC, and for each content type select the TOC type to use.
- for running tests locally
- for running tests on CI server
Read more »
Message thread is part of the Message stack. It's purpose is to enable messages to be grouped into threads or conversations. It does not do anything by itself and needs to be used in conjunction with another message stack module such as Private Messages.
This module provides a REST endpoint that returns structured data for scalable use in a front-end library like React or Angular.
Since the release of Drupal 8 with a standardized way of managing translations, many sites running Drupal 7 are making a switch to Drupal 8. In Drupal 7 there are two ways to translate content:
- Using the content_translation module. The D7 core way of translating content, where every translation is a separate node.
- Using the entity_translation module. Maintains one node with a unique nid, while translations take place at the field level.
In this article we will discuss how to migrate content translations created with the content_translation module from Drupal 7 to Drupal 8. You can find our tutorial about migrating translations that use Entity Translation here.
This article would not have been possible without the help of my colleague Dave. ¡Gracias Dave!The problem
We have a Drupal 7 database containing article nodes, which might have translations in English, Spanish and French. Some of these nodes are language-neutral, i.e. non-translatable. Our target is to migrate the Drupal 7 nodes into a Drupal 8 website, preserving the translations.Before we start
- Since this is an advanced migration topic, it is assumed you already know the basics of migration. If are new to migrations in Drupal 8, I recommend that you read about migrating basic data to Drupal 8 first.
- If you'd like to run the migrations in this example yourself, see the quick-start documentation in our drupal migration i18n example repository.
- The source website used in this example is Drupal 7.54.
- The destination website used in this example is Drupal 8.3.x. However, an alternative solution for earlier versions is included towards the end of the article.
To write the migrations, we create a module - in our case, migrate_example_i18n. There's nothing special about the module declaration, except for the dependencies:
- migrate_plus and migrate_tools provide various features for defining and executing migrations.
- migrate_source_csv: Will be used for demonstrating migration of translated content from non-Drupal sources in an upcoming article.
- migrate_drupal: This module provides tools for migrating data from older versions of Drupal. It comes with Drupal 8.x core. Since this migration uses a Drupal 7 site as a source for its data, we need the migrate_drupal module.
Before jumping into writing these migrations, it is important to mention that Drupal 7 and Drupal 8 translations work very differently. Here's the difference in a nutshell:
- Drupal 7: When we translate a node, a new node is created with a different ID. This translated node has a property named tnid, which stores the ID of the original node, linking the two nodes together. For language-neutral or untranslated content, the tnid is set to 0.
- Drupal 8: When we translate a node, no new node is created! The translation is saved in the fields of the original node, but with a different language code.
So just like we do when migrating translated content from Drupal 6 to Drupal 8, we create two migrations:
- The example_dog_base migration will migrate the original content of each node, untranslated.
- The example_dog_i18n migration will migrate only translations and associate them with original content created by example_dog_base.
We group the two migrations using the example_dog migration group to keep things clean and organized. Then we can execute both migrations with drush migrate-import --group=example_dog --update.Step 1: Base migration
We start with example_dog_base to migrate all base data or non-translations. Described below are some noteworthy parameters:Source source: plugin: d7_node node_type: article key: drupal_7_content constants: uid_root: 1 node_article: 'article'
- plugin: Since we want to import data from a Drupal installation, we need to set the source plugin to d7_node. The d7_node source plugin is introduced by the migrate_drupal, module and it helps us read nodes from a Drupal 7 database without having to write queries manually. Since Drupal 8.3.x, this plugin supports translations created with the content_translation module. If you are using an older version of Drupal 8, then check the alternative solution provided towards the end of this article.
- node_type: This tells the source plugin that we are interested in just one particular Drupal 7 node type, namely article.
- key: Our Drupal 7 data doesn't come from our main Drupal 8 database - instead it comes from a secondary database connection. We choose a key to identify each such connection and we need to tell the source which such key to use. The keys themselves are defined in the $databases variable in our settings.php or settings.local.php. See the example settings.local.php file to see how it's done.
- constants: We define some hard-coded values under this parameter.
- translations: Notice there is no translations parameter here. The default value (false) tells the source plugin that we're only interested in migrating non-translations, i.e. content in the base language and language-neutral content.
- plugin: Since we want to create node entities in Drupal 8, we specify this as entity:node. That's it.
- translations: Again we do not define the translations parameter while migrating base data. Omitting the parameter tells the destination plugin that we are interested in creating fresh nodes for each record, not translations of existing nodes.
This is where we map the old node properties to the new node properties. Most of the properties have been assigned as is, without alteration, however, some noteworthy properties have been discussed below:
- nid: There is no nid parameter here, because we don't care what nid each new node has in Drupal 8. Drupal can just assign a new nid to each node in the normal way.
- type: We specify that we want to create article nodes.
- langcode: The langcode parameter was formerly language in Drupal 7, so we rename it here. Also, if a Drupal 7 node is language-neutral, the language property will have no value. In that case, we default to und.
This takes care of the base data. If we run this migration with drush migrate-import example_hybrid_base --update, all Drupal 7 nodes which are in base language or are language-neutral will be migrated into Drupal 8.Step 2: Translation migration
We are halfway through now! All that's missing is migrating translations of the nodes we migrated above. To do this, we create another migration with the ID example_dog_i18n:source: plugin: d7_node node_type: article translations: true # ... destination: plugin: 'entity:node' translations: true process: nid: plugin: migration source: tnid migration: example_dog_base langcode: language # ... migration_dependencies: required: - example_dog_base
- translations: We set this to true to make the source plugin read only translations.
- translations: We set this to true to make the destination plugin create translations for existing nodes instead of creating fresh new nodes.
- nid: In this case, we do care what the Drupal 8 nid is for each node. It has to match the nid for the untranslated version of this content, so that Drupal can add a translation to the correct node. This section uses the migration (migration_lookup) process plugin to figure out the right nid. It tells Drupal to check the previously-executed example_hybrid_base migration for a D6 node that has the same tnid as this D6 node. It will then then reuse the resulting nid here.
- langcode: We define the language in which the translation should be created.
- migration_dependencies: Since we cannot add translations to nodes that do not yet exist, we tell Drupal that this migration depends on the base migration example_dog_base. That way, the base migration will run before this migration.
That's it! We can run our translation migration with drush migrate-import example_dog_i18n --update and the translations will be imported into Drupal 8. Alternatively, we can use the migration group we defined to run both these migrations at once - the base migration will automatically be executed first and then the i18n migration. Here's how the output should look:$ drush migrate-import --group=example_dog --update Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_base' Processed 7 items (7 created, 0 updated, 0 failed, 0 ignored) - done with 'example_dog_i18n'
You can check if everything went alright by clicking the Translate option for any translated node in Drupal 8. If everything went correctly, you should see that the node exists in the original language and has one or more translations.
Article migrated from Drupal 7 to Drupal 8Alternate Solution for Drupal 8.2.x and Older
The example code for this article works out of the box with Drupal 8.3 or higher. However, it will not work with earlier versions of Drupal 8. For Drupal 8.2 or older, we need to use a custom source plugin (inspired by the d6_node plugin). All we have to do is use the D7NodeContnentTranslation source plugin included in the code for this example, like source: d7_node_content_translation. This custom source plugin adds support for the translations parameter, which in turn makes the migration of content translations work correctly.Next Steps
- View the code for the migrate_example_i18n project on GitHub.
- Read about migrating entity translations from Drupal 7 to Drupal 8.
- Read about migrating translated content from Drupal 6 to Drupal 8.
- Read about migrating translations from CSV, JSON or XML to Drupal 8.
- New to Drupal 8 migrations? Start with Drupal 8 migration basics.