We are always innocent, unless, from laziness or for convenience, we decide to overlook the novelty of the moment.
A simple module extending the default Reset password form.
When a visitor attempts to reset their password more than a number of times (configurable) - it's a sign they're sure they've registered before but can't remember the username and email they've used. To avoid further frustration, we show those visitors a message suggesting to contact customer support by calling a specific phone number for example.
After installing the module, configuration is available at:
Configuration -> People -> Account settings
In the previous part, we discussed about the Translation in Drupal 7 works with few snapshots and some makeovers. Now, lets discuss how to work with translation to translate the contents, field values and entity items.1) Translating Menus
With Drupal core alone, user-defined menu items are not translatable. The Menu translation module, part of the Internationalization (i18n) package, allows users to select a translation mode for each menu.
The following modes are available:
No Multilingual Options
Translate and Localize
There are two ways that menu items will be translated:
You can set a language when creating a custom menu item so that the menu item will only show up for that language. Menu items that link to nodes in a particular language will be treated this way.
You can localize other custom menu items without a language (for example, menu items linking to views pages). Use the Translate tab to translate the menu item title and description. Translators can also use the 'Translate interface' pages to translate these menu items.
Together with Fabian Franz from Tag1 Consulting, I had a session about Big Pipe in Drupal 8, as well as related performance/cacheability improvements.
I’ll let the session description speak for itself:
With placeholders (https://www.drupal.org/node/2478483) having just gone into Drupal 8 Core, BigPipe being unblocked now and actively making its way in, Render Strategies around the corner, and out-of-the-box auth-caching in CDNs + Varnish a true possibility on the horizon, those are really exciting times for Drupal 8 Performance. But there is even more …
Come and join us for a wild ride into the depths of Render Caching and how it enables Drupal to be faster than ever.The Masterplan of Drupal Performance (Next steps)
Here we will reveal the next steps of the TRUE MASTERPLAN of Drupal Performance. The plan we have secretly (not really!) been implementing for years and are now “sharing” finally with all of you! (Well you could look at the issue queue too or this public google doc, but this session will be more fun!)
Learn what we have in store for the future and what has changed since we last talked about this topic in Los Angeles and Amsterdam and why Drupal 8 will even be more awesome than what you have seen so far.
Also see a prototype of render_cache using the exact same Drupal 8 code within Drupal 7 and empowering you to do some of this in Drupal 7 as well.Get the edge advantage of knowing more
Learn how to utilize cache contexts to vary the content of your site, cache tags to know perfectly when items are expired and cache keys to identify the objects - and what is the difference between them.
Learn how powerful ‘#lazy_builders’ will allow the perfect ESI caching you always wanted and how it will all be very transparent and how you can make your modules ready for the placeholder future.
See with your own eyes how you can utilize all of that functionality now on your Drupal 7 and 8 sites.Get ready for a new area of performance
We will show you:
- How to take advantage of #lazy_builders
- How to tweak the auto-placeholdering strategies (depending on state of issue at time of session)
- The biggest Do’s and Don’ts when creating render-cache enabled modules and sites
- Common scenarios and how to solve them (mobile sites variation, cookie variation, etc.)
- Drupal using an intelligent BigPipe approach (but a different one, one that is way more like Facebook does it …)
This session will be presented by Wim Leers and Fabian Franz. Wim implemented a lot of what we show here in Drupal 8 and made the APIs easy and simple to use and made cache tags and #lazy_builders a very powerful concept. Fabian has prototyped a lot of this concepts in his render_cache module, introduced powerful Drupal 8 concepts into Drupal 7 and is always one step ahead in making the next big thing. Together they have set out on a crusade to rule the Drupal Performance world to bring you the fastest Drupal ever and with that trying to make the whole Web fast!Frequently Asked Questions
- I have already seen the session in Amsterdam and Los Angeles, will I learn something new?
Yes, absolutely. While the previous sessions focused more on the basics, this session will also cover how to use #lazy_builders and custom render strategies to empower your Drupal to be fast.
- Will there again be a demo?
Yes, there will again be a nice demo :). You’ll love it!
- Is it even possible to make it even faster than what we have seen?
Yes :)Slides: Making Drupal fly — The fastest Drupal ever is here!Conference: DrupalCon BarcelonaLocation: BarcelonaDate: Sep 23 2015 - 14:15Duration: 60 minutesExtra information:
Thank you to everyone who came out to jump in the group photo! Check us out.
Thank you to Petr Illek for making the timelapse!
We folks at undpaul love Drupal swag. At DrupalCon Amsterdam, we gave away over 500 shirts for free, which was a huge success.drupal planet english
Usually while we add contents to a div, it get arranged accordingly to our web styles. But there are some special cases where we need our contents to be arranged in a vertical manner as like the newspaper (or) journal content. To achieve this vertical fashion of content alignment, after a very long and vast search, we found these jQuery plugin to customize the column layouts dynamically based on these plugins:
Note: This can be easily acheived with the help of Bootstrap themes as in Drupal 7. These plugin are for the non-bootstrap theming to achieve this kind of result.
The columnizer plugin is such kind of plugin which aligns our content all into a adaptive layout, which is also responsive and kind of interesting too. It does provide us a lot of options to get our content aligned in the layout like newspaper material, journal like stuff and etc.
Now, let us know what's all we need to do are these. Just prepare all your html document and download the columnizer plugin from here
To use columnizer, just call the columnize() function on your jQuery selection, and that’s it! we are ready to go.
Drupal will soon be 15 years old, and 5 of that will be spent on building Drupal 8 -- a third of Drupal's life. We started work on Drupal early in 2011 and targeted December 1, 2012 as the original code freeze date. Now almost three years later, we still haven't released Drupal 8. While we are close to the release of Drupal 8, I'm sure many many of you are wondering why it took 3 years to stabilize. It is not like we didn't work hard or that we aren't smart people. Quite the contrary, the Drupal community has some of the most dedicated, hardest working and smartest people I know. Many spent evenings and weekends pushing to get Drupal 8 across the finish line. No one individual or group is to blame for the delay -- except maybe me as the project lead for not having learned fast enough from previous release cycles.Trunk-based development
The past 15 years we used "trunk-based development"; we built new features in incremental steps, maintained in a single branch called "trunk". We'd receive the feature's first patch, commit it to our main branch, put it behind us, and move on to the next patch. Trunk-based development requires a lot of discipline and as a community we have mostly mastered this style of development. We invested heavily in our testing infrastructure and established a lot of processes. For all patches, we had various people reviewing the work to make sure it was solid. We also had different people figure out and review all the required follow-up work to complete the feature. The next steps are carefully planned and laid out for everyone to see in what we call "meta" issues. The idea of splitting one large feature into smaller tasks is not a bad idea; it helps to make things manageable for everyone involved.
Given all this rigor, how do you explain the delays then? The problem is that once these features and plans meet reality, they fall apart. Some features such as Drupal 8's configuration management system had to be rewritten multiple times based on our experience using it despite passing a rigorous review process. Other features such as our work on URL routing, entity base fields and Twig templating required much more follow-up work compared to what was initially estimated. It turns out that breaking up a large task into smaller ones requires a lot of knowledge and vision. It's often impossible to estimate the total impact of a larger feature on other subsystems, overall performance, etc. In other cases, the people working on the feature lacked time or interest to do the follow-up work, leaving it to others to complete. We should realize is that this is how things work in a complex world and not something we are likely to change.
The real problem is the fact that our main branch isn't kept in a shippable state. A lot of patches get committed that require follow-up work, and until that follow-up work is completed, we can't release a new version of Drupal. We can only release as fast as the slowest feature, and this is the key reason why the Drupal 8 release is delayed by years.
Trunk-based development; all development is done on a single main branch and as a result we can only release as fast as the slowest feature.
We need a better way of working -- one that conforms to the realities of the world we live in -- and we need to start using it the day Drupal 8.0.0 is released. Instead of ignoring reality and killing ourselves trying to meet unrealistic release goals, we need to change the process.Feature branch workflow
The most important thing we have to do is keep our main branch in a shippable state. In an ideal world, each commit or merge into the main branch gives birth to a release candidate — it should be safe to release after each commit. This means we have to stop committing patches that put our main branch in an unshippable state.
While this can be achieved using a trunk-based workflow, a newer and better workflow called "feature branch workflows" has become popular. The idea is that (1) each new feature is developed in its own branch instead of the main branch and that (2) the main branch only contains shippable code.
Keeping the main branch shippable at all times enables us to do frequent date-based releases. If a specific feature takes too long, development can continue in the feature branch, and we can release without it. Or when we are uncertain about a feature's robustness or performance, rather than delaying the release, it will simply have to wait until the next release. The maintainers decide to merge in a feature branch based on objective and subjective criteria. Objectively, the test suite must pass, the git history must be clean, etc. Subjectively, the feature must deliver value to the users while maintaining desirable characteristics like consistency (code, API, UX), high performance, etc.
Feature branching; each feature is developed in a dedicated branch. A feature branch is only merged into the main branch when it is "shippable". We no longer have to wait for the slowest feature before we can create a new release.
Date-based releases are widely adopted in the Open Source community (Ubuntu, OpenStack, Android) and are healthy for Open Source projects; they reduce the time it takes for a given feature to become available to the public. This encourages contribution and is in line with the "release early, release often" mantra. We agreed on the benefits and committed to date-based releases following 8.0.0, so this simply aligns the tooling to make it happen.
Feature branch workflows have challenges. Reviewing a feature branch late in its development cycle can be challenging. There is a lot of change and discussion already incorporated. When a feature does finally integrate into main, a lot of change hits all at once. This can be psychologically uncomfortable. In addition, this can be disruptive to the other feature branches in progress. There is no way to avoid this disruption - someone has to integrate first. Release managers minimize the disruption by prioritizing high priority or low disruption feature branches over others.
Here is a workflow that could give us the best of both worlds. We create a feature branch for each major feature and only core committers can commit to feature branches. A team working on a feature would work in a sandbox or submit patches like we do today. Instead of committing patches to the main branch, core committers would commit patches to the corresponding feature branch. This ensures that we maintain our code review process with smaller changes that might not be shippable in isolation. Once we believe a feature branch to be in a shippable state, and it has received sufficient testing, we merge the feature branch into the main branch. A merge like this wouldn't require detailed code review.
Feature branches are also not the silver bullet to all problems we encountered with the Drupal 8 release cycle. We should keep looking for improvements and build them into our workflows to make life easier for ourselves and those we are implementing Drupal for. More on those in future posts.
* Menu Per User module is used to show/hide menu(s) per User.
* Install as you would normally install a contributed Drupal module. See:
for further information.
This post is part 3 in the series “Hashing out a docker workflow”. For background, checkout my previous posts.
Hola! On Tuesday the DrupalCon 2015 in Barcelona has officially started. It is the day when the lectures are starting, the group photo is to be shot and the first day after greetings, sprints and parties with the community...
Final thoughtsDrupal 8 is a game-changer and I’m excited about the possibilities - especially as the community grows around the world. Meanwhile, it’s back to youtube until I pass out on this no-frills DrupalCon experience - sad to be missing out on all the networking & fun times but sh*t happens, one lives and learns... ;) tags: drupalcondrupalDrupal PlanetPlanet Drupal
The Realityloop team is currently at DrupalCon Barcelona. During the opening keynote this morning Dries Buytart attempted to investigate several questions regarding Drupal's place at the moment.
In particular I was interested when he asked "Is Drupal losing momentum?", even before he continued I thought to myself that this is mostly people waiting on Drupal 8 to get released.
Looking at statistics he showed that this loss of momentum has ocurred in the past, as you can see in the image from Dries' slides shown below, Drupal lost momentum before the release of Drupal 7.
This is known as the Osbourne Effect which posits that "Announcement of a new release slows adoption of the current version." I know that we have clients that are contributing to this as I've had several discussions that start with "should I upgrade my site now or wait until Drupal 8 is released?".
This is a somewhat complex question that depends a large part on the functionality that is required by your site, the budget you have to invest towards module porting, and also the time at which the conversation took place.
The key thing is that after the release, at least since Drupal 6, there has always been a surge in adoption once the next version gets released.
As part of the core mentoring team I am a firm believer that you can predict this by looking at the number of contributors for each release:
- Drupal 5 - 472+ contributors
- Drupal 6 - 741+ contributors
- Drupal 7 - 950+ Contributors
- Drupal 8 - 3,000+ contributors
To me this indicates that there will be quite the surge once Drupal 8 is released, and the exciting news is that RC1 has now been scheduled for release on October 7th.
The Realityloop team is committed to Drupal, and although we are a team of 3, we've been involved in the development of over 100 contributed modules and are already scheduling time to begin work on porting many of the modules that still have a place in Drupal 8.
Drupal already powers close to 50% of the top 100,000 websites, and with one of the largest developer communities of any open source project I truly believe that once Drupal 8 goes stable there will be a surge in growth and a storm of really great sites for us to build.
If you have an upcoming project and would like to talk about building it with Drupal 8 or are interested in supporting the porting of any modules to Drupal 8, please do get in touch with me from October 4th:
- Brian Gilbert Ph +613 8609 6966
If you are interested in hearing more about Drupal 8 the Realityloop team are currently also organising Drupal Camp Melbourne, and unconference which will be held on November 27th and 28th 2015.
DrupalCon Barcelona. Day 2. The Annertech crew were up early (especially given our late night last night) and arrived at the convention centre. Here's our team's "best of the day" list - including one from Marta Paz, whom we've picked up as an honorary Annertechie for the week.
Mark "I loved the talk by Tim Millwood and Dick Olsson about revisions in Drupal 8. We see a lot of tenders for large projects asking for an "audit trail" and the approach being taken with multiversions/revisions looks very, very promising."
This tutorial is written for new drupal developers or php developers who want to learn drupal. You can find the part 1 of the tutorial here: tutorial part 1
Last time, we created a simple recipe module with save and load functionality. The user interface is not very friendly yet, and users have to enter a recipe id in the url to load it.
Today, we are going to improve the usability of the module by adding some UI element to it. By the end of the tutorial, you will be able to add, and...
When you are adding Views, you may have seen an extra option called "Delta".
Several students have asked us about the purpose of this field, because it wasn't clear.
The Delta option is available throughout the site, but ordinary users are most likely to encounter it inside Views. Here's how the "Delta" options appear in Views:
- Install and update the restws_schema Drupal 7 module per usual (ideally with Drush)
- Optionally enable restws_schema_ui module.
Removes Drupal's frontend, when using Drupal as a services layer only.
- Uninstalls frontend-only core modules (some are truly only useful when Drupal renders the frontend)
- For all other core modules, removes access to the paths only useful to Drupal's frontend
- Redirects disallowed paths to user login or, (if allowed) to the admin screen
- Properly redirects entity frontend paths to their corresponding edit screen
- Remaps breadcrumbs to match the new backend-only experience
To help avoid confusion when not using Drupal's built-in frontend.