All RPGs and Storygames by Tod Foley are now available at DrivethruRPG. Bring these games to your table!
Sometimes, you would want to restrict access to certain pages on your site to users who do not have a specific role. You would want users to upgrade to a paid plan. Or you would just want to collect some more information from them.
The Rabbit Hole module controls what should happen when a user clicks the link to the entity or enters a URL in the address bar. It redirects such users to another page in the site.
The Rabbit Hole module works with different types of entities. They could be nodes, users, taxonomy terms and files, to name a few.
This tutorial will explain the basic usage of this module. Let’s start!
At Microserve we're always ambitious about the solutions that we design and develop from scratch, but we're also conscious that there's no point in 'reinventing the wheel' when perfectly good solutions already exist. Our clients usually have third-party systems that they rely on for all kinds of business-critical services like CRM, marketing automation, authentication, recruitment and lots more. It's our job as technical architects to understand where those systems end and where the system that we’re developing begins. Crucially, we need to plan how data flows between those systems to get them working seamlessly together. In other words: how to integrate the systems.
Palantir is excited to return to Denver as a sponsor for DrupalCamp Colorado 2019, featuring a keynote from our CEO, Tiffany Farriss. Tiffany will be discussing the role of organizational culture and open source projects like Drupal in the success of tech companies. We hope to see you there!
- Location: TBD
- Date: August 3rd, 2019
- Time: 9 AM - 10 AM MDT
The Drupal community maintains its own evergreen coding standards that differ from those of the broader PHP community (e.g., PSR-2). It's encouraged to pore through the standards line-by-line and memorize each for perfect real-time compliance, but for those with better things to do, fear not! The standards will come to you.
In Drupal 8.7.4, when the experimental Workspaces module is enabled, an access bypass condition is created.
This can be mitigated by disabling the Workspaces module. It does not affect any release other than Drupal 8.7.4.
Drupal 8.7.3 and earlier, Drupal 8.6.x and earlier, and Drupal 7.x are not affected.Solution:
If the site is running Drupal 8.7.4, upgrade to Drupal 8.7.5.
Note, manual step needed. For sites with the Workspaces module enabled, update.php needs to run to ensure a required cache clear. If there is a reverse proxy cache or content delivery network (e.g. Varnish, CloudFlare) it is also advisable to clear these as well.Reported By:
The Embedded Google Docs Field allows the site administrator to change the display of normal file fields, making them viewable directly on the node with the help of the Google Docs Viewer.
This tutorial will explain the usage of this module through an example.
Hint: Google has to be able to locate your site on the web, in order to embed the viewer. This module will not work in a local environment.
What is the latest business forecast for the media and publishing industry? The thunder and lightning of success! This is because Drupal has very useful web solutions for this industry.
In addition to easy content editing in Drupal 8 and other niceties, there are Drupal distributions for media and publishing. They are called Thunder and Lightning, and we will now discuss what they can give you.
The Migrate Drupal UI module provides a web browser user interface for upgrading from Drupal 6 / 7 to Drupal 8. There is a pre-upgrade analysis which displays a list of legacy modules that will be upgraded and will not be upgraded. Included in those that will be upgraded are modules that do not need an upgrade, such as the Help module. In order for this analysis to be correct, some Drupal 8 modules must provide information in a MODULE_NAME.migrate_drupal.yml file in the module's migrations/state directory.heykarthikwithu Wednesday, 17 July 2019 - 17:06:08 IST
The Apigee Dev Portal does not support SOAP/WSDL (Simple Object Access Protocol/Web Service Definition Language) documentation by design. However, Apigee is seeing a number of prospects and customers who have legacy SOAP APIs that they want to onboard onto Apigee Edge quickly. Apigee’s current strategy is to put a REST (Representational State Transfer) facade in front of a SOAP backend as an interim solution. This way customers can take advantage of the out-of-the-box analytics as part of their rationalization exercise to improve and build new RESTful APIs. However, these enterprise clients want to display WSDL documentation in addition to RESTful API documentation.
Shape the exciting lineup of community-driven, educational sessions by serving on the Program Committee!
Our normally scheduled call to chat about all things Drupal and nonprofits will happen this Thursday, July 18, at 1pm ET / 10am PT. (Convert to your local time zone.)
Feel free to share your thoughts and discussion points ahead of time in our collaborative Google doc: https://nten.org/drupal/notes
Already on the agenda: A discussion of announced changes to 20NTC, which specifically impact the community driven sessions our great group of volunteers organized last year.
We have an hour to chat so bring your best Drupal topics and let's do this thing!
Some examples to get your mind firing: how do I recreate [feature] on my Drupal 7 site in Drupal 8? I need to explain [complicated thing] to a non-technical stakeholder -- any advice? How can I get Drupal and my CRM to play nicely?
This free call is sponsored by NTEN.org but open to everyone.
- Join the call: https://www.uberconference.com/ntencommunity
- Optional dial in number: (866) 853-1888
- Alternate number: (720) 689-1432
- Follow along on Google Docs: https://nten.org/drupal/notes
- Follow along on Twitter: #npdrupal
Despite Drupal 8 (D8) being launched back in 2015 and Drupal 9’s release date looming; there are almost a million websites on the internet still running on Drupal 7 (D7). However; many of the website owners justify their reasoning for sticking with Drupal 7 until now to the long update to Drupal 8 process and the budget required.
So... should you upgrade your website to Drupal 8 now? That really depends on your business needs… however; since you decided to build your website using Drupal, I assume you already know the unique advantages that Drupal brings to your brand’s digital experience.
We take a look at a few logical reasons to upgrade your website to Drupal 8 sooner rather than later:
1. D7 End-Of-Life (EOL) Is Around the Corner
Both Drupal 7 and Drupal 8 versions will continue to receive support and fixes from the community until November 2021, a whole year after the release of Drupal 9 in 2020. Beyond that EOL date; D7 and D8 will no longer receive any support. What does that mean?
The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7. There will be no more core commits to Drupal 7. The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules, themes, or other projects. Reports about Drupal 7 vulnerabilities might become public creating 0 day exploits. All Drupal 7 releases on all project pages will be flagged as not supported. Maintainers can change that flag if they desire to. On Drupal 7 sites with the update status module, Drupal Core will show up as unsupported.
After November 2021, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support. If you have a site that is running on Drupal 7, now is the time to start planning the upgrade. You don’t want to be making that decision with only a couple of months to the EOL date remaining.
If you still plan to stick to Drupal 7; you can engage the services of specific vendors who will be announced at a later date as officially recognized members of the Drupal 7 Vendor Extended Support program (D7ES).
Or, you could save money and time by upgrading now and gain the significantly richer benefits of Drupal 8. I strongly recommend this approach. Win-Win.
2. Power Your Digital Business
This one is logical. If you think you’d be saving money and time by jumping directly to Drupal 9 from Drupal 7, think again.
You are already missing out on Drupal 8’s awesome features. Drupal 8 was built with a focus on creating engaging user experiences. Website performance is at the core of all improvements, updates, and modules being created for Drupal 8. One of the first significant improvements introduced was Facebook’s BigPipe, which is now a built-in stable module in Drupal core.
Major brands that are running websites on Drupal 8 can give their site visitors the mobile-first, search engine optimized and secure user experience they crave. Businesses that cater to a global audience are reaping the benefits of the multilingual and translation tools built-in Drupal 8’s CMS.
Additionally, Drupal 8 replaced PHPtemplate with a new, faster, simpler and much more secure theming engine, Twig. Though Twig is PHP-based, all that front end developers need to create beautiful websites is their skill in HTML/CSS. They don’t need to boast much PHP experience or expertise anymore.
The aforementioned are but a sample of highlighted features. Think of all the modules that have been improved and enhanced to build a digital experience that engages your base better than ever. Are you willing to be behind the pack until you decide I need to upgrade closer to the Drupal 7’s EOL date?
3. Smooth Migration to D9
Migrating your website from Drupal 6 to 7 demanded an entire rebuild. It’s true that migrating from Drupal 7 to 8 would be a major hassle as well, however, this would be the last major rebuild you will ever have to make again thanks to Semantic Versioning.
Drupal 9 is built on-top of Drupal 8. Hence, the transition when migrating from Drupal 8 to 9 will be seamless and effortless, especially when you compare the hassle of migrating between other major versions.
“The first release of Drupal 9 will be very similar to the last minor release of Drupal 8, as the primary goal of the Drupal 9.0.0 release will be to remove deprecated code and update third-party dependencies. By keeping your Drupal 8 sites up to date, you should be well prepared for Drupal 9.” - Dries Buytaert, Drupal Project Lead
If you are still reluctant to rebuild your website in order to benefit from the sample of highlighted Drupal 8 features we mentioned earlier; consider Varbase.
Varbase is an enhanced Drupal distribution packed with adaptive functionalities and essential modules, that speed up your development, and provides you with standardized configurations, making your life easier. The essence of Varbase, lies within the basic concept that initiated it; DRY (Don’t Repeat Yourself). Varbase handles that for you, relieving you from repeating all the modules, features, configurations that are included in every Drupal project.
You can build a beast of a digital experience that caters for a global and diverse audience, search engine optimized and mobile-first; whilst saving over 200 development hours.
The time to prepare for your business’ digital future is now. Adopting a neutral stance is only going to be a waste of time, traction and money. Choosing to upgrade to Drupal 8 right now means that you have already upgraded to Drupal 9.
Drupal’s focus on engaging digital experiences reflects the actual shift in user behavior in real life. That is the main reason why global brands and many industries such as the entertainment industry, higher education, healthcare, and even public sectors are adopting Drupal… and Drupal 8’s features offer your digital business more than you can begin to imagine. Our award-winning team can help you build a digitally thriving business in the future by guiding you through the upgrade process.
Contact us now and get a thorough complimentary performance audit of your website!
How did the City of Sandy Springs, GA improve information system efficiency with a unified platform? Join our webinar to see how we built this city on decoupled Drupal 8, GatsbyJS, and Netlify.
We'll explore how a “build-your-own” software approach gives Sandy Springs the formula for faster site speed and the ability to publish messages across multiple content channels — including new digital signage.What You'll Learn
The City of Sandy Springs’ challenges and goals before adopting Drupal 8
How Sandy Springs manages multi channel publishing across the website, social media, and a network of digital signage devices.
- Benefits gained from Drupal 8 and GatsbyJS, including: a fast, reliable site, hosting costs, and ease of development for their team.
Jason Green, Visual Communications Manager at City of Sandy Springs, and Mediacurrent Director of Front End Development Zack Hawkins share an inside look at the project.Registration
Follow the City of Sandy Springs on the path to government digital innovation. Save your seat today!
When sending email from your application, using queuing process can reduce the application response time and increase speed.
By sending the message to queue instead of sending directly at the end of server response, you may achieve better user experience. Once messages are in queue, you just need a scheduled cron task to initiate scheduled email sending.How ?
Queuing is simple in Drupal 8
DrupalEasy: Demystifying drupal-core-require-dev and drupal-core-strict in the "Drupal Composer/Drupal Project" Composer template
If you build Drupal 8 sites using the Drupal Composer/Drupal Project Composer template (DCDP), then you've likely noticed the development dependency webflo/drupal-core-require-dev. If you're like me, you probably didn't give it much thought the first 20 or 30 times you used the template.
After a while though, I started to dig deeper into the details of DCDP, wanting to be able to understand exactly how it worked and what customizations I may want to make. DCDP was really my first real exposure to Composer, and the more I learned, the more I wanted to learn (as is often the case). My curiosity led me to this drupal-core-require-dev rabbit hole.Some background
First, let's level-set ourselves - when you run either "composer install" or "composer create-project" (which is actually calling "composer install" as well) without the "--no-dev" switch, Composer will install all dependencies listed in your composer.json file in both the "require" and "require-dev" sections (as well as dependencies of dependencies). If you take a look at DCDP, you'll notice that in the "require-dev" section, there is one entry: webflo/drupal-core-require-dev.
So, as most folks who start Drupal 8 projects using the recommended DCDP command listed in the README (composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction), Composer is installing everything in the "require" and "require-dev" sections - including webflo/drupal-core-require-dev.
What exactly is webflo/drupal-core-require-dev? Well, it is a "virtual" dependency - meaning it doesn't include any code, rather it just includes a composer.json file that specifies the specific versions of Drupal core development ("require-dev") dependencies that are used to run Drupal core tests. The interesting (and sometimes problematic bit) is that webflo/drupal-core-require-dev doesn't specify any versions for non-development ("require") dependencies. If you take a look at Drupal core's composer.json file, you'll see that for the most part, specific versions of dependencies aren't specified - rather a range is.
This leads to the situation where a project built with webflo/drupal-core-require-dev could have different dependency versions (as long as they adhere to the version constraints is Drupal core's composer.json) than what comes with Drupal core if you had just downloaded it from drupal.org.
For example, if on the date version 8.7.0 of Drupal core was released one of the development dependencies was at version 1.3.1, then that is the version that is provided with Drupal core 8.7.0 downloaded from drupal.org regardless of when you download it. But, when using the DCDP as-is, if since the release of Drupal core 8.7.0 the development dependency was updated to 1.3.2, then when the project is installed using "composer create-project", your project will be using version 1.3.2 of the dependency. While this seems minor, it has led to some issues.
Also - be aware that there are different versions of webflo/drupal-core-require-dev for every minor version of Drupal core. So, if you're updating your site from Drupal core 8.6.x to 8.7.x, then you must also update to webflo/drupal-core-require-dev to 8.7 as well. This is the reason the update command for DCDP includes webflo/drupal-core-require-strict: composer update drupal/core webflo/drupal-core-require-dev "symfony/*" --with-dependencies
After learning this, I had an obvious question: what's the advantage of having Composer install updated versions of Drupal core dependencies? The only thing I found was that if you're a core or contrib developer, then it would be useful to know if your code breaks using updated dependencies. I'm hard-pressed to think of another reason when this makes sense. For most Drupal 8 projects, I think it would be beneficial to use the exact dependencies that the particular version of Drupal core ships with. This way, we can be 100% certain that our project has the same dependency versions that the community's testing infrastructure has validated for the particular version. Luckily, that's what webflo/drupal-core-strict is for.
It works almost the exact same way as webflo/drupal-core-require-dev except that it includes exact versions for all dependencies of Drupal core - for both development ("require-dev") and non-development ("require") packages. The exact versions are the ones that have been tested and are included in the "official" version of Drupal core (for each minor version) downloadable from drupal.org. Like webflo/drupal-core-require-dev, there is a minor version of webflo/drupal-core-strict for each minor version of Drupal core.
So, why does DCDP use webflo/drupal-core-require-dev? Well, there's some debate about if it should or not.
As a side-note, if you host on Pantheon, and use their Pantheon-flavored version of DCDP, then you're probably already using webflo/drupal-core-strict.Starting a project with DCDP using webflo/drupal-core-strict
First, the bad news - if you want to start a new project using webflo/drupal-core-strict, you can't use DCDP out-of-the-(virtual)-box. But, there's a couple of possibilities. At first glance, it seems that you could fork DCDP, make the relevant change to webflo/drupal-core-strict in the composer.json file, then use "composer create-project" on your fork. But, this would also require posting your fork on Packagist (which is discouraged), updating your fork's README (for the create-project and update commands) as well as keeping your fork up-to-date with any DCDP updates. I wouldn't recommend this method.
A better option is to use the "--no-install" option of Composer's "create-project" command:
1. Use the recommended command on the DCDP page, but add a "--no-install" at the end of it:composer create-project drupal-composer/drupal-project:8.x-dev some-dir --no-interaction --no-install
This will download DCDP to your local, but not install dependencies.
2. Edit the composer.json file with:
- New project name
- New project description
- Remove "webflo/drupal-core-require-dev" from the "require-dev" section
- Add "webflo/drupal-core-strict": "^8.7.0", to the "require" section (ensure the version matches drupal/core).
- Change the version requirement for drupal/console to: "drupal/console": "^1.0", (to avoid version conflicts)
- Change the version requirement for drush/drush to: "drush/drush": "^9.0", (to avoid version conflicts)
- Remove "composer/installers" from the "require" section (it is already specified in webflo/drupal-core-strict).
3. Run "composer install".
You'll need to remember that when you want to update Drupal core, you'll want to use the following command (instead of what is in the DCDP README):composer update drupal/core webflo/drupal-core-strict "symfony/*" --with-dependencies
If you're not crazy about either of these two options, there is a third (future?) - leave a comment on this issue and ask for webflo/drupal-core-strict to be used in DCDP.Change an existing project from webflo/drupal-core-require-dev to webflo/drupal-core-strict
What if you already have a project based on DCDP and you want to change it from using webflo/drupal-core-require-dev to webflo/drupal-core-strict? Here's some possible ways of doing it:
As always, to be safe, please test things like this on a copy of your project.Method one: manually downgrade dependencies
This is definitely a tedious process. It involves first removing webflo/drupal-core-require-dev using:composer remove webflo/drupal-core-require-dev
Then, attempt to require drupal-core-strict:composer require webflo/drupal-core-strict:^8.7.0
Depending on a number of factors you're likely to get a bunch of "Your requirements could not be resolved to an installable set of packages." messages. How many you get is mostly a result of the length of time since the previous minor release of Drupal core - the longer it has been, the more dependencies have probably been updated. For each dependency listed, you'll need to downgrade it using something like:composer require symfony/yaml:3.4.26
What is happening is that webflo/drupal-core-require-dev allows dependencies to get upgraded outside of the Drupal core release timeline, while webflo/drupal-core-strict does not. So, you'll need to downgrade dependencies that have been updated. You'll have to do it one-at-a-time - try requiring webflo/drupal-core-strict, see the error message, downgrade the offending dependency, then repeat. In some cases, it isn't immediately obvious which dependency needs to be downgraded, or which version it needs to be downgraded to, so be prepared to use the "composer depends" command a few times.
Eventually, requiring webflo/drupal-core-strict will succeed and you'll know that you're done.
There is one major downside to this method though - by requiring specific versions of each dependency, the versions are effectively pinned in the composer.json file. So, the next time you update Drupal core (and webflo/drupal-core-strict), these specific version constraints will conflict with the updated webflo/drupal-core-strict. One solution would be to remove all of these dependencies from the "require" section of your composer.json file.Method two: rebuilding your codebase
If Method one is tedious and precise, then this method is more of a (less tedious) big hammer. Depending on the complexity of your codebase, this might be a better option for simpler projects. In short, make a copy of your composer.json (for reference), then use "composer remove" to remove dependencies on drupal/core, webflo/drupal-core-require-dev, and anything that depends on them. Then, use "composer require" to add back drupal/core and webflo/drupal-core-strict:composer require webflo/drupal-core-strict:^8.7.0 drupal/core:^8.7.0
Then, add back (composer require) all the dependencies you had to remove. Be sure to add back the same versions of each dependency (this includes Drupal profiles, modules, and themes!) to end up where you were when you started. Once everything is back, then you'll probably want to "relax" the version constraints of your dependencies in your composer.json by adding a "^". For example, if you re-add a contrib module using:composer require drupal/pathauto:8.1.3
Then in the "require section" of your composer.json you'll have:"drupal/pathauto": "8.1.3",
This will prevent drupal/pathauto from being updated. So, you'll want to change this to:"drupal/pathauto": "^8.1.3", Method three: delete and update
[One] solution is to modify your composer.json file, attach the same version limit to drupal/core and drupal-core-strict (e.g. ^8.7.3) to limit what [composer update] needs to look at, and then [delete] both your composer.lock and your vendor directory and run "composer update".
One caveat about this method is that it will update everything. Any outstanding dependency updates (including Drupal profiles, modules, and themes) will be applied (unless you constrain them in your composer.json). Here's what Greg suggests:
- Pin your contrib modules that are not updated to an exact version in composer.json.
- Remove vendor and composer.lock, add webflo/drupal-core-strict [to your composer.json], and generate a new lock file [with "composer update"].
- Remove the pins of your contrib modules in your composer.json by adding ^ [similar to the example in the previous method.]
- Run composer update --lock
Is there an easier way to do this? If so, I'd love to hear about it. Let me know in a comment below.Which to use?
So which one should you use? If all your contrib projects are up-to-date, then I'd go with Method 3. If not, then I'd recommend Method 2 or 3 depending on which you're more comfortable with.The future
Of course, in the future, much of this may be moot (for new projects, at least), as there is an active effort to bring an official version of DCDP to Drupal, including a new scaffolding dependency (committed to drupal/core on July 10, 2019!) and something akin to drupal-core-require-dev and drupal-core-strict. To find out more, check out the Composer Support in Core Initiative.
Thanks to Greg Anderson, one of the Composer in Core Initiative coordinators, for his input and review of this article.