All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
This feature provides the configuration for content specific structure that allows publication of the Contracting documents of the Public Entities of the Bogotá's District which corresponds to the Standard for the Publication and Divulgation of public information defined in the Law of Transparency and Public Information Access of Colombian State.
The Drupal community is unique in many ways, and the Drupal Security Team is an example of this. They provide documentation about writing secure code and keeping your site secure. They work with the drupal.org infrastructure team and the maintainers of contributed modules, to look into and resolve security issues that have been reported.Felix Morgan Thu, 05/24/2018 - 22:33
When a security issue is reported, the Drupal Security Team mobilizes to investigate, understand, and resolve it as soon as possible. They use a Coordinated Disclosure policy, which means that all issues are kept private until a patch can be created and released. Public announcements are only made when the issue has a solution and a secure version is available to everyone. This communication is sent out through all of the channels possible so that everyone is made aware of what they need to do to keep their sites safe and secure.
This means that everyone finds out about the patches, and therefore the vulnerabilities, at the same time. This includes people who want to keep their sites secure, as well as those who want to exploit vulnerabilities. Security updates become a matter of speed, and the development teams at Amazee Labs, along with our hosting partner amazee.io, are always ready to make sure patches are implemented as quickly as possible.Recent Drupal Security Releases
On March 28th 2018, the Drupal Security Team released SA-CORE-2018-002. This patch was a critical security vulnerability that needed to be implemented on every Drupal site in the world as quickly as possible. At the time of the patch release there were no publically known exploits or attacks using the vulnerability, which was present on Drupal versions 6.x, 7.x & 8.x and was caused by inadequate input sanitization on Form API (FAPI) AJAX requests.
On April 25th, 2018 SA-CORE-2018-004 was released as a follow up patch. This release fixed a remote code execution (RCE) bug that would affect any site with Drupal versions 7.x or 8.x. The vulnerability was critical, and both issues resulted from problems with how Drupal handles a “#” character in URLs.What are the dangers?
There are a number of different kinds of attacks that could take advantage of vulnerabilities fixed in the recent security updates. One kind of attack that is becoming more common is the installation of cryptocurrency mining software. These attacks are both subtle and resilient and use the CPU of the site server to generate cryptocurrency for the attacker.Amazee Labs is keeping your sites safe
The Amazee Labs team takes these security releases seriously and works quickly to prepare for these updates. We inform our clients as soon as possible about the upcoming release and organize the maintenance and development teams to be ready to run the updates at the time of the release. During these “patch parties” our global teams work together to solve problems and secure all sites by leveraging everyone’s expertise all at once.
Implementing these measures takes development time not alloted in our usual maintenance budgets. We will always let you know when additional work is needed, and keep the communication channels open to address any concerns.
An additional layer of security is provided to our clients who host with our partner amazee.io. As soon as the security patch is released, the amazee.io team work to put an infrastructure level mitigation in place. This means that all Drupal sites that they host are immediately secured against initial attacks. You can read a detailed breakdown of how they accomplished this here.
This feature provides the configuration for content specific structure that allows publication of the Planning documents of the Public Entities of the Bogotá's District which corresponds to the Standard for the Publication and Diviulgation of public information defined in the Law of Transparency and Public Information Access of Colombian State.
SVG files are an integral part of websites. This article covers 3 Drupal contrib modules that will help users get SVG files into their field-able content types. We also touch on future Drupal core support for SVG files.Read More
This feature provides the configuration for content specific structure that allows publication of the normativity of the Public Entities of the Bogotá's District.
This Normativity corresponds to the Standard for the Publication and Diviulgation of public information defined in the Law of Transparency and Public Information Access of Colombian State.
In this video, Josh Miller shows you how to install Drupal Commerce 2 using a local development tool called Lando. Further instructions are included below the video.
- Commerce Kickstart download: 0:51
- “composer install” command: 8:00
- “lando init” command: 12:56
- “lando start” command: 15:06
- “Drupal install” screen: 17:04
- “lando stop” command: 21:18
Code generated during this video:
Getting Drupal up and running on your computer is an important first step as an evaluator. Good news is that there’s a lot of tech that makes this easier than ever before. We’re going to walk you through how to install Commerce 2 using the Kickstart resource, Composer, and Lando.
- Download and install Composer
- Download and install Lando
- Next go to Commerce Kickstart to create and download your customized composer.json file
- Run ‘composer install’
- Run ‘lando init’
- Run ‘lando start’
- Visit your local URL and install Drupal
- Start building!
Drupal Commerce is an ecommerce focused subset of tools and community based on the open source content management system called Drupal. Drupal Commerce gives you the ability to sell just about anything to anyone using a myriad of open source technologies and leveraging hundreds of Drupal modules built to make that thing you need do that thing you want.
We use Commerce Kickstart to get things started.
Composer is the PHP dependency manager that can not only build and bring in Drupal, Drupal Commerce, and Symfony, but is the technology behind the newest Drupal Commerce Kickstart distribution. We leverage the composer.json file that commercekickstart.com gives us to bring in all of the Drupal code necessary to run a Drupal Commerce website.
To get started, we run “composer install” and that command brings in all the requirements for our project.What is Docker
Docker is a virtualization software that brings together App services like Apache, Nginx, MySQL, Solr, Memcache, and many other technologies so that it can run on your own computer. This installation video uses a tool that runs on top of Docker in an abstract, and frankly easier, way.
If you want to learn more about Docker and the many different types of tools that run on top of it, we recommend John Kennedy’s 2018 Drupalcon presentation about Docker.
Another great resource that compares using Docker tools is Michael Anello’s take on the various technologies.What is Lando
Lando is a thin abstraction layer of tools on top of Docker that makes creating an environment as easy as “lando init” followed by “lando start.” Lando keeps the often confusing devops work of creating a local virtual environment to a few very well documented variable settings that it turns into full docker-compose scripts that Docker, in turn, uses to create a local environment where everything just works together. We’re very excited to see how Lando and Drupal Commerce start to work together.
Last month I went to my first DrupalCon in Nashville. I met a lot of interesting people, had good conversations, and had a hard time choosing from the record number of sessions. As the week went on, I noticed a theme kept coming up. It showed up in sessions on how to create a better admin and content editing experience, in sessions on accessibility and what it’s like to be a blind or deaf engineer, in conversations about helping first-time users enjoy the experience of using Drupal, and in debates about what Drupal will look like in the future. What if the thing that will give Drupal a competitive advantage and improve the admin experience is the same thing that will attract new users and create sites that are accessible for all?
The idea that kept surfacing during my week at DrupalCon was this: we need empathy. The Drupal community has excelled at solving complex engineering problems, and the next challenge we face is just as critical, though it requires us to think a little differently: how do we make space for empathy in our work and in our community?
It’s time to shift our perspective. Photo Credit: Randy Jacob.Our Bias is our Blindspot
Sometimes we don’t need more complex solutions, we need thoughtful ones. Building websites is challenging. There’s never enough time or resources. It’s easy to stick with what’s known and what works. But sometimes what I know is limited, and only works for people who look and think like me. It’s easy to become insular and indifferent to the needs of others because it’s hard to make everyone happy, and thinking about the effort required to change can be overwhelming.
If someone told me, “It’s really hard to talk to people with accents, so I just avoid them,” I’d be shocked. But I know I’ve created sites and tools that are difficult—if not impossible—for people with disabilities to use. Arriving in Nashville, I knew enough about accessibility to know that I needed to learn more. So I dove in and attended every session I could.
I kicked off my deep dive with Katherine Shaw and Fito Kahn’s awesome all day Drupal Accessibility training. Check out Katherine Shaw’s great blog posts on accessibility.Accessible Empathy
I learned that excuses like “accessibility is hard,” or “it doesn’t affect me because I’m not working on a government site” won’t get me off the hook. Accessible websites are now a part of the Americans with Disabilities Act. And any site that is not accessible to all users is liable. I met several engineers who are currently resolving warnings or navigating lawsuits for not meeting WCAG 2.0 guidelines.
But it’s about much more than just changing processes to avoid a lawsuit. Listening to the Core Accessibility panel, I was humbled when it was pointed out that we labor over fixes for Internet Explorer, which can make up 2-3% of users. Meanwhile, 12.6% of people in the US have disabilities (40.7 million people), and accessibility can still be considered an edge case. Building a website that works for more users is not difficult, but it takes intention, a willingness to learn and empathy.
I also learned that having empathy for all types of users doesn’t mean everything has to change immediately. During his talk about accessibility, Everett Zufelt said, “The best place to start? Anywhere. If you fix one button, your site is that much more accessible than it was before.” So I’m challenging myself to build things the right way the first time, drop bad habits and to refine best practices so I can create sites and tools that serve all types of users.Inward Empathy
For some of you reading this, the challenge might be that you have empathy for everyone in the room, except yourself. You take on multiple roles at work. You handle the backend and the frontend and design and project management. You say yes because you know you can do it and how will you get ahead if you don’t show how valuable you are by doing all of the things all the time? I get it. Now stop it.
“ ‘No’ might make them angry, but it will make you free.” –Nayyirah Waheed; Photo credit: Clem Onojeghuo
You deserve empathy too, so be kind to yourself. Good boundaries will keep you fresh and sane. A well cared for version of you will help your team more than the stretched and exhausted one that’s running on too little sleep and too much caffeine.
Something that stood out to me in particular in sessions at DrupalCon was how people wouldn’t move over in their seats to make room and allow those in an already crowded session to sit comfortably in chairs instead of on the floor. People would have empty seats on either side, and not move down the row to make it easier others. There are people who don’t have an issue taking up space, taking what they need, and not for an instant feeling bad about it. Let’s find some balance somewhere in the middle. Give yourself the empathy you need to succeed, and–for the love of god–let’s all scoot down so no one is left sitting on the floor.Outward Empathy
A better admin experience, and faster and more accessible websites are only created when we think about how our work is used by everyone. Take a moment to walk a mile in someone else’s shoes. Now apologize for taking their shoes, sit down and talk to them about how they use your site, what the sticking points are, and how it can be improved. Most importantly, listen. Forget what you think you know, and learn about what it means to be someone else using your website. Then you just might have a week like mine where you were reminded: sometimes engineers are blind or deaf, or both. Sometimes keynotes are a she or a he or a they. Sometimes content editors know exactly what is needed to make a better editing experience–if you just ask.Be Human. Think Digital.
Empathy is what makes us human. We all want to be seen and known and understood. And at the end of the day we all want to use tools that help us to accomplish a task, not remind us that we’re not who the engineer had in mind. Technology without empathy is hollow. Empathy without technology is limited. Let’s make space for empathy in our community and in our code, and let’s change the world for good—for everyone.
One of my favorite slides from the Driesnote at DrupalCon Nashville
The ThinkShout team hanging out with some awesome folks at the Women in Drupal event.Resources
If you’re interested in learning more about the sessions I attended this week, here are links to some of my favorite talks:
If you’re overwhelmed by accessibility and don’t know where to start, here’s a great video on how to do a very basic accessibility audit.
If you’re interested in refining your accessibility practices, there are some amazing tools and resources available. Here are some of my favorites. If you have tools or processes you love, please share in the comments below!
Style Guide Module: Allows you to run accessibility tests on one page that is automatically populated with all basic layout elements. This is also great as a living style guide for the site.
A11y checklist: A11y has a ton of patterns and a useful checklist.
WAVE Accessibility Plugin: Described in the “A smarter Way to Test Accessibility” talk as the ‘Cadillac of accessibility plugins,” this free tool will catch errors, markup the page with an outline of your headings and make accessibility QA much easier.
Sim Daltonism tool: This overlay tool allows you to preview your site for multiple types of colorblindness.
Color Contrast Ratio Checker: This chrome plugin will tell you whether the color contrast of fonts on your site passes WCAG 2.0 standards.
ARIA cheat sheet: This doc outlines all of the different ways you can use ARIA to make your site more accessible
HTML Codesniffer by Squiz: Allows you to set the accessibility standard you want to meet (WCAG2AA is the new legal requirement), and creates a report identifying errors, warnings and notices.
Blizz Vanisher is a tool to help you integrate and configure the Cookie Manager library "tarteaucitron.js" into your Drupal project in order to make your website compliant to the new european "General Data Protection Regulation" (GDPR).
Flocon de toile | Freelance Drupal: Switch from Google Maps to Leaflet and OpenStreetMap with Geolocation on Drupal 8
May 2, 2018 Google has announced a major policy change regarding the use of its online services, including its popular mapping service Google Maps and all its associated APIs, to embed or generate location-based information. This policy change now pays for a service that was previously available for free under some relatively generous quota limits starting June 11, 2018. Please read this post for full details on this policy change and its implications.
Customize the field prefix or remove the default prefix field_
Install this module and visit admin/config/field_prefix/setting
When we originally announced that we'd be providing Drupal 6 Long-Term Support, we committed to supporting our customers until at least February 2017.
Each year in the spring, we've taken a look at the state of Drupal 6 and decide whether we'll extend support for another year, and if we need to make any changes to our offering. Here's the articles from 2016 and 2017, where we announced support until at least February 2019.
Today, I'm happy to announce that we'll be extending our Drupal 6 Long-Term Support until at least February 2020!
While I'm sure there will come a time, when it no longer makes business sense to pour resources into Drupal 6 for the few remaining sites, however, it's already clear to us that there's enough demand to one more year.
However, this time is a little different because PHP 5.6 will reach the end of its security support in December 2018 (8 months from now).
We can't responsibly provide Long-Term Support for Drupal 6, if there isn't a PHP version that you can securely run it on.
So, this year we're making some bigger changes to the program and price and to Drupal 6 itself!
Read on to find out more!
This module will provide a search form inside terms overview pages to help admin users to find taxonomy term by term name.
(Find taxonomy term by term name at terms overview page.)
Sector Blog offers a simple and easy to use blog to publish updates, engage with your audience, or collaborate across teams and locations. Included is everything you'll need to get going - a Blog post content type, automated lists and filtered archives, as well as comments and a Blog editor user role.
Sector Blog is an optional Sector Add-on. The Sector Blog components and configuration make it easy to get started, and the sample content make it easy to grasp the main features.
Our global community includes many EU citizens and residents of the EEA, and we have taken steps to comply with the GDPR which takes effect on May 25, 2018.Your rights under this law and how Drupal.org complies with GDPR
For easy and clear access to the changes:
In plain language, regulations such as GDPR define the following roles, rights, and responsibilities:
- Data Subject - this is you, the end user.
- Data Controller - this is us, the Drupal Association as the owners and operators of Drupal.org and its sub-sites.
- Data Processor - any other organization that processes personal data on behalf of the Data Controller.
- Right to be Informed - A data subject has the right to know whether personal information is being processed; where; and for what purpose.
- Right to Access - A data subject has a right to access the information about them that is stored by the Data Controller.
- Right to Rectification - A data subject has the right to correct any errors in the data about them. This can be done by editing your user account, or contacting the Drupal Association directly.
- Right to Restrict Processing - A data subject has the right to request that data not be processed, and yet also not be deleted by the Data Controller.
- Right to Object - A data subject has the right to opt out of marketing, processing based on legitimate interest, or processing for research or statistical purposes.
- Right to be Forgotten - Also known as the right to revoke consent, the right to be forgotten states that a data subject has the right to request erasure of data, the cessation of processing by the controller, and halting processing of the data by third party processors.
The conditions for this, as outlined in article 17, include the data no longer being relevant to original purposes for processing, or a data subjects withdrawing consent.
It should also be noted that this right requires controllers to compare the subjects' rights to "the public interest in the availability of the data" when considering such requests.
- Data Portability - A data subject has the right to receive a copy of their data in a 'commonly used and machine readable format.'
This information is outlined in the sections below titled "Your Choices About Use and Disclosure of Your Information" and "Accessing and Correcting Your Information".
- Privacy by Design - 'The controller shall..implement appropriate technical and organisational measures..in an effective way.. in order to meet the requirements of this Regulation and protect the rights of data subjects'. Article 23 of the GDPR calls for controllers to hold and process only the data absolutely necessary for the completion of its duties, as well as limit the access to personal data to those who need it to carry out these duties.
- Breach Notification - The Data Controller must notify the appropriate data processing authority and any affected end user of any breach that might result in 'risk to the rights and freedoms of individuals' within 72 hours of becoming aware of the breach.
A Data Processor must notify the Data Controller of any breach 'without undue delay.'
- Data protection officer - A Data Controller or Processor must appoint a Data Protection Officer when: a Data Controller represents a public authority; or the core operations of the Controller require regular and systematic monitoring of Subjects on a large scale; or when the Controller's core operations depend on processing a large scale of special categories of data (including but not limited to health data, criminal conviction information, etc).
The Drupal Association's core operations do not require the Association to establish a Data Protection Officer.
We take privacy and security very seriously, as all Drupal professionals do! We will continue analyzing the legal landscape and collecting feedback for future revisions.
A field group formatter to hide settings unobtrusively on the form. Any fields within this group will hide in a panel that is toggled by a button. This button (a gear icon) will float to the right side of the form.
The Schemata module is our best approach so far in order to provide schemas for our API resources. Unfortunately, this solution is often not good enough. That is because the serialization component in Drupal is so flexible that we can’t anticipate the final form our API responses will take, meaning the schema that our consumers depend on might be inaccurate. How can we improve this situation?
This article is part of the Decoupled hard problems series. In past articles, we talked about request aggregation solutions for performance reasons, and how to leverage image styles in decoupled architectures.TL;DR
- Schemas are key for an API's self-generated documentation
- Schemas are key for the maintainability of the consumer’s data model.
- Schemas are generated from Typed Data definitions using the Schemata module. They are expressed in the JSON Schema format.
- Schemas are statically generated but normalizers are determined at runtime.
A database schema is a description of the data a particular table can hold. Similarly, an API resource schema is a description of the data a particular resource can hold. In other words, a schema describes the shape of a resource and the datatype of each particular property.
Consumers of data need schemas in order to set their expectations. For instance, the schema tells the consumer that the body property is a JSON object that contains a value that is a string. A schema also tells us that the mail property in the user resource is a string in the e-mail format. This knowledge empowers consumers to add client-side form validation for the mail property. In general, a schema will help consumers to have a prior understanding of the data they will be fetching from the API, and what data objects they can write to the API.
We are using the resource schemas in the Docson and Open API to generate automatic documentation. When we enable JSON API and Open API you get a fully functional and accurately documented HTTP API for your data model. Whenever we make changes to a content type, that will be reflected in the HTTP API and the documentation automatically. All thanks to the schemas.
A consumer could fetch the schemas for all the resources it needs at compile time or fetch them once and cache them for a long time. With that information, the consumer can generate its models automatically without developer intervention. That means that with a single implementation once, all of our consumers’ models are done forever. Probably, there is a library for our consumer’s framework that does this already.
More interestingly, since our schema comes with type information our schemas can be type safe. That is important to many languages like Swift, Java, TypeScript, Flow, Elm, etc. Moreover, if the model in the consumer is auto-generated from the schema (one model per resource) then minor updates to the resource are automatically reflected in the model. We can start to use the new model properties in Angular, iOS, Android, etc.
In summary, having schemas for our resources is a huge improvement for the developer experience. This is because they provide auto-generated documentation of the API and auto-generated models for the consumer application.How Are We Generating Schemas In Drupal?
One of Drupal 8's API improvements was the introduction of the Typed Data API. We use this API to declare the data types for a particular content structure. For instance, there is a data type for a Timestamp that extends an Integer. The Entity and Field APIs combine these into more complex structures, like a Node.
JSON API and REST in core can expose entity types as resources out of the box. When these modules expose an entity type they do it based on typed data and field API. Since the process to expose entities is known, we can anticipate schemas for those resources.
In fact, assuming resources are a serialization of field API and typed data is the only thing we can do. The base for JSON API and REST in core is Symfony's serialization component. This component is broken into normalizers, as explained in my previous series. These normalizers transform Drupal's inner data structures into other simpler structures. After this transformation, all knowledge of the data type, or structure is lost. This happens because the normalizer classes do not return the new types and new shapes the typed data has been transformed into. This loss of information is where the big problem lies with the current state of schemas.
The Schemata module provides schemas for JSON API and core REST. It does it by serializing the entity and typed data. It is only able to do this because it knows about the implementation details of these two modules. It knows that the nid property is an integer and it has to be nested under data.attributes in JSON API, but not for core REST. If we were to support another format in Schemata we would need to add an ad-hoc implementation for it.
The big problem is that schemas are static information. That means that they can't change during the execution of the program. However, the serialization process (which transforms the Drupal entities into JSON objects) is a runtime operation. It is possible to write a normalizer that turns the number four into 4 or "four" depending if the date of execution ends in an even minute or not. Even though this example is bizarre, it shows that determining the schema upfront without other considerations can lead to errors. Unfortunately, we can’t assume anything about the data after its serialized.
We can either make normalization less flexible—forcing data types to stay true to the pre-generated schemas—or we can allow the schemas to change during runtime. The second option clearly defeats the purpose of setting expectations, because it would allow a resource to potentially differ from the original data type specified by the schema.
The GraphQL community is opinionated on this and drives the web service from their schema. Thus, they ensure that the web service and schema are always in sync.How Do We Go Forward From Here
Happily, we are already trying to come up with a better way to normalize our data and infer the schema transformations along the way. Nevertheless, whenever a normalizer is injected by a third party contrib module or because of improved normalizations with backward compatibility the Schemata module cannot anticipate it. Schemata will potentially provide the wrong schema in those scenarios. If we are to base the consumer models on our schemas, then they need to be reliable. At the moment they are reliable in JSON API, but only at the cost of losing flexibility with third-party normalizers.
One of the attempts to support data transformations and the impact they have on the schemas are Field Enhancers in JSON API Extras. They represent simple transformations via plugins. Each plugin defines how the data is transformed, and how the schema is affected. This happens in both directions, when the data goes out and when the consumers write back to the API and the transformation needs to be reversed. Whenever we need a custom transformation for a field, we can write a field enhancer instead of a normalizer. That way schemas will remain correct even if the data change implies a change in the schema.undefined
We are very close to being able to validate responses in JSON API against schemas when Schemata is present. It will only happen in development environments (where PHP’s asserts are enabled). Site owners will be able to validate that schemas are correct for their site, with all their custom normalizers. That way, when a site owner builds an API or makes changes they'll be able to validate the normalized resource against the purported schema. If there is any misalignment, a log message will be recorded.
Ideally, we want the certainty that schemas are correct all the time. While the community agrees on the best solution, we have these intermediate measures to have reasonable certainty that your schemas are in sync with your responses.
Note: This article was originally published on November 3, 2017. Following DrupalCon Nashville, we are republishing (with updates) some of our key articles on decoupled or "headless" Drupal as the community as a whole continues to explore this approach further. Comments from the original will appear unmodified.
It’s hard to believe DrupalCon Nashville was over a month ago! We have been busy here at Chromatic ever since, but we wanted to give a recap of the conference from our point of view.