Despite the hectic holiday season, we never stop researching and digging up interesting Drupal content. Our team has once again scoured all the feeds, read countless Drupal articles and made the selection of the most engaging bits of content from last month. So, without further ado, here are what we found to be the top Drupal blog posts from December 2018.
Automate actions on your Drupal-based website. This will enable it to run even more independently from your input.
Automated mailing, publishing new content at a specified time and redirects after meeting certain conditions are only some of the functionalities featured in the Rules module.
Rules is a tool that enables you to define automatic, conditionally executed actions, triggered by various types of events.
What are some examples of such automated actions? For example:
redirecting the user after logging in;
sending an e-mail after adding content;
publishing content at a specific time.
At the foundation of the module lies the Event – Condition – Action rule, with one caveat – the CONDITION does not have to be a part of this scheme.
An example scheme could be as follows:
Thu, 01/10/2019 – 17:49
Website owners are often trapped inside an imaginary bubble where they make conclusions like “There are more valuable sites in the web world, why would mine be targeted by the hackers?”
And Alas the bubble is busted when they observe that hackers have attacked their site because let’s face it- they would never discriminate between any choice they are getting. They want a website to attack, and they have it.
For opensource CMS like Drupal, WordPress, and Joomla, the scenario is the same. As popular as these platforms are, they are the targets of all sorts of attacks. Cybercriminals discover the security loopholes and hack your website in no time.
Which leaves us with the assumption that these platforms ( which together conquer 68.5% of the CMS market) must be providing some form of protection.
And yes, the assumptions are true.
Birth of SIWECOS
SIWECOS project or the “Secure Websites and Content Management Systems” project is the security project which is funded by the German ministry of Economics that desires to improve the security of the CMS based websites ( which of course includes Drupal, WordPress, Joomla, and many others)
The project was designed to help small and medium-sized enterprises (SMEs) identify and correct the security loopholes that they witness on their websites. It focused on concrete recommendations of action in the event of damage and also taking care of sensitizing SMEs to cybersecurity.
The utilization of the vulnerability scanner in the project helped SMEs to regularly check the server system and made them acquaint well with the vulnerability that might occur in a web application. Not only this but a service for web hosts were also presented which actively communicated with acute security vulnerabilities and offered filtering capabilities to prevent cyber attacks.
The end users were also protected with potential data losses as well as financial losses.
The aim of SIWECOS in longer run was to increase web security and raise a proper awareness of the relevance of IT security for SMEs. Thus, Initiative-S came out as a ray of hope for the support of the small and medium-sized enterprise. It was a government-funded project which was built by the initiative, the association of the German internet industry echo.
The association built a web interface called “clamavi”. This was done for the users to grant them with the ability to enter their domain and conduct a malware scan of the source code once per day. Thus the website check of Initiative-S was integrated into the new project of SIWECOS. The proven Initiative-S technology now supplements the portfolio of the new SIWECOS service with a check for possible malware infestation.
Importance of the Project
As mentioned, the whole project revolved around the security of the CMS platform, Since the time it was started, the project took 2 years to complete. The mission was to introduce the end users with:
- Importance of security in cooperation and provided the end users with individual notifications and recommendation on security issue of a website.
- Increase in web security for a longer period and to identify and address security vulnerabilities of their website.
- The project helped ordinary users patch more quickly. Patching is the application of updates (patches) to existing code that either increase the functionality or correct patch vulnerabilities.
- It also scanned registered user websites. If any security vulnerabilities were found then the person in the field of IT security was contacted directly.
What does SIWECOS have in General?
SIWECOS, in general, had three things
It is the detailed version of the introduction and the process on how to subscribe it. They reached out to the end users that not only included the site owners but also the ones that have to maintain it later. The major purpose of the awareness campaign was to influence the behavior of the users since improvements cannot take place without changes in their attitudes and perceptions.
The whole scanning system in Skinning Service is based on an API which is an open source that is embedded inside. It gave the end users with score count between zero and hundred to give them an idea on how secure or insecure the setup is.
Behind the score, there were five scanners which were used to check malware in the HTML code. Scanners like:
- HTTP Header Scanner
Ensures that your server conveys the browser to enable security features.
- Info leak Scanner
Verifies if the site exposes security-relevant information.
- TLS scanner
Checks the HTTPs encryption for known issues, outdated certificates, chain of trust etc
- Initiative S Scanner
This scanner checks the website for viruses or looks for third-party content such as phishing.
- DOMXSS Scanner
This scanner verifies that the website is protected against DOMXSS attacks.
The companies that power the service behind the website are likely to be called as web hosts. Web hosts team generally should have all the basic technical knowledge, security awareness and should have an active communication of filter rules to defend against attacks.
The need for Filter rules – to limit the circle of recipients.
Firewall rules made it easy for experienced attackers to build and exploit the website as they want. Thus, by filtering incoming and outgoing network traffic (based on the set of user-defined rules) there was a reduction in unwanted network communication.
Another reason to use web host was server-side protection. The server- side was protected against all these attacks on the web pages that were installed in the web hoster. This was done to protect web page operators.
Partner in the Project
SIWECOS project included four partners mainly that contributed highly to the project. The four partners were:
Eco or electronic commerce is the largest association of the internet industry in Europe. The association sees itself as the representation of the interests of the internet economy and has set itself with the goal of promoting technologies, shaping framework conditions and representing the interests of its members. The Eco group includes all the internet industry and promotes current and future internet topics.
The awareness building section was mainly done by eco association because of the fact that they were really good at marketing and networking.
The Ruhr-University Bochum, located on the southern hills of central Ruhr area Bochum, is one of the partners in the whole project. It has one of the greatest and most proven track records in the general IT security industry. They were included in the project with the agenda of building a scanning engine that gave the business owners feedback about potential security problems on their site such as SSL misconfiguration or vulnerability to cross-site scripting attacks.
Hackmanit GmbH was founded by IT security experts that were from Ruhr University Bochum. They have an international publication of XML security, SSL/TLS, single sign-on, cross-site scripting, and UI redressing. The priorities of the company were designed by high-quality penetration testing, hands-on training, and tailor-made expertise. The organization has in-depth knowledge about the security of web application, web services, and applied cryptography. The team offers a white box and black box tests which protects the application from the effects of all sorts of hackers attack.
The CMS garden is the umbrella organization of the most relevant and active open source content management system. In other words, the security team started with CMS planning in 2013 by making a shoutout to the CMS community to join the team. Surprisingly, there were CMS platforms which were interested. Thus, by 2013, there were 12 open source CMS systems in one place.
CMS garden also contributes to a series of plugins for different open source CMSes that provides feedbacks from within the CMS management interface so that the site owners have the ability to act immediately when they encounter with any security vulnerability.
In the End
Website attacks and cyber attacks are rapidly growing. These attacks cost the organizations millions of dollars, subject them to the lawsuit and ruin their lives.
SIWECOS is like a shield for all the websites and the CMS platforms, it protects them against cyber attacks and hackers of all sort, helping in keeping up with the security and protection against vulnerabilities.
We know how important web security is to protect your online identity and personal information. If you’re concerned about your web security for your business, or other network issues, our services can help. Contact us on firstname.lastname@example.org the professionals would guide you with all your queries and questions and help you leverage security for your website.
Thu, 01/10/2019 – 08:41
Drupal Mountain Camp brings together experts and newcomers in web development to share their knowledge in creating interactive websites using Drupal and related web technologies. We are committed to unite a diverse crowd from different disciplines such as developers, designers, project managers as well as agency and community leaders.
The future of Drupal communities
For the first keynote, Drupal community leaders such as Nick Veenhof and Imre Gmelig Meijling will discuss about successful models to create sustainable open source communities and how we can improve collaboration in the future to ensure even more success for the open web. This keynote panel talk will be moderated by Rachel Lawson.
In sessions, we will share the latest and greatest in Drupal web development as well learn from real world implementation case studies. Workshops will enable you to grow your web development skills in a hands-on setting. Sprints will teach you how contributing to Drupal can teach you a lot while improving the system for everyone.
Swiss Splash Awards
As a highlight, the Swiss Splash Awards will determine the best Swiss Drupal web projects selected by an independent jury in 9 different categories. These projects will also participate in the global Splash Awards at DrupalCon Europe 2019.
Drupal Mountain Camp takes place at Davos Congress. As tested by various other prominent conferences and by ourselves in 2017, this venue ensures providing a great space for meeting each other. We are glad to be able to offer conference attendees high quality equipment and flawless internet access all in an inspiring setting. Davos is located high up in the Swiss alps, reachable from Zurich airport within a beautiful 2 hours train ride up the mountains.
The Drupal Mountain Camp is all about creating a unique experience, so prepare for some social fun activities. We’ll make sure you can test the slopes by ski and snowboard or join us for the evening activities available to any skill level such as sledding or ice skating.
Drupal Mountain Camp is committed to be a non-profit event with early bird tickets available for just CHF 80,- covering the 3 day conference including food for attendees. This wouldn’t be possible without the generous support of our sponsors. Packages are still available, the following are already confirmed: Gold Sponsors: MD Systems, platform.sh, Amazee Labs. Silver: soul.media, Gridonic, Hostpoint AG, Wondrous, Happy Coding, Previon+. Hosting partner: amazee.io.
Early bird tickets for CHF 80,- are available until Monday January 14th, 2019
Call for sessions and workshops is open until January 21st, 2019
Selected program is announced on January 28th, 2019
Splash Award submissions is open until February 4th, 2019
Regular tickets for CHF 120,- end on February 28th, 2019 after that late bird tickets cost CHF 140,-
Drupal Mountain Camp takes place in Davos Switzerland from March 7-10th, 2019
Join us in Davos!
Visit https://drupalmountaincamp.ch or check our promotion slides to find out more about the conference, secure your ticket and join us to create a unique Drupal Mountain Camp 2019 – Open Source on top of the World in Davos, Switzerland March 7-10th, 2019.
Drupal Mountain Camp is brought to you by Drupal Events, the Swiss Drupal Association formed striving to promote and cultivate the Drupal in Switzerland.
This blog has been re-posted and edited with permission from Dries Buytaert’s blog.
Last year, I talked to nearly one hundred Drupal agency owners to understand what is preventing them from selling Drupal. One of the most common responses raised is that Drupal’s administration UI looks outdated.
This critique is not wrong. Drupal’s current administration UI was originally designed almost ten years ago when we were working on Drupal 7. In the last ten years, the world did not stand still; design trends changed, user interfaces became more dynamic and end-user expectations have changed with that.
To be fair, Drupal’s administration UI has received numerous improvements in the past ten years; Drupal 8 shipped with a new toolbar, an updated content creation experience, more WYSIWYG functionality, and even some design updates.
A comparison of the Drupal 7 and Drupal 8 content creation screen to highlight some of the improvements in Drupal 8.
While we made important improvements between Drupal 7 and Drupal 8, the feedback from the Drupal agency owners doesn’t lie: we have not done enough to keep Drupal’s administration UI modern and up-to-date.
This is something we need to address.
We are introducing a new design system that defines a complete set of principles, patterns, and tools for updating Drupal’s administration UI.
The content administration screen with the new design system.
As you can see on Drupal.org, community feedback on the proposal is overwhelmingly positive with comments like Wow! Such an improvement! and Well done! High contrast and modern look..
Sample space sizing guidelines from the new design system.
I also ran the new design system by a few people who spend their days selling Drupal and they described it as “clean” with “good use of space” and a design they would be confident showing to prospective customers.
Whether you are a Drupal end-user, or in the business of selling Drupal, I recommend you check out the new design system and provide your feedback on Drupal.org.
Special thanks to Cristina Chumillas, Sascha Eggenberger, Roy Scholten, Archita Arora, Dennis Cohn, Ricardo Marcelino, Balazs Kantor, Lewis Nyman,and Antonella Severo for all the work on the new design system so far!
We have started implementing the new design system as a contributed theme with the name Claro. We are aiming to release a beta version for testing in the spring of 2019 and to include it in Drupal core as an experimental theme by Drupal 8.8.0 in December 2019. With more help, we might be able to get it done faster.
Throughout the development of the refreshed administration theme, we will run usability studies to ensure that the new theme indeed is an improvement over the current experience, and we can iteratively improve it along the way.
Acquia has committed to being an early adopter of the theme through the Acquia Lightning distribution, broadening the potential base of projects that can test and provide feedback on the refresh. Hopefully other organizations and projects will do the same.
How can I help?
Wed, 01/09/2019 – 18:24
Drupal 9 is coming. Even if it feels like you only just upgraded to Drupal 8, soon it’ll be time to make the switch to the next version. Fortunately, the shift from Drupal 8 to Drupal 9 should be relatively painless for most organizations. Here’s why.
A little background
Though tools were built in to make the upgrade from Drupal 6 or 7 to Drupal 8 run as smoothly as possible, it could still be a difficult or dramatic process. Drupal 8 marked a major shift for the Drupal world: it introduced major new dependencies, such as Symfony, and a host of new features in Core. The new structure of the software made it tricky to upgrade sites in the first place, which was complicated by the fact that it took a long time for a number of modules to be properly optimized and secured for the new version.
Drupal 9: A natural extension of Drupal 8
Fortunately, the large number of changes made to the Drupal platform in Drupal 8 have made it relatively simple to build, expand, and upgrade for the future. The new software has been designed specifically to make it simple to transition between Drupal 8 and Drupal 9, so that making the migration requires little more work than upgrading between minor version of Drupal 8.
In fact, as Dries Buytaert (the founder and project lead of Drupal) wrote recently in a blog on Drupal.org:
Instead of working on Drupal 9 in a separate codebase, we are building Drupal 9 in Drupal 8. This means that we are adding new functionality as backwards-compatible code and experimental features. Once the code becomes stable, we deprecate any old functionality.
Planning for Drupal 9
As more information is released about the new features and updates in Drupal 9, organizations should consider their digital roadmaps and how the new platform will affect them. And regardless of what your plans are feature-wise, your organization should begin planning to upgrade to Drupal 9 no later than summer of 2021. The reason for that is because the projected end-of-life for the Drupal 8 software is November of 2021, when Symfony 3 (Drupal 8’s largest major dependency) will no longer be supported by its own community.
In the meantime, the best thing your organization can do to prepare for the launch of Drupal 9 is to make sure that you keep your Drupal 8 site fully up to date.
For help planning out your Drupal roadmap, and to make sure that you’ll be ready for a smooth upgrade to Drupal 9 when it releases, contact FFW. We’re here to help you plan out your long-term Drupal strategy and make sure that your team can make the most of your site today, tomorrow, and after Drupal 9 is released.
Everyone loves attractive layouts for web pages. Luckily, Drupal has plenty of awesome page building tools. You will hear such tool names as Panels, Panelizer, Paragraphs, Display Suite, Page Manager, Twig, and more.
It’s no secret that I find Composer a very troublesome piece of software to work with.
I have issues with Composer on two fronts. First, its output is extremely user-unfriendly, such as the long lists of impenetrable statements about dependencies that it produces when it tells you why it can’t make a change you request. Second, many Composer commands have unwanted side-effects, and these work against the practice that changes to your codebase should be as simple as possible for the sake of developer sanity, testing, and user acceptance.
I recently discovered that removing packages is one such task where Composer has ideas of its own. A command such as remove drupal/foo will take it on itself to also update some apparently unrelated packages, meaning that you either have to manage the deployment of these updates as part of your uninstallation of a module, or roll up your sleeves and hack into the mess Composer has made of your codebase.
Guess which option I went for.
Step 1: Remove the module you actually want to remove
Let’s suppose we want to remove the Drupal module ‘foo’ from the codebase because we’re no longer using it:
$ composer remove drupal/foo
This will have two side effects, one of which you might want, and one of which you definitely don’t.
Side effect 1: dependent packages are removed
This is fine, in theory. You probably don’t need the modules that are dependencies of foo. Except… Composer knows about dependencies declared in composer.json, which for Drupal modules might be different from the dependencies declared in module info.yml files (if maintainers haven’t been careful to ensure they match).
Furthermore, Composer doesn’t know about Drupal configuration dependencies. You could have the situation where you installed module Foo, which had a dependency on Bar, so you installed that too. But then you found Bar was quite useful in itself, and you’ve created content and configuration on your site that depends on Bar. Ideally, at that point, you should have declared Bar explicitly in your project’s root composer.json, but most likely, you haven’t.
So at this point, you should go through Composer’s output of what it’s removed,
and check your site doesn’t have any of the Drupal modules enabled.
I recommend taking the list of Drupal modules that Composer has just told you it’s removed in addition to the requested one, and checking its status on your live site:
$ drush pml | ag MODULE
If you find that any modules are still enabled, then revert the changes you’ve just made with the remove command, and declare the modules in your root composer.json, copying the declaration from the composer.json file of the module you are removing. Then start step 1 again.
Side effect 2: unrelated packages are updated
This is undesirable basically because any package update is something that has to be evaluated and tested before it’s deployed. Having that happen as part of a package removal turns what should be a straight-forward task into something complex and unpredictable. It’s forcing the developer to handle two operations that should be separate as one.
(It turns out that the maintainers of Composer don’t even consider this to be a problem, and as I have unfortunately come to expect, the issue on github is a fine example of bad maintainership (for the nadir, see the issue on the use of JSON as a format for the main composer file) — dismissing the problems that users explain they have, claiming the problems are by design, and so on.)
So to revert this, you need to pick apart the changes Composer has made, and reverse some of them.
Before you go any further, commit everything that Composer changed with the remove command. In my preferred method of operation, that means all the files, including the modules folder and the vendor folder. I know that Composer recommends you don’t do that, but frankly I think trusting Composer not to damage your codebase on a whim is folly: you need to be able to back out of any mess it may make.
Step 2: Repair composer.lock
The composer.lock file is the record of how the packages currently are, so to undo some of the changes Composer made, we undo some of the changes made to this file, then get Composer to update based on the lock.
First, restore version of composer.lock to how it was before you started:
$ git checkout HEAD^ composer.lock
Unstage it. I prefer a GUI for git staging and unstaging operations, but on the command line it’s:
$ git reset composer.lock
Your composer lock file now looks as it did before you started.
Use either git add -p or your favourite git GUI to pick out the right bits. Understanding which bits are the ‘right bits’ takes a bit of mental gymnastics: overall, we want to keep the changes in the last commit that removed packages completely, but we want to discard the changes that upgrade packages.
But here we’ve got a reverted diff. So in terms of what we have here, we want to discard changes that re-add a package, and stage and commit the changes that downgrade packages.
When you’re done staging you should have:
- the change to the content hash should be unstaged.
- chunks that are a whole package should be unstaged
- chunks that change version should be staged (be sure to get all the bits that relate to a package)
Then commit what is staged, and discard the rest.
Then do a git diff of composer.lock against your starting point: you should see only complete package removals.
Step 3: Restore packages with unrelated changes
$ composer update --lock
This will restore the packages that Composer updated against your will in step 1 to their original state.
If you are committing Composer-managed packages to your repository, commit them now.
As a final sanity check, do a git diff against your starting point, like this:
$ git df --name-status master
You should see mostly deleted files. To verify there’s nothing that shouldn’t be there in the changed files, do:
$ git df --name-status master | ag '^[^D]'
You should see only composer.json, composer.lock, and the autoloader’s files.
PS. If I am wrong and there IS a way to get Compose to remove a package without side-effects, please tell me.
I feel I have exhausted all the options of the remove command:
- –no-update only changes composer.json, and makes no changes to package files at all. I’m not sure what the point of this is.
- –no-update-with-dependencies only removes the one package, and doesn’t remove any dependencies that are not required anywhere else. This leaves you having to pick through composer.json files yourself and remove dependencies individually, and completely obviates the purpose of a package manager!
Why is something as simple as a package removal turned into a complex operation by Composer? Honestly, I’m baffled. I’ve tried reasoning with the maintainers, and it’s a brick wall.
PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.