Feed aggregator

DrupalCon News: 7 Things You Must Experience in India

Planet Drupal -

India is shaped by countless influences, from centuries old civilizations to modern day technology. In its long journey, the country has absorbed many different cultures, which have given it different dimensions. You must experience some of these when you come for DrupalCon Asia 2016. Here is a list of seven unique experiences that will make your trip worth remembering.

Darren Mothersele: How to Survive Gentrification of the Drupal Community

Planet Drupal -

We're finally approaching the release of Drupal 8.0.0 on 19th Nov. The biggest achievement of the Drupal community to date. A complete rewrite of the core system to use modern object-oriented PHP. An effort that is often referred to as "getting off the island".

While the switch from Drupal 7 to Drupal 8 is a big change for developers, it is the result of a slow process of maturation of the Drupal community. Drupal 8 brings changes that will be welcomed by many, will bring in many new users, and of course, will push a few people out. How can we survive this "gentrification" of the Drupal community and prosper without losing touch with why we loved Drupal in the first place.


Cities all over the world are becoming more exclusive, more expensive, and a natural result of this is gentrification. It's contentious. Some see this as urban improvement, some as social cleansing.

I moved to London nearly 12 years ago. Dalston, to be precise. I was back in Dalston this weekend for a party, and it's very different to how I remember it from 2004. I compared the nice clean overground train to the unreliable and dirty Silverlink trains that used to run to Dalston. Then, walking down Kingsland road without being on guard. When I lived there in 2004 it was often cordoned off by police. The hipsters, the trendy coffee shops, and other obvious signs of gentrification proliferate.

Brixton was my home for many years, and I witnessed first hand the results of gentrification. I had an office space in Brixton, and decided to leave it when the landlord announced he was increasing the rent by 25%. I lived in several flats around Brixton over the years, and eventually moved (a bit) further south as rental prices in Brixton soared. I say this with tongue in cheek, well aware that to many I'd be seen as one of the gentrifiers! It's the communities that settled here during the 1940s and 1950s that gave the area it's eclectic multi-cultural feel. They're the ones who have been displaced, losing their homes and community as developers and "yuppies" take over.

Gentrification of the Drupal Community

I first used Drupal back in 2003, version 4 point something. It was fun. Hacky, but fun. I had to quickly get a site up for an event we were organising and Drupal offered a collaborative content model that set it apart from the other produces we evaluated.

I came back to Drupal in 2007 for another community site build, and Drupal 5 had been released. It was really fun. Yes, still very hacky, but it came with the power to build a CMS exactly the way I wanted it to work, and it came with an awesome community of other hackers. A community of dedicated open-source types, who valued openness, and working on projects for good. I was hooked and made the leap to full time Drupal development. Through Drupal I got involved in the first social innovation camp, and other tech-for-good type things.

Szeged 2008 was my first Drupalcon. 500 Drupal contributors and users in a small university town in Hungary. Everyone I met truly cared about making Drupal an awesome project and was contributing time and effort in any way they could. Several years later and Drupalcon have grown. 2000+ attendees in Barcelona this year, 2300+ in Amsterdam last year. But, as the community has grown, so has the commercial influence. With sales pitches as prevalent as learning sessions on the schedule.

One thing I noticed this year was that several sessions concluded, or included, a call for donations or funding to accelerate a particular module or project's development. The precedent was set in the starting session of the conference when the Drupal Association made an announcement about the Drupal 8 accelerate funding programme. I'm not saying this is a bad thing. If this is what it takes to get Drupal finished in today's conditions, then that's great. But, look at it as an indicator of how the community has changed, when compared to the sessions at Szeged seven years earlier. You would not have seen a call for quarter of a million dollar funding back then. Everyone was there because they loved it, not because they were being paid.

Hacking the hackers

While doing research for this post, I came across this brilliant essay, The hacker hacked, by Brett Scott about the gentrification of hacker culture. I quote his summary of the gentrification process:

Key to any gentrification process are successive waves of pioneers who gradually reduce the perceived risk of the form in question. In property gentrification, this starts with the artists and disenchanted dropouts from mainstream society who are drawn to marginalised areas. This, in turn, creates the seeds for certain markets to take root. A WiFi coffeeshop appears next to the Somalian community centre. And that, in turn, sends signals back into the mainstream that the area is slightly less alien than it used to be.

If you repeat this cycle enough times, the perceived dangers that keep the property developers and yuppies away gradually erode. Suddenly, the tipping point arrives. Through a myriad of individual actions under no one person’s control, the exotic other suddenly appears within a safe frame: interesting, exciting and cool, but not threatening. It becomes open to a carefree voyeurism, like a tiger being transformed into a zoo animal, and then a picture, and then a tiger-print dress to wear at cocktail parties. Something feels ‘gentrified’ when this shallow aesthetic of tiger takes over from the authentic lived experience of tiger.
-- Brett Scott

How does this relate to the Drupal community? Perhaps it starts with the NGOs and charities, our original flagship Drupal sites, that became our "artists and disenchanted dropouts from mainstream society". Then the big media companies move in as the "perceived dangers gradually erode". Eventually, The White House start using Drupal, and we're at home with the large enterprise clients and big corporate contracts.

As the Drupal project developed the requirements changed. Drupal's capabilities improve, and the Drupal user base and community advanced too.

This is evident in the development, and standardisation of things like configuration management. Something that was never an issue in the early days, as the community became more professional, solutions for configuration management were hacked together, and then became standardised.

Configuration management is just one example of the many benefits the Drupal community has experienced through the process of gentrification. There's also great test coverage, performance improvements, greater tooling, and many other advancements that came to Drupal as the community matured. Drupal became less about hacking and more about software engineering.

Drupal 8

Development on Drupal 8 started in March 2011 and four years later, is to set to be released on November 19, 2015. Over these years, Drupal has been rewritten, removing most of the pre-OO era PHP legacy.

Drupal's legacy was the "not invented here" mindset that became entrenched in the community through hacking solutions to extensibility into a language that was not designed to support it. And, a culture of not depending on third-party code due to early well publicised security issues with PHP extensions.

The move away from this legacy, the move to "get off the island", is a move towards more standardised, modern, development practises, and a move to embrace the wider PHP community.

Social cleansing

I mentioned before that gentrification is contentious. For some see it as urban improvement, some as social cleansing. Drupal and the Drupal community have clearly benefitted already, and it looks like prosperous times ahead for those who come along for the ride, and the newcomers who join and adopt Drupal.

But, what about the social cleansing. Will parts of the community be pushed out? Who gets left behind?

Drupal has suffered from an identity crisis. Because of it's flexibility, it's been used for many things. Drupal's openness to hacking, extending and ability to do just about anything, meant it was more than just a CMS. Over the years many talked about "small core", many used Drupal's core tools as a Framework, building apps and tools well beyond what a typical CMS would be used for.

Drupal 8 is a content management system.

Drupal 8 focuses on content management, on providing tools for non-technical users to build and manage sites. That's what it always wanted to be anyway.

Drupal 8 leverages the wider PHP community, in particular the Symfony components, as it's core. It no longer makes sense to see Drupal as a framework.

One of the parts of the community being displaced, are those using Drupal as a framework. If this is you then you may already be looking at a fork, like Backdrop, or playing with other frameworks, like the beautiful Laravel.

Another section of the community that may be displaced are those running Drupal on low end and shared hosting. Through the gentrification process, Drupal's requirements have increased. The increased hosting requirements have meant that dedicated Drupal platform hosting providers have emerged. More options for scalability and custom software stacks have taken precedent over solutions for smaller websites.

Drupal also potentially loses the innovators. Drupal always had a reputation for being cutting edge and innovative. As it moves to become the enterprise choice of open-source CMS, innovation becomes less important, and stability, security, and backwards compatibility become more important. The biggest innovations in Drupal (flexible content types and Views) date back to the 4.7 era. Views is now in core in Drupal 8. As Drupal matures further from this point, we'll probably see Drupal adopting innovations from other systems and ecosystems, rather than innovating on it's own. It's well placed to do this now, built on Symfony components, innovations from the wider community will be easier to integrate.

Surviving Gentrification Do you abandon the form, leave it to the yuppies and head to the next wild frontier? Or do you attempt to break the cycle, deface the estate-agent signs, and picket outside the wine bar with placards reading "Yuppies Go Home"?
-- Brett Scott

Or, do come along for the ride? Enjoy the benefits of gentrification, without losing the reason why you got involved in the first place?

If you're going to stick around then you're going to need change a few things. Here's 5 steps that will get you started:

1. Learn the foundations that Drupal is now built on.

If (like me) you've got a background in OO then this shouldn't be too hard. I did several years of post-graduate research into semantics and verification of object-oriented software. You definitely don't need to go that deep, but I would highly recommend getting to grips with classic works on design patterns such as Gang of Four and Martin Fowler.

With a basic understanding of the core "patterns" of object-oriented software, you start to appreciate how Symfony works.

Drupal, Silex, Laravel, Symfony Full Stack, Symfony CMF, phpBB, Joomla, Magento, Piwik, PHPUnit, Sonata, and many more projects are built on this same foundation. So, it's definitely worth learning, and Drupal can be a good way to learn it, while still working with a system you know well.

Try building a simple app with Silex.

Check out Drupalcon (and Laracon) on YouTube. There's some great stuff. Like this talk from Ryan Weaver about Symfony and this talk by Ross Tuck about Models and Service Layers.

2. Do PHP the right way.

PHP has changed. There's a lot of outdated information and a lot of legacy code. Drupal 8 has been rewritten to remove this legacy code, but there's still a lot of bad advice on how to write PHP out there. Read PHP The Right Way for a full guide on how modern PHP should be crafted.

3. Use Composer, use and create PHP packages.

Getting off the island, and embracing the wider PHP ecosystem means using Composer, and it's ecosystem of PHP packages. There are many more packages that are potentially compatible with Drupal, and by architecting your Drupal extensions as more general PHP packages you have access to a much wider pool of potential collaborators.

Creating PHP packages also forces you to write clean code, think like a software engineer, and write more maintainable, extensible, and reusable code. Check out The PHP League as examples of solid PHP packages. They have a good Skeleton starting package.

You may have made custom Drupal modules before. Try thinking about how you can refactor these into separate packages, and using the Drupal "module" as a small layer that integrates your logic with Drupal.

The SOLID principles will guide you towards creating good packages.

4. Use an IDE

This was a big one for me. I was always against using an IDE, burnt by early experiences with open-source IDEs. I settled on a customised Sublime Text setup, and various other apps. I didn't see much benefit over using one app for everything when I could combine a selection of my favorite apps to do the same thing.

I'm not sure why I stuck to this. I also do a lot of C++ programming. I have my own programming language (Cyril) for creating audio-reactive visuals. I use XCode for C++ as the debugging tools are essential when you're dealing with object graphs, memory management, and debugging pointer issues. So, why not use an IDE for my web development?

I tried PHPStorm and it's great. Far from the cumbersome experience I had in the early days with open-source IDEs, it offers a smooth, fast, integrated experience.

I think you can get away without an IDE when you're hacking on Drupal 7, but on an OO system like Drupal 8 you will need an IDE. You will need the integrated tooling, testing, and you'll be much more efficient with intelligent autocompletion, hinting, quick access to docs, and fast navigation of the huge codebase.

5. Identify your values and serve your purpose.

As the corporates, enterprises, and big businesses take over, it's important to remain true to your yourself. By identifying your values you will be well placed to notice when they are being compromised.

You probably got into open-source because you believe in the power of collaboration. But, this value of collaboration can often be at odds with the cut-throat corporate culture of competition.

To be aware of this is to be aware of the opportunity to spread openness and collaboration with our work.

As the proceeds of Drupal's success flow into the community, it's important to use this to do good. To continue to serve our communities and society as a whole. To enable collaboration, share our work, and use openness to build the world we want.

Final thoughts

The real opportunity, is to spread Drupal's values of cooperation to the wider population.

This is part of a bigger shift in society to adopt open-source values, principles, and methodologies. Chris Anderson says it best:

If the past ten years have been about discovering new social and innovation models on the Web, then the next ten years will be about applying them to the real world.
-- Chris Anderson

The Work Open Manifesto offers a useful formulation of what it means to be open that can apply beyond open source software: "Think Big, Start Small, Work Open".

Drupal is great case study for starting small, thinking big, and working openly.

The Drupal community has always has been transforming, improving ourselves, improving the product, improving our practises, and improving our tools.

Now it's time to think beyond Drupal, beyond the Drupal community, and to see Drupal's values of collaboration, teamwork, and openness spread through the wider community, society, and the world.

Paul Johnson: Tell me your Celebr8D8 plans

Planet Drupal -


I am spearheading the Drupal 8 release celebrations on social media Thursday 19th November. Perhaps, like me, you have been working behind the scenes on a personal project to mark this significant occasion. If you have a website, special party, publicity stunt planned I'm keen to know about it. Come the big day I will use Drupal's social media and @Celebr8D8 to tell the world about your event, site, stunt.

Use my Drupal.org contact form to let me know about your release day plans. Thanks!

Drupal core announcements: Drupal core security release window on Wednesday, November 18

Planet Drupal -

Start:  2015-11-18 (All day) America/New_York Organizers:  David_Rothstein Event type:  Online meeting (eg. IRC meeting)

The monthly security release window for Drupal 6 and Drupal 7 core will take place on Wednesday, November 18.

This does not mean that a Drupal core security release will necessarily take place on that date for either the Drupal 6 or Drupal 7 branches, only that you should prepare to look out for one (and be ready to update your Drupal sites in the event that the Drupal security team decides to make a release).

There will be no bug fix/feature release on this date; the next window for a Drupal core bug fix/feature release is Wednesday, December 2 (and before that, on November 19, Drupal 8.0.0 is scheduled to be released).

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Krimson: 77 of us are going

Planet Drupal -

People from across the globe who use, develop, design and support the Drupal platform will be brought together during a full week dedicated to networking, Drupal 8 and sharing and growing Drupal skills. As we have active hiring plans we’ve decided that this year’s approach should have a focus on meeting people who might want to work for Wunderkraut and getting Drupal 8 out into the world. As Signature Supporting Partner we wanted as much people as possible to attend the event. We managed to get 77 Wunderkrauts on the plane to Barcelona!  From Belgium alone we have an attendance of 17 people. The majority of our developers will be participating in sprints (a get-together for focused development work on a Drupal project) giving all they got together with all other contributors at DrupalCon. We look forward to an active DrupalCon week.   If you're at DrupalCon and feel like talking to us. Just look for the folks with Wunderkraut carrot t-shirts or give Jo a call at his cell phone +32 476 945 176.

Krimson: Watch our epic Drupal 8 promo video

Planet Drupal -

Drupal 8 is coming and everyone is sprinting hard to get it over the finish line. To boost contributor morale we’ve made a motivational Drupal 8 video that will get them into the zone and tackling those last critical issues in no time.

Krimson: Open Monumentendag

Planet Drupal -

Once again Heritage day was a huge succes. About 400 000 visitors visited Flanders monuments and heritage sites last Sunday.  The Open Monumentendag website received more than double the amount of last year's visitors. Visitors to the website organised their day out by using the powerful search tool we built that allowed them to search for activities and sights at their desired location.  Not only could they search by location (province, zip code, city name, km range) but also by activity type, keywords, category and accessibility.  Each search request being added as a (removable) filter for finding the perfect activity. By clicking on the heart icon, next to each activity, a favorite list was drawn up.  Ready for printing and taking along as route map. Our support team monitored the website making sure visitors had a great digital experience for a good start to the day's activities. Did you experience the ease of use of the Open Monumentendag website?  Are you curious about the know-how we applied for this project?  Read our Open Monumentendag case.  

Krimson: Very proud to be a part of it

Planet Drupal -

Drupal Association Executive Director Holly Ross is thrilled that Wunderkraut is joining as first and says: "Their support for the Association and the project is, and has always been, top-notch. This is another great expression of how much Wunderkraut believes in the incredible work our community does." As Drupal Signature Supporting Partner we commit ourselves to advancing the Drupal project and empowering the Drupal community.  We're very proud to be a part of it as we enjoy contributing to the Drupal ecosystem (especially when we can be quircky and fun as CEO Vesa Palmu states). Our contribution allowed the Drupal Association to: Complete Drupal.org's D7 upgrade - now they can enhance new features Hired a full engineering team committed to improving Drupal.org infrastructure Set the roadmap for Drupal.org success.

Krimson: Adapting solutions based on client input

Planet Drupal -

But in this post I'd like to talk about one of the disadvantages that here at Wunderkraut we pay close attention to. A consequence of the ability to build features in more than one way is that it's difficult to predict how different people interact (or want to interact) with them. As a result, companies end up delivering solutions to their clients that although seem perfect, turn out, in time, to be less than ideal and sometimes outright counterproductive.  Great communication with the client and interest in their problems goes a long way towards minimising this effect. But sometimes clients realise that certain implementations are not perfect and could be made better. And when that happens, we are there to listen, adapt and reshape future solutions by taking into account these experiences.  One such recent example involved the use of a certain WYSIWYG library from our toolkit on a client website. Content editors were initially happy with the implementation before they actually started using it to the full extent. Problems began to emerge, leading to editors spending way more time than they should have performing editing tasks. The client signalled this problem to us which we then proceed to correct by replacing said library. This resulted in our client becoming happier with the solution, much more productive and less frustrated with their experience on their site.  We learned an important lesson in this process and we started using that new library on other sites as well. Polling our other clients on the performance of the new library revealed that indeed it was a good change to make. 

Krimson: A brief history of Support at Wunderkraut Benelux

Planet Drupal -

A few years ago most of the requests started with : "Dear Wunderkraut, we want to build a new website and ... "  - nowadays we are addressed as "Dear Wunderkraut, we have x websites in Drupal and are very happy with that, but we are now looking for a reliable partner to support & host ... ". By the year 2011 Drupal had been around for just about 10 years. It was growing and changing at a fast pace. More and more websites were being built with it. Increasing numbers of people were requesting help and support with their website. And though there were a number of companies flourishing in Drupal business, few considered specific Drupal support an interesting market segment. Throughout 2011 Wunderkraut Benelux (formerly known as Krimson) was tinkering with the idea of offering support, but it was only when Drupal newbie Jurgen Verhasselt arrived at the company in 2012 that the idea really took shape. Before his arrival, six different people, all with different profiles, were handling customer support in a weekly rotation system. This worked poorly. A developer trying to get his own job done plus deal with a customer issue at the same time was getting neither job done properly. Tickets got lost or forgotten, customers felt frustrated and problems were not always fixed. We knew we could do better. The job required uninterrupted dedication and constant follow-up. That’s where Jurgen came in the picture. After years of day job experience in the graphic sector and nights spent on Drupal he came to work at Wunderkraut and seized the opportunity to dedicate himself entirely to Drupal support. Within a couple of weeks his coworkers had handed over all their cases. They were relieved, he was excited! And most importantly, our customers were being assisted on a constant and reliable basis. By the end of 2012 the first important change was brought about, i.e. to have Jurgen work closely with colleague Stijn Vanden Brande, our Sys Admin. This team of two ensured that many of the problems that arose could be solved extremely efficiently. Wunderkraut being the hosting party as well as the Drupal party means that no needless discussions with the hosting took place and moreover, the hosting environment was well-known. This meant we could find solutions with little loss of time, as we know that time is an important factor when a customer is under pressure to deliver. In the course of 2013 our support system went from a well-meaning but improvised attempt to help customers in need to a fully qualified division within our company. What changed? We decided to classify customer support issues into: questions, incidents/problems and change requests and incorporated ITIL based best practices. In this way we created a dedicated Service Desk which acts as a Single Point of Contact after Warranty. This enabled us to offer clearly differing support models based on the diverse needs of our customers (more details about this here). In addition, we adopted customer support software and industry standard monitoring tools. We’ve been improving ever since, thanks to the large amount of input we receive from our trusted customers. Since 2013, Danny and Tim have joined our superb support squad and we’re looking to grow more in the months to come. When customers call us for support we do quite a bit more than just fix the problem at hand. Foremostly, we listen carefully and double check everything to ensure that we understand him or her correctly. This helps to take the edge off the huge pressure our customer may be experiencing. After which, we have a list of do’s and don’t for valuable support. Do a quick scan of possible causes by getting a clear understanding of the symptoms Do look for the cause of course, but also assess possible quick-fixes and workarounds to give yourself time to solve the underlying issue Do check if it’s a pebkac and finally, do test everything within the realm of reason. The most basic don’t that we swear by is: never, ever apply changes to the foundation of a project. Support never covers a problem that takes more than two days to fix. At that point we escalate to development. We are so dedicated to offering superior support to customers that on explicit request, we cater to our customers’ customers. Needless to say, our commitment in support has yielded remarkable  results and plenty of customer satisfaction (which makes us happy, too)

Krimson: I'm running Drupal 6, what do I do?

Planet Drupal -

If your website is running Drupal 6, chances are it’s between 3 and 6 years old now, and once Drupal 8 comes out. Support for Drupal 6 will drop. Luckily the support window has recently been prolonged for another 3 months after Drupal 8 comes out. But still,  that leaves you only a small window of time to migrate to the latest and greatest. But why would you?  There are many great things about Drupal 8 that will have something for everyone to love, but that should not be the only reason why you would need an upgrade. It is not the tool itself that will magically improve the traffic to your site, neither convert its users to start buying more stuff, it’s how you use the tool.   So if your site is running Drupal 6 and hasn’t had large improvements in the last years it might be time to investigate if it needs a major overhaul to be up to par with the competition. If that’s the case, think about brand, concept, design, UX and all of that first to understand how your site should work and what it should look like, only then we can understand if a choice needs to be made to go for Drupal 7 or Drupal 8.   If your site is still running well you might not even need to upgrade! Although community support for Drupal 6 will end a few months after Drupal 8 release, we will continue to support Drupal 6 sites and work with you to fix any security issues we encounter and collaborate with the Drupal Security Team to provide patches. My rule of thumb is that if your site uses only core Drupal and a small set of contributed modules, it’s ok to build a new website on Drupal 8 once it comes out. But if you have a complex website running on many contributed and custom modules it might be better to wait a few months maybe a year until all becomes stable. 

Krimson: Introduction to customer journey mapping

Planet Drupal -

So how does customer journey mapping work? In this somewhat simplified example, we map the customer journey of somebody signing up for an online course. If you want to follow along with your own use case, pick an important target audience and a customer journey that you know is problematic for the customer. 1. Plot the customer steps in the journey   Write down the series of steps a client takes to complete this journey. For example “requests brochure”, “receives brochure”, “visits the website for more information”, etc. Put each step on a coloured sticky note. 2. Define the interactions with your organisation Next, for each step, determine which people and groups the customer interacts with, like the marketing department, copywriter and designer, customer service agent, etc. Do the same for all objects and systems that the client encounters, like the brochure, website and email messages. You’ve now mapped out all people, groups, systems and objects that the customer interacts with during this particular journey. 3. Draw the line Draw a line under the sticky notes. Everything above the line is “on stage”, visible to your customers. 4. Map what happens behind the curtains   Now we’ll plot the backstage parts. Use sticky notes of a different color and collect the persons, groups, actions, objects and systems that support the on stage part of the journey. In this example these would be the marketing team that produces the prod brochure, the printer, the mail delivery partner, web site content team, IT departments, etc. This backstage part is usually more complex than the on stage part. 5. How do people feel about this? Now we get to the crucial part. Mark the parts that work well from the perspective of the person interacting with it with green dots. Mark the parts where people start to feel unhappy with yellow dots. Mark the parts where people get really frustrated with red. What you’ll probably see now is that your client starts to feel unhappy much sooner than employees or partners. It could well be that on the inside people are perfectly happy with how things work while the customer gets frustrated. What does this give you? Through this process you can immediately start discovering and solving customer experience issues because you now have: A user centred perspective on your entire service/product offering A good view on opportunities for innovation and improvement Clarity about which parts of the organisation can be made responsible to produce those improvements In a shareable format that is easy to understand Mapping your customer journey is an important first step towards customer centred thinking and acting. The challenge is learning to see things from your customers perspective and that's exactly what a customer journey map enables you to do. Based on the opportunities you identified from the customer journey map, you’ll want to start integrating the multitude of digital channels, tools and technology already in use into a cohesive platform. In short: A platform for digital experience management! That's our topic for our next post.

Krimson: Taming Facet API paths

Planet Drupal -

In combination with the FacetAPI module, which allows you to easily configure a block or a pane with facet links, we created a page displaying search results containing contact type content and a facets block on the left hand side to narrow down those results. One of the struggles with FacetAPI are the URLs of the individual facets. While Drupal turns the ugly GET 'q' parameter into a clean URLs, FacetAPI just concatenates any extra query parameters which leads to Real Ugly Paths. The FacetAPI Pretty Paths module tries to change that by rewriting those into human friendly URLs. Our challenge involved altering the paths generated by the facets, but with a slight twist. Due to the projects architecture, we were forced to replace the full view mode of a node of the bundle type "contact" with a single search result based on the nid of the visited node. This was a cheap way to avoid duplicating functionality and wasting precious time. We used the CTools custom page manager to take over the node/% page and added a variant which is triggered by a selection rule based on the bundle type. The variant itself doesn't use the panels renderer but redirects the visitor to the Solr page passing the nid as an extra argument with the URL. This resulted in a path like this: /contacts?contact=1234. With this snippet, the contact query parameter is passed to Solr which yields the exact result we need. /** * Implements hook_apachesolr_query_alter(). */ function myproject_apachesolr_query_alter($query) { if (!empty($_GET['contact'])) { $query->addFilter('entity_id', $_GET['contact']); } } The result page with our single search result still contains facets in a sidebar. Moreover, the URLs of those facets looked like this: /contacts?contact=1234&f[0]=im_field_myfield..... Now we faced a new problem. The ?contact=1234 part was conflicting with the rest of the search query. This resulted in an empty result page, whenever our single search result, node 1234, didn't match with the rest of the search query! So, we had to alter the paths of the individual facets, to make them look like this: /contacts?f[0]=im_field_myfield. This is how I approached the problem. If you look carefully in the API documentation, you won't find any hooks that allow you to directly alter the URLs of the facets. Gutting the FacetAPI module is quite daunting. I started looking for undocumented hooks, but quickly abandoned that approach. Then, I realised that FacetAPI Pretty Paths actually does what we wanted: alter the paths of the facets to make them look, well, pretty! I just had to figure out how it worked and emulate its behaviour in our own module. Turns out that most of the facet generating functionality is contained in a set of adaptable, loosely coupled, extensible classes registered as CTools plugin handlers. Great! This means that I just had to find the relevant class and override those methods with our custom logic while extending. Facet URLs are generated by classes extending the abstract FacetapiUrlProcessor class. The FacetapiUrlProcessorStandard extends and implements the base class and already does all of the heavy lifting, so I decided to take it from there. I just had to create a new class, implement the right methods and register it as a plugin. In the folder of my custom module, I created a new folder plugins/facetapi containing a new file called url_processor_myproject.inc. This is my class: /** * @file * A custom URL processor for cancer. */ /** * Extension of FacetapiUrlProcessor. */ class FacetapiUrlProcessorMyProject extends FacetapiUrlProcessorStandard { /** * Overrides FacetapiUrlProcessorStandard::normalizeParams(). * * Strips the "q" and "page" variables from the params array. * Custom: Strips the 'contact' variable from the params array too */ public function normalizeParams(array $params, $filter_key = 'f') { return drupal_get_query_parameters($params, array('q', 'page', 'contact')); } } I registered my new URL Processor by implementing hook_facetapi_url_processors in the myproject.module file. ** * Implements hook_facetapi_url_processors(). */ function myproject_facetapi_url_processors() { return array( 'myproject' => array( 'handler' => array( 'label' => t('MyProject'), 'class' => 'FacetapiUrlProcessorMyProject', ), ), ); } I also included the .inc file in the myproject.info file: files[] = plugins/facetapi/url_processor_myproject.inc Now I had a new registered URL Processor handler. But I still needed to hook it up with the correct Solr searcher on which the FacetAPI relies to generate facets. hook_facetapi_searcher_info_alter allows you to override the searcher definition and tell the searcher to use your new custom URL processor rather than the standard URL processor. This is the implementation in myproject.module: /** * Implements hook_facetapi_search_info(). */ function myproject_facetapi_searcher_info_alter(array &$searcher_info) { foreach ($searcher_info as &$info) { $info['url processor'] = 'myproject'; } } After clearing the cache, the correct path was generated per facet. Great! Of course, the paths still don't look pretty and contain those way too visible and way too ugly query parameters. We could enable the FacetAPI Pretty Path module, but by implementing our own URL processor, FacetAPI Pretty Paths will cause a conflict since the searcher uses either one or the other class. Not both. One way to solve this problem would be to extend the FacetapiUrlProcessorPrettyPaths class, since it is derived from the same FacetapiUrlProcessorStandard base class, and override its normalizeParams() method. But that's another story.


Subscribe to Cruiskeen Consulting LLC aggregator