Development News

Matt: Combating Epidemics With Internet

Wordpress Planet - Fri, 06/26/2020 - 18:41

In 2006 David Eagleman, who wrote one of my favorite books, Sum, wrote a letter published in Nature:

Kathleen Morrison, in News & Views (“Failure and how to avoid it” Nature 440, 752–754; 2006), notes that societies have often prevented collapse by adopting new technological strategies. In today’s world, where one of the most-talked about prospects for collapse is an epidemic of infectious disease, it is worth remembering that perhaps we already have the technological strategy to avoid it — the Internet.

Remote working, made possible by the Internet (‘telepresence’), is already a key component of national and business pandemic plans. Telepresence can inhibit viral transmission by reducing human-to-human contact. Prepared organizations can leverage telepresence to allow continued productivity and functioning of supply chains during an outbreak.

He explores these ideas as well in his Long Now talk in April 2010, in which he talked about Six Easy Steps to Avert the Collapse of Civilization. Here’s an excerpt from that talk covering telepresence and telemedicine. Both videos have had under a thousand views so far. When you watch this remember that it was April, 2010!

This is the topic of his new book, The Safety Net: Surviving Pandemics and Other Disasters.

OpenLucius: Drupal how-to: redirect anonymous users to login page | A working example module (Drupal 9 compatible)

Main Drupal Feed - Fri, 06/26/2020 - 10:07

For our Drupal distribution we needed to redirect all anonymous users to the login page, as for now it's implemented as a closed platform for social collaboration. The Drupal 8 way didn't work anymore; we fixed it for Drupal 9 and published a working module. 

So if you're building a Drupal social intranet, collaboration tool or community this might help you to direct them the right way -so they don't get an unfriendly 'access denied'.

Keep in mind that you still have to build the correct access control into all your pages with help of permissions / access checks / advanced route access, this module doesn't provide for that.

Third & Grove: Five Tactics to Generate More B2B Leads with Drupal

Main Drupal Feed - Fri, 06/26/2020 - 05:46

To sell a business a product or service, you have to get in front of the right buyer at the right time. It’s really the second part of that sentence that is so crucial. Why? Because you can’t win deals you don’t know about.

WPTavern: Add Per-Block Notes and Create Draft Blocks With the Wholesome Publishing Plugin

Wordpress Planet - Thu, 06/25/2020 - 20:58

Matt Watson, through his Wholesome Code brand, released a plugin called Wholesome Publishing on the WordPress plugin directory on Tuesday. Version 1.0 of the plugin adds a couple of simple but useful editing features that should help teams of writers or content designers. The plugin allows users to add nested comments on a per-block basis and mark individual blocks as drafts.

At this point, the plugin is not a fully-fledged pro editing plugin. However, its basic features go a long way toward improving collaborative publishing. It is a good first showing for a version 1.0. I hope that it continues to grow and bring new editing features to the block editor.

The plugin works with both core WordPress and third-party blocks. Overall, it performed well in my tests, but I did find a few minor issues that could be easily addressed in a future update. If you are looking for such a plugin, it is well worth a test run to see if it fits into your publishing workflow. I am seriously considering it for use here on WP Tavern, if that provides an indication of its potential.

Nested Block Comments Adding nested comments to a Cover block.

The primary feature that drew me to this plugin was the ability to leave simple notes via the block editor. Even here on the Tavern, we have an old editorial notes system, but it is no longer a user-friendly option with the block editor. Notes are tucked away at the bottom of the editing screen along with other old-school meta boxes. A new system, particularly one that allowed comments on a per-block basis, was definitely worth exploring.

Block comments — not to be confused with post comments on the front end — are simple to add. On the post editing screen, users merely need to click the comment button in the toolbar, which will open a comments sidebar panel. The panel will show a text box to add a new comment for the currently-selected block.

Comments belong to individual blocks. However, it is not clear in the comments sidebar panel which block a comment is for when there are multiple comments. Clicking on a single comment selects the block in question, which helps, but the user experience would be better with two additions:

  • The selected block’s comments should be highlighted while unrelated comments fade out.
  • There should be an indicator in the comments sidebar that points out the block each comment is assigned to.

Unfortunately, it is not possible to see or leave a comment unless you are an administrator. I am unsure if this is intentional or a bug. It is at least a user experience issue because the comments sidebar panel still appears, regardless of whether the user can read the block comments.

Despite the need for a bit of polishing to improve the experience, this feature was reasonably easy to pick up and use right away.

The plugin does clean up after itself. If a user deletes a block, its comments are also deleted.

I do have one big feature request for the plugin author. An opt-in setting for enabling an email system would be a nice touch. The post author and anyone who leaves a comment on the post should be notified when a new comment is made.

Create Draft Blocks Setting a Gallery block to draft status.

The second plugin feature goes hand in hand with the first. Wholesome Publishing allows end-users to mark any block in the post as a draft, which means the block will not appear on the front end of the site. The reason it works well with the comments feature is that users can explain why the block was marked as a draft. This could be particularly useful on teams of multiple writers.

In the block options panel, users should see a new tab titled “Publishing.” The tab will have a single on/off switch for setting the given block as a draft. Unlike the block comments system, any user can put an individual user into draft mode as long as they have access to edit the post.

I did run into one issue with draft blocks. When clicking the on/off toggle, all of the block options tabs would reset to the default open or closed state. It is a trivial issue that might become irritating for some. Outside of that, the feature worked well.

Digital Echidna: Thoughts on all things digital: Adopting open source in the transit and transportation industry

Main Drupal Feed - Thu, 06/25/2020 - 16:06
The fundamental building blocks of running an efficient and user-focused public transportation network and building a well-designed, effective, and user-centric website are actually pretty similar: You need talented people, quality data, and elite…

wishdesk.com: URL shortener integration for a Drupal website

Main Drupal Feed - Thu, 06/25/2020 - 15:37
Our web agency that creates appealing, feature-rich, and user-friendly websites, shares a post on URL shorteners: what they are, why they are used, and how to integrate a URL shortener with a website. 

Gábor Hojtsy: State of Drupal 9 - first post-release recording from Drupal India Conclave

Main Drupal Feed - Thu, 06/25/2020 - 14:58

Last week I had the pleasure to present my open source State of Drupal 9 talk at Drupal India Conclave. It was great with very timely questions. While I keep the slides up to date, there is always some new development. Since the recording of this video, Drupal 7's community security support was extended with a year to November 2022. The session should be fully up to date otherwise as of today. Feel free to use the slides to present at your own meetup or in-company training. Thanks Drupal India Association for having me on the program!

Ny Media: Deploying translations in Drupal

Main Drupal Feed - Thu, 06/25/2020 - 12:19
Deploying translations in Drupal eirik June 25, 2020

One of the things that is remarkable with Drupal 8 (and Drupal 9) is the support for multiple languages. You can translate anything, so making a page completely Norwegian is something Drupal supports out of the box.

If you download Drupal and a couple of modules, you can with just a few clicks have almost all of the interface translated into Norwegian, since translation is a community effort. This means that most of the strings we and our users see during a normal work day, are already translated by us, or someone else in the community. A very special shout out here to svenryen, who almost by himself went through all the strings in Drupal 8.

Today I want to introduce another interesting challenge, and how we are able to solve that with Drupal. Namely deploying new features that should contain translations.

At Ny Media we develop tailored and highly customized solutions for our clients. This way we ensure that their result will make their job and their business easier and more profitable. To do this, we often end up writing custom code for use either between our own projects, or for a specific client.

Translating Drupal Core is a community effort. But brand new strings coming from features that we just created in custom code is not something we can rely on the community to get translated. So we have to do it ourselves. The challenge here lies in how we can get the strings translated on the production site, when the strings are only found in this specific project. Let’s look at a couple of theoretical solutions, and then look at the solution we use. Which we by coincidence think is the best, and now we want to share this with you.

Let’s imagine that we are developing a feature where we display some Copyright information on every page, and we want to translate that. Let’s just say that we call this module “copyright_info”. And maybe we have some code that looks like this:

/** * Implements hook_preprocess_HOOK(). */ function copyright_info_preprocess_page(&$variables) { $variables["page"]["content"][] = [ '#markup' => t('Thank you for visiting this site, and we hope you like the content. However it is copyrighted so please do not steal it.'), ]; }

Now on every page we will have the whole interface in Norwegian. The only exception is the part with copyright, since that is something we just wrote ourselves.

Screenshot from translated frontpage. Note the untranslated custom string. Option 1: Translating “by hand” when the new feature is deployed.

This is the easiest and most obvious way to do it. After you have deployed your new feature, you go into the administration form for your site. This part is located under  Administration -> Configuration -> Regional and language -> User interface translation, or path admin/config/regional/translate. So we search up the string(s) we just made. Then we can translate them one by one.

This is a very transparent and easy solution. And that has its advantages:

  • Requires no additional build steps to import translations
  • Requires no additional modules to enable

However, it has some disadvantages as well:

  • Tedious to do for more than one translation.
  • Error prone (Copy-paste errors, or typos)
  • You end up having a deployed site with a temporarily untranslated string while you are manually editing the translation(s).

In this example case this might be a good solution since we only have that one string. But once you get more than 1 string to translate, you really do not want to do that by hand. And if you have a high traffic site, you probably do not want your site do be untranslated while you work.

Option 2: Exporting translation on a dev/staging site, and importing it on the live site

Another option that is available out of the box, is to export all the translated strings you have on one site, and then import them on another.

First you can export and download the strings from a copy of the site where your new strings are translated. Then you upload and import the strings on the live site

This is also fairly easy to do so it does have similar advantages:

  • Requires no additional build steps to import translations
  • Require no additional modules to enable
  • Supports importing of huge amounts of text

It does however come with some disadvantages:

  • Still manual work, and might leave your site temporarily untranslated
  • Requires manual intervention
  • The translations batches are not version controlled
Option 3: Importing custom translations as a part of your build process.

As you probably have figured, this is the option I wanted to highlight in this blog post, and this is the method we are currently using in Ny Media. To achieve this we use a Drupal module called Custom translation deployments. This is a module we developed as part of a client project, which in turn ended up being our standard setup for deploying translations on our projects.

The module provides two ways of providing translations to easily deploy as part of the build process. We will look at the most simple here, and then briefly mention a slightly more advanced way.

The first step of being able to deploy translations is making sure your translations are committed to your version control system. A default Drupal installation will set the translation directory to sites/default/files/translations,. This is typically a directory ignored by the version control system. So we start this process by changing it to somewhere we can check in to our version control system. Like ../translations. To change it, we go to the page for File system located under Administration -> Configuration -> Media, or at path admin/config/media/file-system.

Since the project is located one level below the Drupal installation, we place the translations in a translations folder in the root of the directory.

Here in Norway we are usually looking for Norwegian translations for our Norwegian clients. The module Custom translation deployments comes with a predefined translation file pattern defined. Meaning if we place a file called project_specifc-custom.LANGUAGE.po (or in the case of Norwegian project_specifc-custom.nb.po) in the newly defined and created translation folder, it will get imported. Let’s try that.

First let's make sure the file is in place.

$ ls ../translations project_specific-custom.nb.po

Now one can either use the interface (under Administration -> Reports -> Available translation updates - admin/reports/translations) or do this with drush.

The other convenient thing is to add this as part of your deployment script. Maybe you have some sort of Continuous Deployment tool for it, or maybe you just use some manual and run it on your server. Whatever boat you are in, you can always do something like this:

$ drush sdel locale.translation_last_checked && drush locale-update && drush cr > [notice] Translation file not found: http://ftp.drupal.org/files/translations/8.x/project_specific/project_specific-custom.nb.po. > [notice] Checked nb translation for project_specific. > [notice] Imported nb translation for project_specific. > [notice] Translations imported: 1 added, 0 updated, 0 removed. > [notice] Message: En oversettelsesfil importert. /1/ oversettelser ble lagt til, /0/ > oversettelser ble oppdatert og /0/ oversettelser ble fjernet.

This is actually 3 commands. The first one makes sure that Drush is forced to think it is time to update the translations. The second one updates the translations, and the third one clears the cache. This third step is important if you have translated strings in your JavaScript.

But it is also possible to do this through the interface. Which would look something like this.

One other thing to note is that having the project defined as a locale project, means you can have a translation file on a server, and Drupal will look for updates to it. As you can see from the drush output above, it will look for it in a specific pattern. This is defined as part of the hook implementation for custom_translation_deployments. So if you want a translation file for your organization you can have a custom module implementing this hook, and therefore also make it available to be updated and downloaded automatically. Her is one such example:

/** * Implements hook_custom_translation_deployments_files(). */ function my_org_custom_translation_deployments_files() { $items = []; $items[] = [ 'name' => 'my_org', 'project_type' => 'module', 'core' => '8.x', // We set the version to something static, but not to "dev". 'version' => 'custom', 'server_pattern' => 'http://my_org.com/files/translations/%core/%project/%project-%version.%language.po', 'status' => 1, ]; return $items; }

This way we can now either ship a translation file called my_org-custom.nb.po or a file on http://my_org.com/files/translations/8.x/my_org/my_org-custom.nb.po.

The last part I would recommend is to only look for translation updates in the local filesystem on your production server, and only manually. This way, Drupal will never try to download new translations on your live site, creating conflicts with your version controlled translations. The setting for this is at  Administration -> Configuration -> Regional and language -> User interface translation -> Interface translation settings, or path admin/config/regional/translate/settings.

You can also do this as part of the settings on the live site, and instead keep this setting on for development sites. To do that in settings.php you would do this:

$config['locale.settings']['translation']['use_source'] = 'local'; Flexible translation methods

However your advanced methods of deployment and translation is, Drupal has a way for you to handle it. And when Drupal out of the box can not support your preferred method of deployment or automation, contributed projects like Custom translation deployments can help you the last steps of the way. The module is fully tested, used in production on many sites, and supports Drupal 9 out of the box!

If you are looking for a partner in developing your localized Drupal site, contact Ny Media!

 

Axelerant Blog: Our implementation of serverless,

Main Drupal Feed - Thu, 06/25/2020 - 12:19
Our implementation of serverless, decoupled Drupal enabled a luxury resort client to consolidate their web properties and serve multilingual content to a worldwide audience.

Axelerant Blog: Choosing the right support vendor is a

Main Drupal Feed - Thu, 06/25/2020 - 12:19
Choosing the right support vendor is a challenging process. Here's how you can tell if your Drupal services provider is right for you.

Axelerant Blog: Drupal 8 developers, making Drupal 8

Main Drupal Feed - Thu, 06/25/2020 - 12:19
Drupal 8 developers, making Drupal 8 PHP 7 ready is one of the best things to happen for us. This is why.

Dries Buytaert: Caring for old software

Main Drupal Feed - Thu, 06/25/2020 - 06:22

Given the impact of COVID-19 on organizations' budgets, we extended Drupal 7's end-of-life date by one year. Drupal 7 will receive security updates until November 2022, instead of November 2021. For more information, see the official announcement.

Extending the lifetime of Drupal 7 felt like the right thing to do. It's aligned with Drupal's goal to build software that is safe for everyone to use.

I wish more software was well-maintained like Drupal is. We released Drupal 7 almost a decade ago and continue to care for it.

We often recognize those who help innovate or introduce new features. But maintaining existing Open Source software also relies on the contributions of individuals and organizations. Today, I'd like us to praise those who maintain and improve Drupal 7. Thank you!

Promet Source: Eight Signs It's Time to Redesign Your Website

Main Drupal Feed - Thu, 06/25/2020 - 00:46
Website redesign decisions often percolate for months, if not years, before action is taken and the team dives in for a do-over. Prior to taking the plunge, there tends to be a lot of low-grade dissatisfaction that gains momentum, as more and more conversations focus all the ways that operations would run smoother, marketing would work better, or all of the tasks that could be offloaded to the website if only navigation was simpler or the site was up to date. 

WPTavern: WordPress Contributors Propose Updating Trac Ticket Resolutions to Be More Friendly

Wordpress Planet - Wed, 06/24/2020 - 23:23

WordPress contributors are currently discussing adopting friendlier terms for some of the trac ticket resolutions to create a more welcoming environment for participants and newcomers. Since trac resolutions are not set in stone, organizations can customize these terms for different workflows.

During a recent core developers chat, Sergey Biryukov proposed that WordPress trac rename “invalid,” “worksforme,” and “wontfix” ticket resolutions to something more friendly and less confusing. The idea was positively received and is now an official proposal.

“More than a few times I’ve seen someone closing a ticket as worksforme after testing a patch because, well, it works for them. When that happens, the ticket has to be reopened with a comment that the patch still needs to be reviewed and committed,” Biryukov said. This particular scenario clearly illustrates how the resolutions can sometimes be confusing for contributors.

Biryukov proposed the following updates:

  • invalid → not-applicable
  • worksforme → not-reproducible or cannot-reproduce
  • wontfix → not-implemented

Others suggested further refinements in the comments of the proposal. Juliette Reinders Folmer noted that ‘not-implemented’ doesn’t seem to capture the full weight of ‘wontfix’ as a decision, because it doesn’t convey anything about the intention.

“The thing which worries me about ‘not implemented’ is that it can be interpreted as an invitation to implement,” Reinders Folmer said. “It doesn’t convey that there is no intention (at this time) to accept an implementation.”

Mika Epstein said they may want to consider having multiple alternatives to ‘wontfix,’ such as not-in-scope, insufficient resources, or better-as-a-plugin.

Peter Wilson suggested the term ‘support-referral’ as an alternative to ‘invalid,’ since many of these tickets are closed due to support requests.

Goodbye, ‘Wontfix’

‘Wontfix’ is a somewhat polite way to say “forget about it” to someone voicing a concern or a suggestion that doesn’t fit with a project’s goals. It is broadly used and understood throughout the industry, and has sometimes been wielded as a gavel to shut down conversation in heated discussions.

The experience of submitting an issue that is closed with the resolution ‘wontfix’ is so visceral that it is often used in a humorous context outside of software development.

That’s a feature, not a bug. #wontfix

— Chase Combs (@sonicbarber) October 25, 2019

For project maintainers who are handing down ticket resolutions as edicts, terms like ‘wontfix’ and ‘worksforme’ have a certain irreplaceable, incisive charm to them. On the other hand, it’s easy to see how these terms might be particularly irksome, especially for new contributors.

Contributors are still brainstorming alternative ticket resolution terms. Anyone with suggestions can jump in on Biryukov’s proposal. As long as WordPress core is still using trac for development, terminology that is clearer and more welcoming may help make the requirement of using trac more friendly in general.

“I know we plan on moving away from Trac at some point, but we’re not there yet, and I think clarifying these resolutions would be helpful in the short term,” Biryukov said.

Some might argue that moving WordPress core development to a platform like GitHub or GitLab would do a great deal more to make it a friendlier contribution experience. Earlier this month, Matt Mullenweg was asked during a virtual Q&A if there has been any progress in moving WordPress development to GitHub.

“No progress there yet, since a lot of the active development has already moved to Github and the Gutenberg plugin, there’s been less pressure on migrating the Trac-based tickets and workflows,” Mullenweg said.

WPTavern: Gutenberg 8.4 Adds Image Editing, Includes Multi-Block Controls, and Enables Block Directory Search

Wordpress Planet - Wed, 06/24/2020 - 21:29

Gutenberg 8.4 landed today with some major user-facing changes, including new image editing tools and the ability to edit options for multiple blocks. The previously experimental block directory search is now enabled for all Gutenberg installations.

Version 8.4 is next to the last major version of Gutenberg planned for integration in WordPress 5.5. The first 5.5 beta is currently on schedule for July 7.

This update includes over three dozen bug fixes, which is several more than typical of a two-week release cycle. It is well worth updating for this alone. It also includes a couple of dozen enhancements, such as support for drag-and-drop in the Social Links block and the ability to transform a Preformatted block into a Code block. Theme authors should enjoy the removal of the canvas padding, which should further improve the ability to match the editor and front end styles.

As usual, this update seems to be an improvement over the previous version. Thus far, I have not run into any regressions in testing.

Upgrade to Get Image Editing Image editing tools in the block editor.

WordPress may be well on its way to replacing one of the extra tools I always use when publishing. For years, I have manually zoomed, cropped, and rotated images in Photoshop, Gimp, or another image editor. I have performed this same action for so long that it feels like a part of the publishing process.

Gutenberg 8.4’s new image editing tools may have me rethinking the need for additional software. The feature allows users to zoom, rotate, or change the aspect ratio for an image directly in the editor.

After selecting an image block, the editor toolbar will display a new crop icon. Once clicked, a range slider will appear below the image in the editor. The slider allows users to zoom in on an image.

After clicking the crop button in the toolbar, two new buttons will also appear. The first button is a simple rotation button, which allows users to rotate the image clockwise, 90 degrees at a time. The second button is for changing the image’s aspect ratio. Once clicked, it will display a dropdown with the following options:

  • Landscape
    – 16:10
    – 16:9
    – 4:3
    – 3:2
  • Portrait
    – 10:16
    – 9:16
    – 3:4
    – 2:3
  • Square

After zooming or changing the aspect ratio, users can also move the image around to change the focal point. The image editor also provides a 3×3 grid for aligning images perfectly, which should be a nice addition for photographers (see rule of thirds).

If nothing else excites you about Gutenberg 8.4, this is the feature you will want to try. The development team put a lot of thought and care behind the user experience.

Customize Multiple Blocks at Once Assigning custom text color to two paragraphs.

Have you ever wanted to change the text color of multiple paragraphs? Perhaps you have needed to enlarge the font size for two blocks or a multitude of other customizations that you have wanted to apply to multiple blocks? Gutenberg 8.4 allows end-users to edit the block options for more than one block at a time. The only limitation is that the blocks must be of the same type, which makes sense because each block type has different options.

The process is simple. Select two or more blocks and customize all of the selected blocks via the block options panel.

In the past, I have gotten around this missing feature on occasion by adding multiple blocks to a Group block and editing its options. The limitation with that method is that the Group block only supports custom text and background colors. It is nice to see the Gutenberg development team tackling this much-needed feature. It will at least allow some of us to do away with such hacks.

Search and Find New Blocks Adding a block via the block directory search feature.

In September 2019, Gutenberg plugin users received their first glimpse of the block directory search. The experimental feature first landed in version 6.5 and promised to revolutionize the block installation process. Users would be able to seamlessly add blocks from the WordPress block directory from the editing screen. No need to save the current post and head over to the plugins screen. Just search, add a block, and continue writing.

Now, nearly 20 major releases later, the feature is no longer experimental. It is a fully-integrated part of the plugin and is expected to land in WordPress 5.5. That means it is time for Gutenberg users to begin heavily testing this feature and reporting any bugs. It also means it is time for plugin developers to step up their game and begin submitting more single-block plugins to the directory.

To use the new feature, users merely need to search for a block via the block inserter. If one is not installed, it will search for the block on WordPress.org. If one is found, Gutenberg will display an “Add Block” button. Once clicked, it will install the block plugin and insert the block into the post editor.

For the most part, it worked reasonably well in my tests. However, it was not without a few faults.

One issue I ran into was that the block plugin’s CSS did not take effect without reloading the page. Thinking this may have been a fluke, I tested again and ran into the same issue. Considering this was the Layout Grid block from Automattic, which needs specific CSS to align columns, the experience was not ideal. My content was not aligned in columns.

I also had the issue of installing a new block but WordPress not recognizing it as available to insert into the editor. When clicking the “Add Block” button a second time in this scenario, I received the “destination folder already exists” message. It was only after refreshing the page that I was able to use the block.

For this feature to land in core, it needs to be a seamless experience. Users should be able to add new blocks and use them on the fly. At least in my tests, this feature was not quite there. Maybe it is my environment. Maybe I just had some bad luck for the day, but it looks like there is still more work to be done before this is a prime-time feature.

HeroPress: Why Expand HeroPress?

Wordpress Planet - Wed, 06/24/2020 - 20:27

The goal of HeroPress is to help. It always was and it always will be.

For the last five years we’ve given what we had to give. Between full time work and raising a family, focusing on elevating other people’s voices was the best route, and the essays continued.

But now — motivated by community interest — we have the opportunity to do more.

We have a unique platform that can be used to create equity in the community. One place to come to find information, meet diverse people groups, and ultimately bridge the various WordPress communities across the world.

To do this, we plan to:

  • Raise access to knowledge by removing economic barriers.
  • Enable global conversations that grow WordPress for the future.
  • Educate us all with the richness and depth that can only come from multi-cultural perspectives and experiences.

The WordPress community is vast and life is busy. In the best of times it is difficult to broaden our relationships to meet the ever growing demands of business, and these are not the best of times.

So, we’re looking to help by bringing the world to you. One url with one purpose meeting a variety of needs.

I have always believed that we have the ability to do amazing things together, and through this expansion we hope to do just that.


Subscribe now to be the first to receive updates!

.mailpoet_hp_email_label{display:none!important;}#mailpoet_form_4 .mailpoet_form { } #mailpoet_form_4 .mailpoet_column_with_background { padding: 10px; } #mailpoet_form_4 .mailpoet_form_column:not(:first-child) { margin-left: 20px; } #mailpoet_form_4 .mailpoet_paragraph { line-height: 20px; margin-bottom: 20px; } #mailpoet_form_4 .mailpoet_segment_label, #mailpoet_form_4 .mailpoet_text_label, #mailpoet_form_4 .mailpoet_textarea_label, #mailpoet_form_4 .mailpoet_select_label, #mailpoet_form_4 .mailpoet_radio_label, #mailpoet_form_4 .mailpoet_checkbox_label, #mailpoet_form_4 .mailpoet_list_label, #mailpoet_form_4 .mailpoet_date_label { display: block; font-weight: normal; } #mailpoet_form_4 .mailpoet_text, #mailpoet_form_4 .mailpoet_textarea, #mailpoet_form_4 .mailpoet_select, #mailpoet_form_4 .mailpoet_date_month, #mailpoet_form_4 .mailpoet_date_day, #mailpoet_form_4 .mailpoet_date_year, #mailpoet_form_4 .mailpoet_date { display: block; } #mailpoet_form_4 .mailpoet_text, #mailpoet_form_4 .mailpoet_textarea { width: 200px; } #mailpoet_form_4 .mailpoet_checkbox { } #mailpoet_form_4 .mailpoet_submit { } #mailpoet_form_4 .mailpoet_divider { } #mailpoet_form_4 .mailpoet_message { } #mailpoet_form_4 .mailpoet_form_loading { width: 30px; text-align: center; line-height: normal; } #mailpoet_form_4 .mailpoet_form_loading > span { width: 5px; height: 5px; background-color: #5b5b5b; }#mailpoet_form_4{border-radius: 0px;text-align: left;}#mailpoet_form_4 form.mailpoet_form {padding: 20px;}#mailpoet_form_4{width: 100%;}#mailpoet_form_4 .mailpoet_paragraph.last {margin-bottom: 0}@media (max-width: 500px) {#mailpoet_form_4 {background-image: none;}} Please leave this field empty

Thanks! Check your inbox or spam folder to confirm your subscription.


The post Why Expand HeroPress? appeared first on HeroPress.

Security public service announcements: Extending Drupal 7's End-of-Life - PSA-2020-06-24

Main Drupal Feed - Wed, 06/24/2020 - 19:41
Date: 2020-June-24Description: 

Previously, Drupal 7's end-of-life was scheduled for November 2021. Given the impact of COVID-19 on budgets and businesses, we will be extending the end of life until November 28, 2022. The Drupal Security Team will continue to follow the Security Team processes for Drupal 7 core and contributed projects.

However, this means extra work from the Drupal community at large and the security team in particular to review security reports, create patches, and release security advisories for Drupal 7. This community effort will give site owners more time while budgets recover, but the organizations that sponsor security team members and the individual security team members who volunteer their time could use your support. If you can, please donate to support the end-of-life extension.

Drupal 8 will still be end-of-life on November 2, 2021, due to Symfony 3's end of life. However, since the upgrade path from Drupal 8 to Drupal 9 is much easier, we don't anticipate the same impact on end-users.

What does this mean for my Drupal 7 site?

You can continue to run the site and get security updates via the normal channels and processes. This will give you an extra year to work on converting your site to Drupal 9.

Do I need to upgrade to Drupal 8 before I upgrade to Drupal 9?

Migrating directly from Drupal 7 to Drupal 9 is supported with the core Migrate module. Read more on preparing a Drupal 7 site for Drupal 9.

How can I help?

Consider donating to support this effort. If you are a representative of a large end-user of Drupal, we'd love you to join the Drupal Association and the security team as a partner.

You can also consider getting more involved in fixing issues in the issue queue or joining the Security Team as a way to support the effort.

What about Drupal 7 Vendor Extended Support?

The extended support will now run from November 2022 until November 2025. You can read more about the Drupal 7 Vendor Extended Support program.

What about contributed projects?

The Security Team will continue to follow the Security Team processes for contributed projects. Contributed project maintainers are asked to consider supporting existing Drupal 7 releases if they are able.

Matt Glaman: Trying out issue forks on Drupal.org!

Main Drupal Feed - Wed, 06/24/2020 - 19:35

Have you heard that now has issue forks for Git-based contribution versus patches? This means we can now work in a pull-request style workflow on Drupal.org issues. It's an opt-in beta, and I have not had a chance to work with the feature yet. 

Drupal In the News: Drupal Featured on Stack Overflow: Why now is the time to give Drupal another look

Main Drupal Feed - Wed, 06/24/2020 - 18:14

The content management ecosystem at large and Drupal in particular have evolved tremendously over the last 20 years, and many developers who haven't engaged with the CMS market in a while may have an outdated conception of what a CMS can do. With Drupal 9's release at the cutting edge of the CMS world, now is a better time than ever to reintroduce developers at large to what Drupal can accomplish.

Stack Overflow recently invited Drupal Association CTO Tim Lehnen to write about the evolution of the CMS marketplace, and what Drupal has to offer:

For many people discussion of content management systems raises unpleasant specters of the early 2000s. But while CMS platforms may not feel like the shiniest new tech on the block, they still have a lot to offer, and they've evolved in ways that might surprise you. Let's talk about Drupal, a 20 year old open source project that still manages to be on the leading edge of the CMS world.
The Overflow

Read the article

Pages