Drupal Planet

Subscribe to canal de noticias Drupal Planet
Drupal.org - aggregated feeds in category Planet Drupal
Actualizado: hace 59 mins 39 segs

fluffy.pro. Drupal Developer's blog: Install the latest version of a composer programmatically

Dom, 11/05/2017 - 12:53
If you need to install the latest version of a composer you can use next bash snippet:EXPECTED_SIGNATURE=$(wget -q -O - https://composer.github.io/installer.sig) && \
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" && \
php -r "if (hash_file('SHA384', 'composer-setup.php') === '${EXPECTED_SIGNATURE}') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" && \
php composer-setup.php && \
php -r "unlink('composer-setup.php');" && \
mv composer.phar /usr/local/bin/composer
Using EXPECTED_SIGNATURE variable with the latest available signature value you don't have to hardcode a specific one for comparison on 3rd line.

Agaric Collective: Using CKEditor plugins in Drupal 8

Vie, 11/03/2017 - 15:21

CKEditor is well-known software with a big community behind it and it already has a ton of useful plugins ready to be used. It is the WYSIWYG text editor which ships with Drupal 8 core.

Unfortunately, the many plugins provided by the CKEditor community can't be used directly in the CKEditor that comes with Drupal 8. It is necessary to let Drupal know that we are going to add a new button to the CKEditor.

Why Drupal needs to know about our plugins

Drupal allows us to create different text formats, where depending on the role of the user (and so what text formats they have available) they can use different HTML tags in the content. Also, we can decide if the text format will use the CKEditor at all and, if it does, which buttons will be available for that text format.

That is why Drupal needs to know about any new button, so it can build the correct configuration per text format.

Adding a new button to CKEditor

We are going to add the Media Embed plugin, which adds a button to our editor that opens a dialog where you can paste an embed code from YouTube, Vimeo, and other providers of online video hosting.

First of all, let's create a new module which will contain the code of this new button, so inside the /modules/contrib/ folder let's create a folder called wysiwyg_mediaembed. (If you're not intending to share your module, you should put it in /modules/custom/— but please share your modules, especially ones making CKEditor plugins available to Drupal!)

cd modules/contrib/ mkdir wysiwyg_mediaembed

And inside let's create the info file: wysiwyg_mediaembed.info.yml

name: CKEditor Media Embed Button (wysiwyg_mediaembed) type: module description: "Adds the Media Embed Button plugin to CKEditor." package: CKEditor core: '8.x' dependencies: - ckeditor

Adding this file will Drupal allows us to install the module, if you want to read more about how to create a custom module, you can read about it here.

Once we have our info file we just need to create a Drupal plugin which will give info to the CKEditor about this new plugin, we do that creating the following class:

touch src/Plugin/CkEditorPlugin/MediaEmbedButton.php

With this content:

namespace Drupal\wysiwyg_mediaembed\Plugin\CKEditorPlugin; use Drupal\ckeditor\CKEditorPluginBase; use Drupal\editor\Entity\Editor; /** * Defines the "wysiwyg_mediaembed" plugin. * * @CKEditorPlugin( * id = "mediaembed", * label = @Translation("CKEditor Media Embed Button") * ) */ class MediaEmbedButton extends CKEditorPluginBase { /** * Get path to library folder. * The path where the library is, usually all the libraries are * inside the '/libraries/' folder in the Drupal root. */ public function getLibraryPath() { $path = '/libraries/mediaembed'; return $path; } /** * {@inheritdoc} * Which other plugins require our plugin, in our case none. */ public function getDependencies(Editor $editor) { return []; } /** * {@inheritdoc} * The path where CKEditor will look for our plugin. */ public function getFile() { return $this->getLibraryPath() . '/plugin.js'; } /** * {@inheritdoc} * * We can provide extra configuration if our plugin requires * it, in our case we no need it. */ public function getConfig(Editor $editor) { return []; } /** * {@inheritdoc} * Where Drupal will look for the image of the button. */ public function getButtons() { $path = $this->getLibraryPath(); return [ 'MediaEmbed' => [ 'label' => $this->t('Media Embed'), 'image' => $path . '/icons/mediaembed.png', ], ]; } }

The class's code is pretty straightforward: it is just a matter of letting Drupal know where the library is and where the button image is and that's it.

The rest is just download the library and put it in the correct place and activate the module. If all went ok we will see our new button in the Drupal Text Format Page (usually at: /admin/config/content/formats).

This module was ported because we needed it in a project, so if you want to know how this code looks all together, you can download the module from here.

Now that you know how to port a CKEditor plugin to Drupal 8 the next time you can save time using Drupal Console with the following command:

drupal generate:plugin:ckeditorbutton

What CKEditor plugin are you going to port?

Lullabot: Decoupled Drupal Hard Problems: Schemas

Vie, 11/03/2017 - 13:59

The Schemata module is our best approach so far in order to provide schemas for our API resources. Unfortunately, this solution is often not good enough. That is because the serialization component in Drupal is so flexible that we can’t anticipate the final form our API responses will take, meaning the schema that our consumers depend on might be inaccurate. How can we improve this situation?

This article is part of the Decoupled hard problems series. In past articles we talked about request aggregation solutions for performance reasons, and how to leverage image styles in decoupled architectures.

TL;DR
  • Schemas are key for an API's self-generated documentation
  • Schemas are key for the maintainability of the consumer’s data model.
  • Schemas are generated from Typed Data definitions using the Schemata module. They are expressed in the JSON Schema format.
  • Schemas are statically generated but normalizers are determined at runtime.
Why Do We Need Schemas?

A database schema is a description of the data a particular table can hold. Similarly an API resource schema is a description of the data a particular resource can hold. In other words, a schema describes the shape of a resource and the datatype of each particular property.

Consumers of data need schemas in order to set their expectations. For instance, the schema tells the consumer that the body property is a JSON object that contains a value that is a string. A schema also tells us that the mail property in the user resource is a string in the e-mail format. This knowledge empowers consumers to add client-side form validation for the mail property. In general, a schema will help consumers to have prior understanding of the data they will be fetching from the API, and what data objects they can write to the API.

We are using the resource schemas in the Docson and Open API to generate automatic documentation. When we enable JSON API and  Open API you get a fully functional and accurately documented HTTP API for your data model. Whenever we make changes to a content type, that will be reflected in the HTTP API and the documentation automatically. All thanks to the schemas.

A consumer could fetch the schemas for all the resources it needs at compile time or fetch them once and cache them for a long time. With that information, the consumer can generate its models automatically without developer intervention. That means that with a single implementation once, all of our consumers’ models are done forever. Probably, there is a library for our consumer’s framework that does this already.

More interestingly, since our schema comes with type information our schemas can be type safe. That is important to many languages like Swift, Java, TypeScript, Flow, Elm, etc. Moreover if the model in the consumer is auto-generated from the schema (one model per resource) then minor updates to the resource are automatically reflected in the model. We can start to use the new model properties in Angular, iOS, Android, etc.

In summary, having schemas for our resources is a huge improvement for the developer experience. This is because they provide auto-generated documentation of the API, and auto-generated models for the consumer application.

How We Are Generating Schemas In Drupal?

One of Drupal 8's API improvements was the introduction of the Typed Data API. We use this API to declare the data types for a particular content structure. For instance, there is a data type for a Timestamp that extends an Integer. The Entity and Field APIs combine these into more complex structures, like a Node.

JSON API and REST in core can expose entity types as resources out of the box. When these modules expose an entity type they do it based on typed data and field API. Since the process to expose entities is known, we can anticipate schemas for those resources.

In fact, assuming resources are a serialization of field API and typed data is the only thing we can do. The base for JSON API and REST in core is Symfony's serialization component. This component is broken into normalizers, as explained in my previous series. These normalizers transform Drupal's inner data structures into other simpler structures. After this transformation, all knowledge of the data type, or structure is lost. This happens because the normalizer classes do not return the new types and new shapes the typed data has been transformed to. This loss of information is where the big problem lies with the current state of schemas.

The Schemata module provides schemas for JSON API and core REST. It does it by serializing the entity and typed data. It is only able to do this because it knows about the implementation details of these two modules. It knows that the nid property is an integer and it has to be nested under data.attributes in JSON API, but not for core REST. If we were to support another format in Schemata we would need to add an ad-hoc implementation for it.

The big problem is that schemas are static information. That means that they can't change during the execution of the program. However, the serialization process (which transforms the Drupal entities into JSON objects) is a runtime operation. It is possible to write a normalizer that turns the number four into 4 or "four" depending if the date of execution ends in an even minute or not. Even though this example is bizarre, it shows that determining the schema upfront without other considerations can lead to errors. Unfortunately, we can’t assume anything about the data after its serialized.

We can either make normalization less flexible—forcing data types to stay true to the pre-generated schemas—or we can allow the schemas to change during runtime. The second option clearly defeats the purpose of setting expectations, because it would allow a resource to potentially differ from the original data type specified by the schema.

The GraphQL community is opinionated on this and drives the web service from their schema. Thus, they ensure that the web service and schema are always in sync.

How Do We Go Forward From Here

Happily, we are already trying to come up with a better way to normalize our data and infer the schema transformations along the way. Nevertheless, whenever a normalizer is injected by a third party contrib module or because of improved normalizations with backwards compatibility the Schemata module cannot anticipate it. Schemata will potentially provide the wrong schema in those scenarios. If we are to base the consumer models on our schemas, then they need to be reliable. At the moment they are reliable in JSON API, but only at the cost of losing flexibility with third party normalizers.

One of the attempts to support data transformations and the impact they have on the schemas are Field Enhancers in JSON API Extras. They represent simple transformations via plugins. Each plugin defines how the data is transformed, and how the schema is affected. This happens for both directions, when the data goes out and when the consumers write back to the API and the transformation needs to be reversed. Whenever we need a custom transformation for a field, we can write a field enhancer instead of a normalizer. That way schemas will remain correct even if the data change implies a change in the schema.

undefined

We are very close to being able to validate responses in JSON API against schemas when Schemata is present. It will only happen in development environments (where PHP’s asserts are enabled). Site owners will be able to validate that schemas are correct for their site, with all their custom normalizers. That way, when a site owner builds an API or makes changes they'll be able to validate the normalized resource against the purported schema. If there is any misalignment, a log message will be recorded.

Ideally, we want the certainty that schemas are correct all the time. While the community agrees on the best solution, we have these intermediate measures to have reasonable certainty that your schemas are in sync with your responses.

Join the discussion in the #contenta Slack channel or come to the next API-First Meeting and show your interest there!

Hero photo by Oliver Thomas Klein on Unsplash.

InternetDevels: Responsive images in Drupal 8: beautiful on every device!

Vie, 11/03/2017 - 10:48

When does “smaller” mean “bigger”? When your images grow smaller to perfectly adjust themselves to various devices, while your user satisfaction, audience coverage, website’s speed, and profits grow bigger. A nice formula, isn’t it? This magic ability of images to adjust themselves to screens is how responsive web design works. And it works especially well in the latest Drupal version, Drupal 8, which has built-in support for responsive images.

Read more

Agiledrop.com Blog: AGILEDROP: Why should agencies focus on building ambitious websites

Vie, 11/03/2017 - 09:35
Dries Buytaert, the founder of Drupal, gave great session this year at Drupalcon Vienna. Watch the part where he talks about who is Drupal for. Instead of focusing on big and small websites, or SME and enterprise clients, Dries describes the type of a website Drupal is made for as ambitious.  What is not an ambitious website A business that used to have a simple brochure website is now better off being served by SaaS (software as a service) solutions like Wix and Squarespace. Facebook, Google, and Amazon are providing services that not only cover what a good-old-website did in the past, but… READ MORE

Appnovation Technologies: Appnovator Spotlight: Meet Victoria Marcos

Vie, 11/03/2017 - 05:00
Appnovator Spotlight: Meet Victoria Marcos Who are you? What's your story? My name is Victoria Marcos, I’m from Venezuela and moved to England 8 years ago. I’m married and have a beautiful dog called Bonnie. I’ve been working in Appnovation for 3.5 years as Project Manager. I have a degree in Computer Engineering and a Master in Computer Science. I used to work as Business Analy...

OSTraining: What Does Delta Mean in Drupal?

Vie, 11/03/2017 - 02:44

When you are adding Views, you may have seen an extra option called "Delta".

Several students have asked us about the purpose of this field, because it wasn't clear.

The Delta option is available throughout the site, but ordinary users are most likely to encounter it inside Views. Here's how the "Delta" options appear in Views:

PreviousNext: Safely extending Drupal 8 plugin classes without fear of constructor changes

Jue, 11/02/2017 - 20:34
Share:

From time to time you may find you need to extend another module's plugins to add new functionality.

You may also find you need to alter the signature of the constructor in order to inject additional dependencies.

However plugin constructors are considered internal in Drupal's BC policy.

So how do you safely do this without introducing the risk of breakage if things change.

In this article we'll show you a quick trick learned from Search API module to avoid this issue.

by Lee Rowlands / 3 November 2017

So let's consider a plugin constructor that has some arguments.

Here's the constructor and factory method for Migrate's SQL map plugin

/**
   * Constructs an SQL object.
   *
   * Sets up the tables and builds the maps,
   *
   * @param array $configuration
   *   The configuration.
   * @param string $plugin_id
   *   The plugin ID for the migration process to do.
   * @param mixed $plugin_definition
   *   The configuration for the plugin.
   * @param \Drupal\migrate\Plugin\MigrationInterface $migration
   *   The migration to do.
   */
  public function __construct(array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration, EventDispatcherInterface $event_dispatcher) {
    parent::__construct($configuration, $plugin_id, $plugin_definition);
    $this->migration = $migration;
    $this->eventDispatcher = $event_dispatcher;
  }

  /**
   * {@inheritdoc}
   */
  public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {
    return new static(
      $configuration,
      $plugin_id,
      $plugin_definition,
      $migration,
      $container->get('event_dispatcher')
    );
  }

As you can see, there are two additional dependencies injected beyond the standard plugin constructor arguments - the event dispatcher and the migration.

Now if you subclass this and extend the constructor and factory to inject additional arguments, should the base plugin change its constructor, you're going to be in trouble.

Instead, you can use this approach that Search API takes - leave the constructor as is (don't override it) and use setter injection for the new dependencies.

/**    * {@inheritdoc}    */   public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition, MigrationInterface $migration = NULL) {     $instance = parent::create(       $container,       $configuration, $plugin_id,       $plugin_definition,       $migration     ); $instance->setFooMeddler($container->get('foo.meddler'); return $instance;   } /** * Sets foo meddler. */ public function setFooMeddler(FooMeddlerInterface $fooMeddler) { $this->fooMeddler = $fooMeddler; }

Because the signature of the parent create method is enforced by the public API of \Drupal\Core\Plugin\ContainerFactoryPluginInterface you're guaranteed that it won't change.

Thanks to Thomas Seidl for this pattern

Tagged Drupal 8, Plugins, OOP

Posted by Lee Rowlands
Senior Drupal Developer

Dated 3 November 2017

Comments

Comment by dawehner

Dated 3 November 2017

Nice!! Thank you for sharing it!

Pagination Add new comment

Drop Guard: Automatic updates - a study by the University of North Carolina State

Jue, 11/02/2017 - 09:45
Automatic updates - a study by the University of North Carolina State

A study from the North Carolina State University discovered that projects which are using open source libraries are updated 60% more often when using automatic updates via pull requests. The base of the study are 7,470 repositories on GitHub. This blog post is a summary of the most important facts and highlights of the methods, challenges and tools when it comes to use of automation for reaching a higher security level while using open source libraries.

There are 3 main facts why open source updates are a pain for developers
  1. Developers are always busy and doing updates is no fun

Drupal Planet Business Events Security PHP Study

Web Omelette: My First Book - Drupal 8 Module Development (Or Where I Have Been Lately)

Jue, 11/02/2017 - 05:01

If you’ve been wondering where I’ve been and why I haven’t been writing any articles lately, I am here to put your mind at ease: i’ve been working heavily on my first book about Drupal, called Drupal 8 Module Development. And I am happy to announce that it has finally been published and available for purchase.

Released by Packt Publishing, a leading publishing house for technical books in the Open Source world, my book is a comprehensive guide for developers new to Drupal 8. It aims to introduce you to module development starting from scratch but building up to complex functionalities. In doing so, you learn about all the fundamental subsystems and APIs available to work with in your Drupal module.

As you know, my website mainly focuses on Drupal knowledge via articles about tips and techniques, especially in Drupal 8 (most recently). So if you’ve been finding these helpful, I recommend checking out my book as it contains about 500 pages of great content aiming to help you ramp up your Drupal 8 module development skills. I appreciate each and every one who decides to give it a chance and I hope you find it as useful as I intended it to be.

Here is the list of chapters that will take you on the journey from starting a simple module to writing performant functionality using complex subsystems and APIs:

  • Chapter 1,  Developing for Drupal 8 , provides an introduction to module development in Drupal 8. In doing so, it introduces the reader to the various subsystems and outlines the requirements for running a Drupal 8 application.
  • Chapter 2,  Creating Your First Module , gets the ball rolling by creating the first Drupal 8 module of the book. Its main focus is to explore the most common things module developers need to know from the get-go.
  • Chapter 3,  Logging and Mailing , is about the tools available for doing something every web- based application does and/or should be doing, that is, sending emails and logging events.
  • Chapter 4,  Theming , presents the theme system from a module developer's perspective in Drupal 8.
  • Chapter 5,  Menus and Menu Links , explores the world of menus in Drupal 8 and shows how to programmatically create and work with menu links.
  • Chapter 6,  ata Modeling and Storage , looks at the various types of storage available in Drupal 8, from the state system to configuration and entities.
  • Chapter 7,  Your Own Custom Entity and Plugin Types , takes a hands-on approach creating a custom configuration and content entity type, as well as custom plugin type to wire up a practical functional example.
  • Chapter 8,  The Database API , presents the database abstraction layer and how we can work directly with data stored in custom tables.
  • Chapter 9,  Custom Fields , exemplifies the creation of the three plugins necessary for creating a custom field that can be used on a Drupal 8 content entity type.
  • Chapter 10,  Access Control , explores the world of access restrictions in Drupal 8, from roles and permissions to route and entity access checks.
  • Chapter 11,  Caching , looks at the various cache mechanisms available for module developers to improve the performance of their functionality.
  • Chapter 12,  Javascript and the AJAX API , introduces module developers to the specificities of writing JavaScript in Drupal 8, as well as the powerful AJAX system, which can be used to build advanced interactions.
  • Chapter 13,  Internationalization and Languages , deals with the practices Drupal 8 module developers need to observe in order to ensure that the application can be properly translated.
  • Chapter 14,  Batches, Queues, and Cron , explores the various ways module developers can structure their data processing tasks in a reliable way.
  • Chapter 15,  Views , looks at the various ways module developers can programmatically interact with Views and even expose their own data to them.
  • Chapter 16,  Working with Files and Images , explores the various file and image APIs that allow module developers to store, track, and manage files in Drupal 8.
  • Chapter 17,  Automated Testing , explores the various types of automated test module developers can write for their Drupal 8 applications to ensure stable and resilient code.
  • Annex, Drupal 8 Security , recaps some of the main things module developers need to pay attention to for writing secure code in Drupal 8.

If you find something incorrect or out of place, please use the appropriate errata submission form mentioned in the book. And as always, feel free to drop comments below about the your thoughts on the book. Enjoy and thank you very much for purchasing my book!

Hook 42: October Accessibility (A11Y) Talks

Mié, 11/01/2017 - 23:18

This month we had Nicolas Steenhout joining us to talk about "Accessibility: Don't turn off that JavaScript just yet."

The year is 2017, and JavaScript has never been as ubiquitous. Long gone are the days when in order to be considered accessible, pages had to work flawlessly without scripting. Scripting has also come a long way, and developers are now even leveraging the powers of JavaScript to rewrite content in order to make it more accessible to assistive technologies.

Nextide Blog: Maestro D8 Concepts Part 4: Interactive Task Edit Options

Mié, 11/01/2017 - 23:04

This is part 4 of the Maestro for Drupal 8 blog series, defining and documenting the various aspects of the Maestro workflow engine.  Please see Part 1 for information on Maestro's Templates and Tasks, Part 2 for the Maestro's workflow engine internals and Part 3 for information on how Maestro handles logical loopback scenarios.

Freelock : Freelock Interviewed on Drupal and WordPress Expertise

Mié, 11/01/2017 - 21:42
microphone-with-screen-with-chart.jpg

In September, Freelock was recognized as a leading web development company in Seattle by Clutch. Not only were we thrilled to be featured in that report and ranked as one of the top three web developers in the area, but we are excited to share that as a result, Clutch interviewed us on our web development expertise.

Drupal PlanetSecurityDrupalWordPressDrupal 8CMS

myDropWizard.com: Drupal 6 security update for Autologout 6.x-4.x

Mié, 11/01/2017 - 18:16

As you may know, Drupal 6 has reached End-of-Life (EOL) which means the Drupal Security Team is no longer doing Security Advisories or working on security patches for Drupal 6 core or contrib modules - but the Drupal 6 LTS vendors are and we're one of them!

Today, there is a Moderately Critical security release for the Autologout module to fix a Cross Site Scripting (XSS) vulnerability.

This module provides a site administrator the ability to log users out after a specified time of inactivity.

The module does not sufficiently filter user-supplied text that is shown when logging a user out. This vulnerability is mitigated by the fact that an attacker must have a role with the permission "administer autologout".

See the security advisory for Drupal 7 for more information.

Here you can download the Drupal 6 patch.

NOTE: This only affects the Autologout 6.x-4.x branch -- the 6.x-2.x branch (which we also support) isn't vulnerable.

If you have a Drupal 6 site using the Autologout module, we recommend you update immediately.

If you'd like all your Drupal 6 modules to receive security updates and have the fixes deployed the same day they're released, please check out our D6LTS plans.

Note: if you use the myDropWizard module (totally free!), you'll be alerted to these and any future security updates, and will be able to use drush to install them (even though they won't necessarily have a release on Drupal.org).

Commerce Guys: Commerce Braintree integration adds PayPal Express Checkout and PayPal Credit support

Mié, 11/01/2017 - 16:13

Drupal Commerce is more than just a module project. As I laid out in my session at DrupalCon Vienna, it is an entire ecosystem supported by dozens of agencies and powering well over $1.5bn in online transactions annually. This makes Drupal Commerce one of the largest open source eCommerce projects in the world, and it's thanks in no small part to our Technology Partners (comprised primarily of payment providers) that we are able to invest as much of our time in it as we do.

Braintree is one such partner and a fantastic supporter of Commerce 2.x since last Summer. During our sprint to release a beta at DrupalCon Dublin, they sponsored Bojan's time for two weeks to expand and improve the core Payment API.

As a result, they also became the first integrated payment gateway and the test case for any payment provider following their integration pattern - individual iframes embedded into the checkout form for each payment field, making it easy to securely collect payment card data through your own checkout form.

For the initial release of the Commerce Braintree integration on Drupal 8, we targeted basic credit card payment support via their Hosted Fields API. As of this week, we've finalized patches that add support for PayPal Express Checkout and PayPal Credit alongside credit card payment through Braintree. They are a PayPal company, after all!


Customers can pay via credit card on-site or Express Checkout via a modal dialog.

You can test the new features end to end by grabbing the latest release of the Commerce Braintree module and configuring it to work through the Braintree sandbox. If you get stuck, you can find us in the #commerce channel in the Drupal Slack or open an issue in the queue if that's not possible.

Thanks again to Braintree for their support and development sponsorship. If you'd like to learn more about how Technology Partners benefit our ecosystem, consider joining me and Commerce Braintree's D7 co-maintainer Andy Giles this weekend at DrupalCamp Atlanta (Nov. 3-4). I'll present a longer version of my DrupalCon session, Marketing and Selling the Drupal Commerce Ecosystem, and naturally I'll tap Andy to help me answer all your hardest questions. ; )

Acro Media: Video: What to Expect Now That Drupal Commerce 2.0 is Live

Mié, 11/01/2017 - 13:12


Lots of live Commerce 2 sites were actively and successfully selling products to people long before the official launch on September 20th. We ourselves were among the early adopters taking advantage of the new functionality available in Drupal 8. But as with any new-and-not-fully-tested technology, there were the inevitable growing pains: missing functionality, bugs, etc. Fortunately, most of those issues are now in the past.

A few core modules that were buggy but are solid now:

  • Promotions and coupons
  • Taxes
  • Payments (supports 30+ payment gateways!)
  • Products
  • Orders

As an added bonus, the Commerce Shipping module that Acro Media helped develop received a full stable release alongside Commerce 2 (which is especially cool when you remember that Commerce 1 launched with no shipping functionality at all). Commerce Shipping features a much improved API and includes support for UPS and FedEx, with USPS to follow shortly.

Acro Media and other community members have been working on a few other associated modules to go along with the Commerce 2 launch. Here are the details:

  • Point of Sale is going to alpha release
  • Commerce Migrate is going to have a new release (likely not a stable release, however, as there is still work to be done migrating edge cases)

    Ubercart to Commerce 2 migrate is mostly done and includes all core stuff like products, customers, orders, taxes, etc.

    Commerce 1 to Commerce 2 migrate is a little rough but is still very usable; an improved version should be ready in October sometime

A cool new Composer based Commerce Kickstart installer is also available! It represents a great improvement over the original Commerce Kickstart and should be easier for everyone to use. You can find that here.

TLDR: The fully supported, stable release of Commerce 2 is live and has lots of cool stuff with it. If you were hesitant to use it to build sites before, you most certainly can go ahead now.

OSTraining: Using the Focal Point Module for Images in Drupal 8

Mié, 11/01/2017 - 12:24

You most likely created image styles with Drupal's "Scale and crop" image effect. This style allows you to display large images on a smaller scale and save precious screen space.

There is one issue with such styling though. Often the most interesting point of the image gets chopped off. The "Focal Point" contrib module helps avoid this issue.

In this tutorial, you will learn to use this module to select the most important portion of the image you would like to show to your readers. 

ADCI Solutions: Visual regression testing for Drupal using Gemini

Mié, 11/01/2017 - 09:00

Testing a lot of pages after small changes in CSS files - again and again... Looks familiar? Gemini gets you rid of this waste of time. We will show you how to write Gemini tests and extend this tool.

 

Learn about visual regression testing for Drupal

 

Drupal Modules: The One Percent: Drupal Modules: The One Percent —Multiple Registration (video tutorial)

Mié, 11/01/2017 - 00:16
Drupal Modules: The One Percent —Multiple Registration (video tutorial) NonProfit Tue, 10/31/2017 - 21:16 Episode 42

Here is where we seek to bring awareness to Drupal modules running on less than 1% of reporting sites. Today we'll consider Multiple Registration, a module which gives you the ability to create role-specific registration pages.

Agiledrop.com Blog: AGILEDROP: 5 sessions about project management from DrupalCon Vienna

Mar, 10/31/2017 - 23:20
In case you have missed some of the Drupalcon Vienna’ session about project management, here they are.    A new Approach for Improving Estimations with Content Discovery Workshops Richard Jones, CTO at Inviqa   The research process connects the client and all participants with each other so that all things are clarified before they start working on a project. In this process, teams plan how they will fulfill the client's requirements. However, it can quickly happen to overestimate the performance of the system, so the assessment is not accurate enough. In this session, a workshop… READ MORE

Páginas