emGee Software Solutions Custom Database Applications

Share this

Drupal CMS

Appnovation Technologies: Simple Website Approach Using a Headless CMS: Part 1

Drupal.org aggregator - Wed, 02/06/2019 - 00:00
Simple Website Approach Using a Headless CMS: Part 1 I strongly believe that the path for innovation requires a mix of experimentation, sweat, and failure. Without experimenting with new solutions, new technologies, new tools, we are limiting our ability to improve, arresting our potential to be better, to be faster, and sadly ensuring that we stay rooted in systems, processes and...
Categories: Drupal CMS

The Accidental Coder: 8: Compound (bundled) fields - your new best friend - Part 5

Drupal.org aggregator - Sat, 01/12/2019 - 19:38
8: Compound (bundled) fields - your new best friend - Part 5 j ayen green Sat, 01/12/2019 - 22:38
Categories: Drupal CMS

Jeff Geerling's Blog: Cleaning up after adding files in Drupal Behat tests

Drupal.org aggregator - Fri, 01/11/2019 - 11:51

I've been going kind of crazy covering a particular Drupal site I'm building in Behat tests—testing every bit of core functionality on the site. In this particular case, a feature I'm testing allows users to upload arbitrary files to an SFTP server, then Drupal shows those filenames in a streamlined UI.

I needed to be able to test the user action of "I'm a user, I upload a file to this directory, then I see the file listed in a certain place on the site."

These files are not managed by Drupal (e.g. they're not file field uploads), but if they were, I'd invest some time in resolving this issue in the drupalextension project: "When I attach the file" and Drupal temporary files.

Since they are just random files dropped on the filesystem, I needed to:

Categories: Drupal CMS

The Accidental Coder: The Flip Side of Community and Open Source

Drupal.org aggregator - Fri, 01/11/2019 - 07:12
The Flip Side of Community and Open Source j ayen green Fri, 01/11/2019 - 10:12
Categories: Drupal CMS

Agiledrop.com Blog: Top Drupal blog posts from December 2018

Drupal.org aggregator - Fri, 01/11/2019 - 02:54

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.

READ MORE
Categories: Drupal CMS

Droptica: Rules module – automatic conditionally executed actions in Drupal 8

Drupal.org aggregator - Fri, 01/11/2019 - 01:23
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:
Categories: Drupal CMS

Vardot: 3 Reasons Why Drupal Distributions Are Essential

Drupal.org aggregator - Thu, 01/10/2019 - 06:13
Firas Ghunaim January 10, 2019

Amongst ambitious brands and serious digital operators; Drupal adoption rate on the rise.

Governments and major brands across the globe are already testifying to the positive impact that Drupal has made on their digital business.

As a developer, you might be approached by a client that insists on developing their digital platform and/or experience using Drupal.

Here are 3 key reasons why Drupal distributions will make your life much easier:

 

1. Time

“How long do you need to complete the project? That long?!?”

Dealing with continuous amendments and changes to the project requirements is the bane of all developers.

Distributions feature tons of tried and tested best-in-class features, modules and components that are already integrated and tested together. This allows developers to successfully complete project tasks that normally consume a scary amount of time to build.

For example; should you be required to build a Media Entity Browser for a certain project may consume up to 6 to 8 hours from your time.

 

Source: Varbase

Imagine it took you that long for project A... now you have to repeat the same process for project B.

However; with Drupal distributions such as Varbase, the Media Entity Browser is already built-in, optimized and integrated with other modules you might require.

Total time consumed on Media Entity Browser development: Zero.

Thanks to DRY (Don’t-Repeat-Yourself); Drupal distributions will shorten the project development time by hundreds of hours. You won’t ever have to repeat the same development process for any other project.

 

LEARN MORE ABOUT VARBASE

 

2. Efficiency

Not all programmers and web developers are equal in skill and expertise. But, we all face challenges and issues that might arise during the project development process.

Drupal distributions offer a wealth of solutions that fix issues you might not even realize you had. Why? Open-source.

For example; you are currently developing an e-commerce platform for a client and face an issue with a particular component.

The fact is that you weren’t the first developer to encounter this issue.

When using Drupal distributions, you will find almost all challenges and issues related to components or modules you may need have been solved and addressed by someone before you.

Working on almost ready-built websites not only saves time but also affords you the opportunity to personalize any ready-made component or feature based on your project requirements.

Take the aforementioned example; you already have a Media Entity Browser ready, but you wish to match it to your clients’ requirements. In no time at all, you can build upon the ready-made feature via customization or integration. Simples.

 

3. Standards

At Vardot, we refer to “websites” as digital experiences. The difference between them?

Standards.

Drupal has built a name for itself due to the focus on building the best user-friendly digital experiences possible and the fact that Drupal is open-source has enabled its evolution based on actual feedback from various practical perspectives.

Your ability to develop a website (e.g.) the best online equestrian market; depends entirely on the standards you apply throughout the development process.

For example; Varbase is an ideal distribution to develop platforms that rely on rich multi-media content such as Al Jazeera and Georgetown University. On the other hand, Drupal distributions such as Commerce Kickstart feature every possible component needed by a developer to build an e-commerce digital experience.

Case Study: Georgetown University - Qatar

Of course, when we speak of standards; we are not referring solely to quality standards. You will be able to develop the best possible digital experience for any industry using Drupal distributions whilst maintaining all W3C standards and accessibility standards.

 

Bonus: Drupal Distributions Maintenance

Drupal distributions are rich in features that are all integrated with each other.

You will never have to scour for individual updates for each module you need. All you’ll ever possibly need is to update the distribution itself.

Since all modules and features are integrated. All would be updated and tested together.

If you are considering starting a Drupal project or to build a Drupal-based digital experience, let us know. We'd love to help.  Contact Us.

Categories: Drupal CMS

Digital Echidna: Thoughts on all things digital: Join Us for Drupal Global Contribution Weekend

Drupal.org aggregator - Thu, 01/10/2019 - 03:01
Drupal. It’s been the foundation of our solutions for a few years now and it powers some of the top sites around the world in fields ranging from commerce to government. If you’ve ever been interested in getting your feet wet with the CMS, or…
Categories: Drupal CMS

Issue 370

TheWeeklyDrop - Thu, 01/10/2019 - 01:47
Issue 370 - January, 10th 2019
Categories: Drupal CMS

OpenSense Labs: The SIWECOS: German Government Sponsored CMS Security

Drupal.org aggregator - Thu, 01/10/2019 - 01:34
The SIWECOS: German Government Sponsored CMS Security Vasundhra 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.  Initiative-S 

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 

Awareness Building

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.

Skinning Service

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. 

Web Host

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

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. 
 



RUB 

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

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.



CMS Graden 

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 hello@opensenselabs.com the professionals would guide you with all your queries and questions and help you leverage security for your website.

blog banner blog image Drupal Drupal 8 CMS SIWECOS Security Initiative- S Scanner Eco RUB Hackmanit CMS Garden Protection Blog Type Articles Is it a good read ? On
Categories: Drupal CMS

Drupal Mountain Camp: Drupal Mountain Camp 2019 - Open Source on top of the World - Davos, Switzerland, March 7-10

Drupal.org aggregator - Wed, 01/09/2019 - 23:41
Drupal Mountain Camp 2019 - Open Source on top of the World - Davos, Switzerland, March 7-10 admin Thu, 01/10/2019 - 08:41 Preview

Introduction

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.

Keynotes 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.

Drupal Admin UI & JavaScript Modernisation initiative

In the second keynote Matthew Grill, one of the Drupal 8 JavaScript subsystem maintainers, will present about the importance and significance of the Admin UI & JavaScript Modernisation initiative and Drupal’s JavaScript future.

Sessions

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.

Location

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 camp

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.

Tickets

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.

Key dates
  • 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.

Categories: Drupal CMS

Drupal blog: Refreshing the Drupal administration UI

Drupal.org aggregator - Wed, 01/09/2019 - 11:29

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.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based 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 ChumillasSascha EggenbergerRoy ScholtenArchita AroraDennis CohnRicardo MarcelinoBalazs KantorLewis 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?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri EskolaGábor Hojtsy and Jeff Beeman for their help with this post.

File attachments:  drupal-7-vs-drupal-8-administration-ui-1280w.png carlo-content-administration-1280w.png carlo-spacing-1280w.png
Categories: Drupal CMS

FFW Agency: It’s time to start planning for Drupal 9

Drupal.org aggregator - Wed, 01/09/2019 - 10:24
It’s time to start planning for Drupal 9 leigh.anderson 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.

Comments
Categories: Drupal CMS

InternetDevels: A glimpse at creating layouts in Drupal 8 with the Layout Builder module

Drupal.org aggregator - Wed, 01/09/2019 - 08:26

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.

Read more
Categories: Drupal CMS

Joachim's blog: Getting more than you bargained for: removing a Drupal module with Composer

Drupal.org aggregator - Wed, 01/09/2019 - 06:19

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

Finally, do:

$ 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.

Tags: Composer
Categories: Drupal CMS

Matt Glaman: Writing better Drupal code with static analysis using PHPStan

Drupal.org aggregator - Tue, 01/08/2019 - 20:00
Writing better Drupal code with static analysis using PHPStan Published on Tuesday 8, January 2019

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.

Categories: Drupal CMS

Karim Boudjema: 10 helpful Drupal 8 modules for 2019

Drupal.org aggregator - Tue, 01/08/2019 - 15:04
It’s always hard to pick up the most useful Drupal 8 modules because it depends on the site you will create or manage. But there are some really helpful modules you can use in almost every situation.

In this post, I will share some modules that I use almost all the time in my Drupal 8 projects, they are not related to a particular type of site but they are always helpful, both in development or production environment.

1. Admin Toolbar

(D8) - https://www.drupal.org/project/admin_toolbar
The Admin Toolbar module will greatly save your time. By having a drop-down menu and extending the original Drupal menu, it helps to perform various admin actions faster and easier.

The module works on the top of the default toolbar core module, therefore it is a very light module and keeps all the toolbar functionalities (shortcut / media responsive).
Categories: Drupal CMS

mark.ie: Creating an 'Add to Calendar' Widget in Drupal

Drupal.org aggregator - Tue, 01/08/2019 - 13:11
Creating an 'Add to Calendar' Widget in Drupal

A simple request: we need an 'Add to Calendar' widget to add our events to Google Calendar, iCal, and Outlook. Simple (once I had completed it!).

markconroy Tue, 01/08/2019 - 21:11

There's a module for that. There is, it's called, obviously, addtocalendar. It works very well, if you:

  • want to use the addtocalendar.com service,
  • want to pay for this service

If you don't want to use an external service for something as simple as adding an event to a calendar, then it looks like you'll need a custom solution. Their smallest plan only allows 2 events per month.

The PatternLab Part

Here's the custom solution I came up with (in the future, I'll look at creating a module for this with a settings/UI page for site builders). Note, it's a PatternLab implementation; if you don't use PatternLab and just want to work directly in your Drupal theme, it would be even easier.

Here's the code for the 'Add to Calendar' pattern in PatternLab (some classes and things are removed to make it easier to read):

  1. {%
  2. set classes = [
  3. "add-to-calendar"
  4. ]
  5. %}
  6.  
  7. {% set ical_link = 'data:text/calendar;charset=utf8,BEGIN:VCALENDAR%0AVERSION:2.0%0ABEGIN:VEVENT%0ADTSTART:' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '%0ADTEND:' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '%0ASUMMARY:' ~ atc_title ~ '%0ADESCRIPTION:' ~ atc_details|striptags ~ '%0ALOCATION:' ~ atc_location|replace({'
    ': ' ', '
    ': ' ', '

    ': ' ', '

    ': ''}) ~ '%0AEND:VEVENT%0AEND:VCALENDAR' %}
  8.  
  9. {% set google_link = 'https://www.google.com/calendar/r/eventedit?text=' ~ atc_title ~ '&dates=' ~ atc_start_date|date("Ymd\\THi00\\Z") ~ '/' ~ atc_end_date|date("Ymd\\THi00\\Z") ~ '&details=' ~ atc_details|striptags ~ '&location=' ~ atc_location|replace({'
    ': ' ', '
    ': ' ', '

    ': ' ', '

    ': ''}) %}
  10.  
  11. {{ attributes.addClass(classes) }}>
  12.  
  13. {{ google_link }}">Add to Google Calendar
  14.  
  15. {{ ical_link }}">Add to iCal
  16.  
  17. {{ ical_link }}">Add to Outlook
  18.  

What does the above code do?

  • Creates a Google Calendar variable and creates an iCal variable. Outlook will also use iCal.
  • Uses these variables as links to add the event to their respective calendars.

Within the variables, we have some more variables (start date, end date, etc), which we should probably wrap in conditional statements so that their clauses don't print unless they are present in Drupal (some fields might be optional on your event content type, such as end time).

These variables are:

  • atc_start_date: Start Date and time
  • atc_end_date: End Date and time
  • atc_title: the name of the event
  • atc_details: description for the event
  • atc_location: place of event

In our Event pattern in PatternLab, we then have a variable called 'add_to_calendar' so that events have the option to have this widget or not. In event.twig, we simply print:

  1. {% if add_to_calendar %}
  2. {% include '@site-components/add-to-calendar/add-to-calendar.twig' %}
  3. {% endif %}
The Drupal Part

In Drupal we create a boolean field on our event content type field_event_add_to_calendar, if this is ticked, we will display the Add to Calendar widget.

Here's the code from node--event--full.html.twig

  1. {# Set the Add to Calendar Variables #}
  2.  
  3. {% if node.field_add_to_calendar.value %}
  4. {% set add_to_calendar = true %}
  5. {% endif %}
  6.  
  7. {% if node.field_event_date.value %}
  8. {% set atc_start_date = node.field_event_date.value %}
  9. {% endif %}
  10.  
  11. {% if node.field_event_date.end_value %}
  12. {% set atc_end_date = node.field_event_date.end_value %}
  13. {% endif %}
  14.  
  15. {% if node.title.value %}
  16. {% set atc_title = node.title.value %}
  17. {% endif %}
  18.  
  19. {% if node.field_event_intro.value %}
  20. {% set atc_details = node.field_event_intro.value %}
  21. {% endif %}
  22.  
  23. {% if node.field_event_location.value %}
  24. {% set atc_location = node.field_event_location.value %}
  25. {% endif %}
  26.  
  27. ...
  28.  
  29. {% include "@content/event/event.twig" %}

To explain:

If the 'Add to Calendar' boolean is on, we set the add to calendar variable as true

This in turn tells patternlab to render the Add to Calendar component.

We then check if each field we might use has a value in it - such as a start date and end date

If so, we map the values from each of those fields to variables in our Add to Calendar component (such as atc_start, atc_title, etc)

Now, when you view a node, you will see your Add to Calendar widget on any nodes that the editors choose to put it. You can see a sample of the Add to Calendar widget in my PatternLab.

Simple, once I figured it out.

Got an improvement for this? The comments are open.

Categories: Drupal CMS

Dries Buytaert: Refreshing the Drupal administration UI

Drupal.org aggregator - Tue, 01/08/2019 - 08:20

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.

In the short term, we plan on updating the existing administration UI with the new design system. Longer term, we are working on creating a completely new JavaScript-based 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?

The team is looking for more designers and frontend developers to get involved. You can attend the weekly meetings on #javascript on Drupal Slack Mondays at 16:30 UTC and on #admin-ui on Drupal Slack Wednesdays at 14:30 UTC.

Thanks to Lauri Eskola, Gábor Hojtsy and Jeff Beeman for their help with this post.

Categories: Drupal CMS

Agiledrop.com Blog: Interview with Shawn McCabe, CTO of Acro Media

Drupal.org aggregator - Tue, 01/08/2019 - 02:24

This time we had a chat with none other than Shawn McCabe, the CTO of Acro Media. In our interview, the avid Drupal contributor talked about his most memorable Drupal moments, his love for open source and his reasons to opt for a more sustainable lifestyle. Have a read!

READ MORE
Categories: Drupal CMS

Pages

1 2 3 4 5 6 7 8 9 next › last »