Creating a duplicate of an entity is easily done via the entity API method Entity::createDuplicate(). This is a convenient method if the goal is to clone an entity into a new entity, as all identifiers of the previous entity get unset when using this method.
Drush should be installed and updated through composer. There is no stable Drush 9 version yet, so the development version must be used. Updating to the development version of Drush 9 is a simple as typing:
$ composer require drush/drush:dev-master
Porting the commands is a semi-automatic process: There is a command that will generate the required files and class structure for you. To start the wizard, just type:
$ drush generate drush-command-file -l dev
Drush will ask you for the module's machine name and for the optional path to the legacy Drush command file (the one that has your commands, ending with .drush.inc). You will have to provide the absolute path.
This is the file your Drush command definition goes into. Do not use your module's regular services.yml as you might have done in Drush 8 or else you will confuse the legacy Drush which will lead to a PHP error like this:
Fatal error: Class 'Drush\Commands\DrushCommands' not found in MyModuleCommands.
Use the dedicated drush.services.yml file in your module's root directory instead.
The file should look like this:
This is a technical description of the 2.x branch of the module. For the newer 3.x branch see this article; for 4.x, see this article.
Version 2.10 of Simple XML sitemap is mainly a feature release with only a few minor bugs fixed. The new features are
See the 8.x-2.10 release page for details.
A new version has been released, please make sure to visit the project page.
Simple XML sitemap is now able to create Google image sitemaps through indexing all images attached to entities. This includes images uploaded through the image field as well as inline images uploaded through the WYSIWYG. The inclusion of images can be set at the entity type and bundle level but can be overridden on a per-entity basis giving you all the flexibility.
Since its relaunch in 2015, the Drupal 7 powered precore.net has been gaining popularity among artists and design students to become their go-to platform. Until today, design students have uploaded over 700 portfolios providing guidance to enrolling candidates. These portfolios are linked to over 500 art faculties of hundreds of universities.
Before enrolling in a course, a candidate can research their local university and study other students' portfolios or enroll in their local design course to prepare for the entry tests - all of it on precore.net.
On top of that, students provide and collect support on the precore.net forum which boasts over 20000 users who have written nearly 250000 posts. This may be the biggest and most beautiful forum built on top of Drupal core.
The most powerful feature however may be the ability for guests to create most of the site's content without having to go through any type of registration process. Visitors can go ahead and correct their school's information just by clicking 'edit'. Likewise, anyone can write a blog post - no account or personal information needed. We think this technology has massively contributed to the quantity and quality of content on precore.net.
Letting users create content without having to register (or going through any other annoying process) is becoming an important customer engagement strategy.
When you allow anonymous users to create content on your website, you want this content to go through a moderation process before it becomes publicly available. To implement this in Drupal, the anonymous user has to be given permission to create content and the content type needs to be unpublished by default.
The problem with Drupal 7 and Drupal 8 is that as soon as the anonymous user saves new content, they loose access rights to it and get redirected to an 'Access denied' page which is not very user friendly.
In addition to the above, you may want the anonymous user to be able to edit or even delete their own content in case they find an error right after submitting it. Users often find typos or other kinds of mistakes right after content submission.
Gbyte created the Session Node Access module to tackle exactly these issues. The module allows administrators to grant certain user roles (not only anonymous users) specific permissions to content they created. These permissions last only as long as the browsing session lasts; after that, the regular permissions apply again. This way it is possible to allow guests or users of a certain role to keep access to their content, even if it is pending for approval.
Now Session Node Access has been ported to Drupal 8 - thank you to Gaël Gosset for doing the initial porting.
Right now this module works only with nodes, we may implement it for other entities in case of demand.
This is a technical comparison of the older 2.x branch of the Simple XML sitemap module and an older development version of XML sitemap. XML sitemap has just had its first release and for more on the newer 4.x branch of Simple XML sitemap see this article.
This comparison may be interesting for XML sitemap users moving to Drupal 8 or for users intending to wait for the port. (Do not wait, help out!) Please also be advised that gbyte made Simple XML sitemap, which makes this comparison intrinsically biased.
There are major differences between Simple XML sitemap (simple_sitemap) and XML sitemap (xmlsitemap) and depending on your use case, you might want to choose one or the other.
What sets the modules apart are their complexity, extensibility, performance and feature sets.
Having been built specifically for D8, simple_sitemap has arguably a cleaner code base adhering to D8 standards i (i.e. use of OOP). In contrast, the xmlsitemap module will have a hard time adjusting to D8 technologies and guidelines, as it carries around a whole lot of legacy code going back as far as Drupal 5.
What is meant here is the impact of the module on a Drupal 8 system, how quick the sitemap generation process is and how long it takes for a visitor to fetch the sitemap.
Sitemap generation performance
The Simple XML Sitemap module was originally created by gbyte as a temporary replacement for the non-functioning Drupal 8 XML Sitemamp Module. After putting some more work into it however, we decided to keep using it in our D8 & D9 projects, as it is very lightweight, simple to use and most importandly, adheres to a newer XML sitemap standard.
The 2.x branch features most of the functionality of the heavier XML Sitemap module while also featuring hreflang and image XML sitemaps, which is a new Google standard for creating multilingual XML sitemaps that should improve SEO even more.
The 3.x branch adds a robust generation process that works with huge sites in limited environments. It also introduces the concept of sitemap variants which are instances of different sitemap types which in turn are made of sitemap and URL generators. This makes it possible to run several different sitemap types on one Drupal instance.
The 4.x branch is a rewrite with developers/integrators in mind and makes much greater use of Drupal's entity API dropping some of its very specific chaining API. On top of that, it features many code and UI improvements.
Here is the description from the module page:
Please note the article's publishing date. Some of the information presented below may not be current anymore.
With only a few critical issues left in the Drupal 8 queue and D8 being surprisingly usable, many developers already use it in small projects to play with the technology and to challenge themselves.
I have to admit, I am no exception - the embracement of many PHP technologies and (finally!) the jump to the OOP paradigm makes me want to stop writing right now and code some more.
I would wait a few months before creating bigger D8 projects for my clients. The community has to play some catching up first and port modules, themes and write documentation. On top of that, apart from all the OOP technologies we love, there have been some new drupalisms introduced and not documented yet - this combined with the lack of contributed module solutions makes D8 development much more time consuming for paid projects in comparison to D7.
Small projects however are very doable.
First however, it may be necessary to upgrade the server, as D8 introduces relatively high PHP and SQL requirements. See the official requirements page.
The Drupal 7 translation system including the internationalization package is a heavy beast and while it mostly gets the job done, it is all but intuitive in use.
For high volume translations it is recommended to use the translation template extractor and translate the strings externally. For small corrections however, it is often much more convenient to use the translation interface (admin/config/regional/translate/translate).
Now that you've created that shiny module/template and made it translatable by passing all strings through the t() function, you may be wondering why your newly created string is not showing up in the translate interface.
To save you some trouble, here is a short list of things to check:
1. Include the project version number within the module/theme .info file.
Without the project version information, the translate interface will not register new translatable strings in your module/theme. Make sure to add version = 7.x-1.0 into the module/template .info file.
2. Run the string through the function in a non-standard language mode.
In order for the translation system to add your translatable string, the t() function must run at least once in a non-standard language. To achieve that, you will need to switch the language of the site to one you are going to translate into and then visit the page that displays the string.
3. Mind the case sensitive search filter.
Be accurate when using the translate interface filter - it does not forgive.