Drupal Planet

Drupal Association blog: Drupal.org Digital Advertising Update

6 godzin 14 minutes ago

The Drupal Association is 4 years into our initiative to diversify revenue streams to make the Association more sustainable and less reliant on DrupalCon to fund all of our programs.  Monetization on Drupal.org itself is an important revenue stream that helps fund various Drupal.org initiatives and improvements

We’ve focused much of our effort creating new content that both serves new audiences and provides revenue opportunities, however, we’re still only monetizing roughly 20% of our total site traffic.  When we began, we outlined a few important guidelines for our efforts, including:

  • When possible, only monetize users who are logged out and not contributing to the Project.
  • Address the industry-wide shift to Programmatic Advertising, which is the automated buying and selling of digital advertising.

We’re piloting a new ad program to help us better achieve our monetization goals, while still respecting those users who actively contribute to the project.  We want to experiment with more traditional, high visibility banner ads that you typically see on other websites, such as 970 x 90 Leaderboard ads.  We also want to better leverage 3rd party ad networks and exchanges.  These new advertising placements will automatically check for two things before they display:  1) is the user an active contributor(based on contribution credits) and/or 2) is the user a Drupal Association Member.  If either of those are true, the ad won’t display.

New Ad Network Partner:  Carbon Ads
In addition to the pilot program above, we are also piloting a relationship with a new ad network sponsor, that is tailored to the audiences we serve. When we first launched advertising on Drupal.org, the community asked that ads remain relevant to the Drupal ecosystem. We agree that this is important, however, this makes it extremely difficult to leverage 3rd party ad exchanges like Google. While they offer category filters, it’s impossible to guarantee that every ad served will be relevant to Drupal.

Vertical-focused ad networks exist, although they’re becoming less common. We’re excited to announce that we’ve recently started working with Carbon Ads, a closed ad exchange that limits its advertisers to tech and developer focused advertising. They have a sales team of about 12 people working directly with companies like Microsoft, Slack, and Digital Ocean, and an advertising operations team that manages and uploads all ad creative themselves. This removes a lot of the risk that other self-serving ad platforms pose.

Why we love Carbon Ads:

  • They are a closed ad network (there’s far less risk of malicious, offensive, or unrelated ad content appearing on Drupal.org).
  • They are GDPR compliant.
  • They don’t track site visitors with cookies, nor collect their personal data for ad targeting. You can learn more about their data policy here.   The most sensitive data they collect is the IP address which they use to decide whether to show ads in a specific regions.  Furthermore, none of the data collected are stored permanently.
  • They come highly recommended from partner sites like Vue.js, Laravel, and Bootstrap.

It’s important that we fund Drupal.org improvements, and that we do so in a responsible way that respects the community. Thanks for taking the time to read about our initiatives, and please tell us your thoughts! 

We will be listening, identifying common themes and responding to feedback in about a week.
 

Hook 42: Hook 42 is off to the BADCamp Circus!

7 godzin 30 minutes ago

The BADCamp Circus is coming to town for 4 whole days! From cities near and far, Drupalists are converging in Berkeley very soon for this year’s circus-themed BADCamp!

Join Hook 42 under the bigtop for 3 unique sessions. We’ll be sharing our thoughts on redesigning the Stanford Cantor Arts Center website, accessibility tooling, and creating custom Drupal 8 modules. Of course, the whole team will be there too, collaborating with new and old friends alike.

Join us as we flex our Drupal muscles, perform daring acts of development, and add to the general merriment of the Drupal community. BADCamp 2018 is sure to not disappoint!

Evolving Web: Highlights of Drupal Europe

9 godzin 32 minutes ago

I spent last week hanging out with over 1000 Drupalers at Drupal Europe, the biggest Drupal event of the year in Europe. It was held in Darmstadt, Germany and brought Drupal users of all sorts from all over the world. Most attendees were from Europe, but many travelled from Asia, North America, and as far away as Australia to attend.

What Was Special About Drupal Europe?

Drupal Europe was basically a community-organized DrupalCon. It was a large event that had most of the features that you would associate with a DrupalCon from the professional venue to the DriesNote to the hundreds of valuable sessions to Trivia Night and the large contribution sprint on Friday.

Watching the 12 core organizers and countless other volunteers step up and organize this event was an inspiration. The volunteers are community members and they brought so many great ideas to the event that made the event excellent. Here are some of the things that I loved about the conference:

BoFs (small break-out sessions that are conversations between attendees rather than speaker-led) were incorporated into the main calendar of events making them highly visible. This made it easy to see which ones were going on. This meant that BoFs were popular and all that I attended seemed highly productive.

There were also lots of opportunities to contribute throughout the conference, and reduced-price contributor tickets were available for people who just wanted to work on the project and not attend sessions.

Diversity tickets were available. I haven’t seen the data, but it seemed like a more geographically and gender diverse conference than other Drupal events I’ve attended in Europe. 

The Splash Awards that kicked off the Tuesday of the event and highlighted great Drupal work being done. I think this is a great way to integrate more success stories and customers into the community.

The overall conference venue from the way the space and sponsor booths were laid out to the food were all very conducive to networking opportunities. There were lots of different spaces to chat, hang out, talk to sponsors, drink coffee, and contribute. The signage kept everything on track and allowed real-time updates to the schedule as needed (thanks Gabor Hojtsy!)

Updates from the Dries Note

If you didn’t attend the event, I recommend watching the DriesNote to get an update on what’s happening with the Drupal project and the community as a whole. Dries talked about the roadmap for Drupal. He touched on recent work on improving the evaluator experience, the work being done on the admin UI, and updates to drupal.org.
 

Drupal User Experience Study

I spent some of the week co-ordinating efforts around the Drupal UX Study that I’ve been working on. I got to meet with Cristina Chumulls and new contributors. We worked on the wireframes for the new Admin UI. The work we’re doing was promoted at the DriesNote, so watch from here to find out more.

If you want to get involved in helping us do user testing to improve the Drupal Admin UI, find us on the Admin UI channel on the Drupal Slack.

Working Together to Market Drupal!

I also spent a lot of my week talking to folks from different parts of the community about how we can work together to better promote Drupal. This resulted in three separate community efforts: creating a starter kit to help local associations promote Drupal, hiring a marketing manager to create materials for local communities, and a marketing pitch deck for the Drupal project as a whole.
Get in touch with me on the #marketing channel on the Drupal Slack if you want to get involved in these efforts and I’ll connect you to the right person! (my username is pixelite).

Where’s All the Drupal Talent?

Many Drupal agencies face challenges recruiting new talent. When we talk about marketing Drupal, the need to bring new people into the community always comes up. At Drupal Europe, I participated in a panel about how to recruit Drupal talent organized by Josef Dabernig. I talked about our efforts to Axcelerant. I also learned a lot about how other Drupal teams are organized and innovative programs for on-boarding junior developers.

Drupal Association

This was the first big Drupal event that I attended as a member of the board of the Drupal Association. I attended a board retreat the two days before Drupal Europe and got up-to-speed on what the Board is working on. I took advantage of the conference to connect with people in the community who are interested in the Promote Drupal initiative and other efforts of the association. I also sat on a panel about the past, present, and future of the Drupal Association and collected the feedback from audience members who were asking questions about the role of the association going forward.

I’m excited to get started on the board and I’ll post more updates as my involvement advances.

Watch more here!

#DrupalThanks
Again, huge thanks to the volunteer organizers of the event! 

 

 

+ more awesome articles by Evolving Web

Aten Design Group: Handling Timezones in a Progressively Decoupled Drupal Application

11 godzin 15 minutes ago

This year I’ve been working on a fun new Drupal-based event management application for libraries. During the course of development, I’ve become convinced that–beyond caching and naming things–the third level of Computer Science Hell is reserved for time zone handling. Displaying and parsing time zones proved to be a fruitful source of unforeseen issues and difficult to diagnose bugs.

The application we’ve been working on uses a progressively decoupled architecture, meaning interfaces that demand greater interactivity are self-contained client-side applications mounted within the context of a larger server-rendered Drupal site. This allows us to focus our efforts, time and budget on specific key interfaces, while taking advantage of Drupal’s extensive ecosystem to quickly build out a broader featureset.

Some examples of where time zone bugs reared their nasty heads:

  1. In certain cases, events rendered server-side displayed different date times than the same event rendered client-side.
  2. In a filterable list of events, time based-filters, such as “Show events between September 6th and 9th.”
  3. A user’s list of upcoming events would sometimes not include events starting within the next hour or two.
  4. Two logged in users could see a different time for the same event.

Let’s talk about that last one, as it’s a fairly common Drupal issue and key to understanding how to prevent the former examples.

User’s Preferred Time Zone

Drupal handles time zone display at the user level. When creating or editing their account, a user can specify their preferred time zone.

All users have a preferred time zone–even the logged-out anonymous user. A Drupal site is configured with a default time zone upon creation. This default time zone serves as the preferred time zone of all anonymous users. It also serves as the default preferred time zone for any new user account as it’s created.

When date values are rendered, the user’s preferred time zone is taken into account. Let’s say you have Drupal site with a default time zone set to America/New_York. If you have an event set to start at 4pm EST, all anonymous users–since they’re preferred time zone matches the site default–will see the event starts at 4pm.

However, a user with a preferred time zone of America/Phoenix will see that same event’s time as either 2pm or 1pm – literally depending on how the planets have aligned – thanks to the user’s time zone preference and Arizona’s respectable disregard for daylight savings time.

So the first thing you need to understand to prevent time zone bugs is users can set their preferred time zone.

Dates are Stored in UTC

One thing Drupal does really well is store dates in Coordinated Universal Time or UTC – I’m not sure that’s how acronyms work – but whatever. UTC is a standard, not a time zone. Time zones are relative to UTC. Dates are stored in the database as either Unix timestamps or ISO-8601 formatted strings. In either case they are set and stored in UTC.

Likewise, Javascript date objects are stored internally as UTC date strings. This allows dates to be compared and queried consistently.

The Disconnect

We now know Drupal and JS both store dates internally in a consistent UTC format. However JS dates, by default, are displayed in the user’s local time zone – the time zone set in their computer’s OS. Drupal on the other hand, displays dates in your user account’s preferred time zone. These two won’t always match up.

If the browser and Drupal think you are in two different time zones, dates rendered on the server and client could be off by any number of hours.

For example, you may be in Denver and have America/Denver set as your preferred time zone, but if you’re logged out and Drupal has a default time zone set to America/New York, server rendered times will display 2 hours ahead of client rendered times.

In another scenario, you may live in the same time zone configured as Drupal’s default and don’t have have a preferred time zone set. Everything looks fine until you travel a couple time zones away, and now all the client rendered dates are off.

This is the root cause of the bugs in the first three examples above.

The browser couldn’t care less what preferred time zone you have set in Drupal. It only knows local time and UTC time. Unlike PHP, JS currently does not have native functions for explicitly setting the time zone on a Date object.

Keeping Client- and Server-Rendered Dates in Sync

Now we know Drupal and the browser store dates in UTC. This is good. To make our lives easier, we’ll want to keep our client side dates in UTC as much as possible so that when we query the server with date-based filters, we get proper comparisons of dates greater than or equal to.

But we need to ensure our client-rendered dates match our server-rendered dates when they are displayed on the page. We also need to ensure dates entered via form fields are parsed properly so they match the user’s preferred time zone. There’s two things we need to do.

  1. Let the client know the user’s preferred time zone.
  2. Parse and display client-side dates using this time zone.

Passing the User’s Preferred time zone To do this, we’ll attach the preferred time zone via drupalSettings. This can be done via HOOK_page_attachments() in a .module file. If you don’t know how to create a custom module, there are plenty of resources online.

/** * Implements hook_page_attachments. */ function my_module_page_attachments(array &$attachments) { // Add user time zone to drupalSettings. $user_time zone = new \Datetime zone(drupal_get_user_time zone()); $attachments['#attached']['drupalSettings']['my_module']['user'] = [ 'time zone' => drupal_get_user_time zone(), ]; // Cache this per user. $attachments['#cache']['contexts'][] = 'user'; // Clear the cache when the users is updated. $attachments['#cache']['tags'][] = 'user:' . $current_user->id(); }

With this, we can now access the user’s preferred time zone in the browser from the drupalSettings global, like so:

const userTimeZone = drupalSettings.my_module.user.time zone; // Ex: ‘America/Denver’ Displaying, Parsing and Manipulating Dates in the User’s Time Zone

Now that we know the users preferred time zone client side, we can ensure any dates that are displayed and parsed, for example – from an input, are taking into account the correct time zone.

Currently there isn’t good native support for this in browsers. We have to either write our own functionality or use a third party date library. I typically use Moment.js for this. Moment has been around for a while and, as far as I know, has the best time zone handling.

To use Moment’s time zone handling, you’ll need to load the library with time zone support and the most recent time zone dataset. The dataset is required to map time zone names to the appropriate UTC offset – taking into account Daylight Saving Time at the appropriate time of year.

For all the following examples, we’ll assume you’ve loaded the time zone version of Moment with data bundled together as a browser global. There’s a number of other ways to import Moment via npm if you prefer to use it as a module.

<script src="https://momentjs.com/downloads/moment-time zone-with-data-2012-2022.min.js"></script> Setting a Time Zone on Dates

To begin with, we need to tell Moment what time zone we are dealing with. We’ll also assume userTimeZone has been set to the string value from drupalSettings above.

// Create a date for now in the user’s time zone const date = moment().tz(userTimeZone);

Just like Drupal and native JS Date objects, Moment stores the underlying date in UTC. The time zone plugin merely allows us to include a reference to a specific time zone which will be taken into account when manipulating the date with certain methods and formatting the date as a string.

const date = moment('2018-09-13 12:25:00'); date.unix(); // 1536863100 date.format('HH:mm') // ‘12:25’ date.tz('America/New_York') // "14:25" date.unix() // 1536863100

In this case, we are simply using Moment to display a date in a specific time zone. The underlying UTC date never changes.

Manipulating a Date

Whereas the format() method in Moment simply outputs a string representing a date, other methods manipulate the underlying date object. It’s important to take time zone into consideration when manipulating a date with certain operations to ensure the resulting UTC date is correct.

For example, Moment has a handy startOf() method that lets you set the date to, for example, the start of the day.

We instinctively think of the start of day as being 12:00 AM. But 12:00 AM in Denver is a different UTC time than 12:00 AM in New York. Therefore, it’s important to ensure our Moment object is set to the desired time zone before manipulating it. Otherwise we will get different results depending on the time of day and local time zone in which the method was executed.

Parsing a Date

In some cases, we need to parse a date. For instance, to correctly convert a Date Time field from Drupal into a JS Date object, we need to ensure it’s parsed into the right time zone. This is pretty straightforward as the date output from Drupal is in UTC. However, the client doesn’t know that. We can simply append the Z designator to indicate this date in UTC.

moment(`${someDateValue}Z`);

I typically wrap this in a function for easy reuse:

export const dateFromDrupal = date => moment(`${date}Z`).toDate();

And going the reverse direction:

export const dateToDrupal = date => date.toISOString().replace('.000Z', '');

Another use case for parsing dates is when handling user input. For example, if you have a filtering interface in which you need to show events on a given day. The user needs to enter a date. The HTML date input uses a simple string representation of a day, such as 2018-09-15 – in the user’s local time zone.

Now, if we want to take this input and query Drupal for events with a start time between the start and end of this day, we’ll need to convert this string value into a UTC date. We’ll need to do so by parsing this date in the user’s time zone, otherwise we might not get accurate results. In fact, they could be as much as a day off from what we’re expecting.

function changeEventHandler(event) { if (event.target.value) { const inputDate = moment.tz(event.target.value, userTimeZone); const startValue = inputDate.startOf(‘day’); const endValue = inputDate.endOf(‘day’); // Do something with the start and end date. } }

Date and time zone handling is one thing you should not take for granted when considering decoupling a Drupal application. Having a good understanding of how dates are stored and manipulated will help you identify, diagnose and avoid date related bugs.

Keep these things in mind throughout the development process and you should be fine:

  1. Store your dates and pass them around in UTC. This will help keep things consistent and reduce any time zone related bugs.
  2. Take time zone into account when dealing with user input and output. Time zones are relative to the user, so keeping those operations as close to the user interface as possible should keep the internals of the application simple.
  3. When considering any open source modules that deal with dates, such as React components or date handling libraries, make sure they allow for proper time zone handling. This will save you some headaches down the road.
  4. Test your application using different user time zones in Drupal and by manually overriding your time zone on your local machine. Sometimes bugs are not apparent until you are on a drastically different time zone than the server.

Good luck!

ARREA-Systems: Drupal 8 composer installation on EC2 with Ubuntu 18.04 LTS

14 godzin 11 minutes ago
Drupal 8 composer installation on EC2 with Ubuntu 18.04 LTS Fri, 09/21/2018 - 21:31 In this post we will share our experience with installing a Drupal 8 application on an Amazon EC2 server with latest Ubuntu 18.04 LTS. Installing Drupal with composer greatly simplify system maintenance and further update.

OpenSense Labs: CMS Comparison 2018: Drupal vs Umbraco

14 godzin 11 minutes ago
CMS Comparison 2018: Drupal vs Umbraco Akshita Fri, 09/21/2018 - 19:01

Like every organization, you want yours to build around consistent and successful marketing operations. The choice of your CMS has a lot to do with the execution of the successful marketing campaigns. 

Dynamic organizational goals need dynamic sites. Which raises the bar high when selecting the CMS of your choice. 

Comes along the cost involved in all aspects. 

In the comparison series, today, we have Drupal (open source software) vs Umbraco (proprietary software).

Here’s to choose between Drupal and Umbraco. Which one serves your needs better? Read on to know more. 

But first, let’s have a look at the market share of each CMS. 

Market Share of Umbraco vs Drupal  Source: W3TechsSource: W3TechsSource: Similartech


Drupal has better usage coverage in more websites categories. Including Business & Industry, Arts & Entertainment, People & Society, Career & Education, and 242 other categories. In other words Umbraco hasn't got a lead over Drupal in any websites category.

Let’s get to the actual comparison. 

Round One: The Cost

Umbraco is actually an open source but it heavily relies on proprietary software. Umbraco add-ons range from free to a licensing fee either per domain, per server, or a lifetime license. The licensing is covered under MIT license which means you can do whatever you want as long as you include the original copyright and license notice in any copy of the software/source. 

Drupal, on the other hand, is an open source software. Free to use, re-use, and distribute. Drupal modules (add ons) are free too. 

The Drupal.org (official Drupal website) writes it as “...It's built on principles like collaboration, globalism, and innovation. It's distributed under the terms of the GNU General Public License (GPL). There are no licensing fees, ever. Drupal will always be free.”

Drupal Wins!


Round Two: Editing Experience

At the heart of marketing lies content. 

A marketing CMS streamlines the work involved in creating new content in unprecedented ways. That is why your CMS needs to offer the right and intuitive kind of editing experience. 

Creating content is easy in Drupal. Authoring with WYSIWYG features is designed to keep content creation neat and ordered. It provides the preview and drag-and-drop image uploads option. And when you need to make quick changes with in-context editing it is easier. 

Not just this, it is available in 100 languages. You don’t have to limit your audience to one specific demography or language. 

With the help of a CKEditor feature built specifically for Drupal, you can more easily control details like image alignment and captions right from the palm of your hand.

By default, the editor enforces clean markup and has formatting tools disabled. In case you are looking to change the settings or editing buttons you just need to use a drag-and-drop configuration UI for adding and removing editor buttons.

Editing is indeed intuitive in Umbraco. 

It is easier to just add the content and rearrange it accordingly. Working on Drupal’s text editor for more than a year, it has been a breath of fresh air (no offense, Drupal community). Adding multimedia content is easy.

Not just this, you can also see the preview of your content on different sites with Umbraco’ unique Responsive Preview. Even before it is live. 

This ensures that the visitors experience the content the way you want them to. Adjustments are easy to make too. 

Another thing that adds is that as an editor you can always rollback to an older version. It’s like an infinite undo button. (@Drupal we need this.)

The built-in Umbraco Image Cropper ensures that your images are presented as you want. With the focal point you simply point and click on the most important thing in the image and the image is automatically resized and cropped so as to fit perfectly on any device while ensuring that the most important thing stays in focus. 

Drupal’s Focal Point module promises similar functionality but it needs to be added later. 

Both offer the option to schedule the content. 

Umbraco Wins! 


Round Three: Practicing Accessibility

It is very important that as an organization you don’t happen to miss any of your audience, not even by ignorance. 

Drupal 8 provides web accessibility out-of-the-box and it is mandatory. Not just this you could even mark content regions with attributes with HTML5 semantic markup. 

Navigation is simpler by identifying menus, banners, and ancillary content areas, and letting keyboard users move through them more easily. Drupal 8 puts these methods to work in a new admin toolbar that adapts to different screen widths, and is easier for people with screen readers to use.

Umbraco, although, provides accessibility features like alt text sadly they are optional. Accessibility is something that should be part of the general web development practices, and clearly Drupal ensures the discrimination doesn’t happen, as a choice. 

Drupal Wins!


Round Four: Community support

The Drupal Community is one of the largest open source communities in the world. The community support involves documentation creation, sharing networking opportunities, and more. The sheer commitment to the open source spirit pushes the Drupal project forward.

Around 1,300 agencies provide Drupal services across the globe (according to Drupal.org) and more than 3,200 contributors are working right now to improve the platform. 

Community support of Umbraco is no different. The official website tells us that they currently have an active community of over 200,000 “Umbracians” worldwide ready to share their experience and knowledge with others.

They take pride that the online community transcends to and becomes real gatherings all over the world in the form of local Umbraco meetups and even Festivals. 

It’s a Tie!
 

Round Five: Installation Profile

Getting started with the Umbraco? It provides you with two options - Clean website and the one with a demo. However good the intentions were a clean slate can be a bit overwhelming for some, especially if they’re new to Umbraco (did I copy that?)

Drupal - the latest 8.6 version provides with a starter kit - a basic site with a sleek minimalistic design of a food magazine. Learn and play with it. Set the features as you want. 

This makes it easy to customize and see how Drupal features set in. See if it fits your needs. 

Drupal Wins!


Round Six: Headless/ API first

An API first or Headless CMS simply lets you hit publish and your changes will automatically update on mobile apps, on store displays, flat screens, websites, even on smart watches. 

A feature that you can’t afford to miss especially when there are numerous screen types today. 

Umbraco promises that its headless “helps you edit the content easily in one place, and it is updated across your webshop, website, campaign sites and on displays on every screen.” 
 
Umbraco Headless helps you enable power for other types of websites with Umbraco such as Single Page Application or websites running on a different platform than .NET. 

Problem? 

The community is very close to having everything in place for the official launch of Umbraco Headless. It is not yet launched. All Hype, Nothing Fruitful

Drupal 8 core has out-of-the-box REST API that allows operators to interact with content entities like taxonomy terms, nodes, users, and comments.

Drupal 8 has Contenta (a Drupal distribution) and Reservoir are two of the API first initiative. Various contributed modules allow you to add web services to a Drupal installation without the need for writing code. 

For instance, Developers can use Services module and the RESTful Web Services module to configure a server for enabling the Drupal installation to push or allow data that is to be pulled as needed with the help of REST API. No matter whether the action is a push or pull, Drupal is the services layer. 

Drupal Wins! 


Round Seven: Training and Understanding 

Umbraco.TV will help you go from zero to Umbraco hero at a pace that suits you. Our easy to follow online training videos + written docs will give you the fundamental knowledge to start building awesome Umbraco websites, without burning a hole in your pocket!

Drupal has a steep learning curve. True that! 

But the content is easily available on the web. You can access learning material on Acquia, OSTraining, and Drupalize.me. Leaving Drupalize.me aside both the sources are free and available for all. 

It’s a Tie!


Round Eight: Hosting and Deployment

Drupal is hosting-service agnostic which can be deployed to any hosting service that supports PHP-based web applications. It stores the site configuration data in a consistent manner. It is easy to move configuration between environments like development, test and production environments.

Umbraco solutions are typically hosted by Microsoft Azure. To aid in deployment to Azure, Umbraco comes with an Azure toolkit consisting of ready-to-run command scripts, performance optimisation configurations, security essentials and many more. 

Being hosting-service agnostic, Drupal does the better job in this category.

Drupal Wins!


Conclusion

Every CMS has its own set of advantages. The choice of CMS is generally influenced by what your web project’s requirements are. The questions that follow are: What functionality or features are needed? 

In my opinion, Drupal has a bonus point for maintaining a modules directory that lets you search and manage the content. 

It's easier to customize components—views, lists, blocks, admin tools, and more—than ever before. Control how data is displayed without using a single line of code.

Drop a mail at hello@opensenselabs.com to discuss your business goals.

blog banner blog image Blog Type Articles Is it a good read ? On

OPTASY: Media Handling in Drupal 8.6.0: 4 New Features that Will Enhance Your Media Management Experience in Drupal

16 godzin 37 minutes ago
Media Handling in Drupal 8.6.0: 4 New Features that Will Enhance Your Media Management Experience in Drupal silviu.serdaru Fri, 09/21/2018 - 11:05

The media management experience had been one of the well-known sources of frustration for Drupal content editors for a long time. For, let's face it: Drupal's out-of-the-box media support was just... basic. But not anymore: there are new exciting features for media handling in Drupal 8.6.0 that will dramatically change the way you manage your media assets on your Drupal website!

Now, let's take a sneak peek at these most-anticipated media handling features that Drupal 8.6.0 comes equipped with:
 

Chocolate Lily: Managing Shared Configuration Part 5: Updating from Extensions

1 dzień 9 godzin ago

This is the fifth installment in a series presenting work on shared configuration that comes out of the Drutopia initiative and related efforts. To catch up, see Part 1, Configuration Providers, Part 2, Configuration Snapshots, Part 3, Respecting Customizations, and Part 4, Configuration Alters.

In this installment we'll start to pull it all together.

Paraphrasing a bit from Part 1, we described a key problem this way:

How can I update my site so that I have all the latest configuration changes from a distribution--while still retaining any customizations I made?

In Part 1 we mentioned Fabian Bircher's widely used Configuration Split module and its enabling API module, Config Filter, returning in Part 3 to give a more detailed introduction. In Part 2, we summarized the API and accompanying user interface that core provides for staging configuration. Here we'll take a deep dive into how we can merge in configuration updates from installed extensions through an approach that's built on Config Filter and closely parallels core's configuration staging.