All RPGs and Storygames by Tod Foley are now available at DrivethruRPG and RPGnow. Bring these games to your table!
Epic Games has issued a claim against Exciting Events, the organizers of a recent and unsanctioned Fortnite festival hosted in the UK over the weekend.Â ...
Integrates Drupal with BigCommerce.
The module will allow you to leverage the obvious strengths of each platform: Drupal as the front-end CMS for customized UX, design, and content management (including display of intended BC content), and BigCommerce as the headless commerce engine.
In this "Making of GDC" blog post, GM Katie Stern opens up about the process of establishing "Community Spaces" at GDC, and what organizers are doing to help attendees find their place at the show. ...
Drupal Commerce is a fantastic open source ecommerce platform, but there is a common misconception that it is lacking when it comes to performance and scalability. This is not true! Drupal Commerce is extremely fast and is more than capable of scaling from small business all the way to enterprise level ecommerce. We have proof and it’s right here for you to view.
Shawn McCabe, Acro Media’s CTO, put Drupal Commerce to the test to see how it performed on a number of different AWS configurations, ranging from single server setups all the way up to multi-server configurations.
He ran simulated traffic through Drupal Commerce, mimicking actual traffic as close as possible, testing concurrent users, site speed, transactions per second, and a number of other useful technical metrics.
The smallest server configuration tested was capable of handling 130 concurrent users flawlessly, with a throughput of 13.59 transactions per second. On the other hand, the largest configuration could handle 52,000 concurrent users with a throughput of 1,305.85 transactions per second.
The report goes further and includes how the tests were set up, their limitations and methodology, all of the server configurations details and, of course, the test results. This testing puts the performance and scalability question to rest, backed by hard data that anyone can reproduce. Drupal Commerce is a viable option for ecommerce that businesses of any size can use and grow with in the future.
CONTENTS OF THIS FILE
* Recommended modules
The media entity gist module add a new media source for embed gist in your site.
* For a full description of the module, visit the project page:
A new Field Widget for displaying the entity information as a table instead of a grid.
This is useful when displaying only the Entity Label vs the rendered entity.
There will be a security release of 8.5.x and 8.6.x on February 20th 2019 between 1PM to 5PM America/New York (1800 to 2200 UTC). (To see this in your local timezone, refer to the Drupal Core Calendar) . The risk on this is currently rated at 20/25 (Highly critical) AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon.
Not all configurations are affected. Reserve time on February 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory.
Contributed module security updates may also be required.
If you are running Drupal 7, no core update is required, but you may need to update contributed modules if you are using an affected module. We are unable to provide the list of those modules at this time.
Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.
Security release announcements will appear on the Drupal.org security advisory page.
Drupal empowers site builders and editors to configure their sites in settings forms. Configuration management lets developers push changes up to live sites to be imported. But developers have to be considerate to ensure imports will not wipe out those changes made directly through the live sites' settings forms. At the least, they have to export the changes before making further tweaks. But admins may make further changes in the meantime too, so developers can end up frequently pulling irrelevant changes back from live, which seems unnecessary.
Here's some examples of the kind of config that I'm thinking of:
- The site email and Google Analytics account are usually managed by site admins, not developers. So developers should not be the ones to manage those settings.
- Marketers may like tweaking the site name or slogan. That doesn't need to affect developers.
- Contact forms contain labels and other text which may be key to the communication between a client and their customers.
- Permissions - sometimes it's not clear where the lines are between editors/admins/etc, so why not allow some flexibility to reassign permissions directly on live without needing to touch the codebase?
We need an approach that allows for specific settings to be considered 'unmanaged' - so an import wouldn't touch whatever they have made to be on live. The Config Ignore project claims to solve this, but we already use Config split which is more powerful, more flexible and has a better user interface. (Although Config Ignore does allow targeting parts of config rather than whole config items.)
Config split is often used to create environment-specific sets of configuration, but its design means it can be used for separating config for other purposes. In this scenario, what's needed is a split that represents settings to be protected, which can be exported immediately before any import. Then when importing, Drupal only sees the preserved version of the settings, so won't change them, regardless of what is in the main configuration files.
The split, which I've called 'Unmanaged', needs to be set up like as follows (see screenshot):
- Use a folder (directory) which already exists and is writable. I use ../config/unmanaged, so it matches the split name and is outside the webroot.
- Set to active. I usually set all other splits to inactive, and only make them active in an environment's settings.php, but this split exists for the sake of workflow, not environment. For example, it can actually be useful locally, so I can tweak things for development without affecting what ends up in version control.
- Have the largest weight of any split, so that it overrides any other exported version of config it contains.
- Use the Conditional split section, not Complete split, to pick configuration to protect.
- Do not tick either of the checkboxes in the conditional split section.
Once the split has been created, the container needs rebuilding for it to work. Run this, which includes exporting it for the first time:drush cache-rebuild drush -y config-split-export unmanaged
Now that it is exported, a .htaccess file will be have been added to the directory alongside the config. Add the following line to your project's .gitignore file, adjusting the directory location as appropriate. This ensures the directory will get created on live when changes are pulled from git (containing .htaccess), but deliberately without the exported config:config/unmanaged/*.yml
So now before running any imports, make sure to export the split:drush -y config-split-export unmanaged drush -y config-import
With this split and the export step in place in your workflow, you can be confident of allowing your developers and site admins to get on with their respective work, without getting in each others' way. This puts configuration splits to use for something beyond environment-specific overrides, which I think is exciting. I wonder what other useful purposes they may have?
Photo by Sascha Hormel from Pexels
Fetches and stores the comment count for content entities, when using external comment services like Disqus or Facebook Comments. It will make it possible to for example built a “Most commented articles” views blocks.
There is always some data which needs to be masked for some fields as output
This module deals with masking of such fields when shown in Entity View Mode
Eg: - Credit card number : **********2016
- SSN : *****1468
- Phone : 765345####
Module offers a Field Manage Display option to customize the masking output.
Module gives options for users to set different types of masking
1. Show characters
2. Mask characters
Module works with Field type
Websites will run into problems. Whether you're using Drupal or any other software, there will be problems at some point.
Drupal runs on PHP and when PHP has problems, it reports them to you.
However, often these errors will appear on your site and will be visible to visitors, as in the image below: