We are here on earth to do good for others. What the others are here for, I don't know.
Apachesolr Display module allows us to output search results as node display. This module store rendered entity or entity json encoded object inside solr index without affecting solr search speed. There are settings yoursite.com/admin/config/search/apachesolr/search-pages/your-search-page/edit.
Storing whole node object
advantages: no additional search results styling needed.
disadvantages: solr index become bigger, executed node_view().
This simple module adds support to your site to block HTTP POST requests that are not associated with form submissions. This is useful for reducing the potential for attackers to bypass your caching infrastructure by making HTTP POST Requests for pages of your site.
DrupalCon is the heart and soul of the Drupal Community. Thousands of us have attended over the past 9 years. Many of us, myself included, have had life-changing experiences at DrupalCon. How did DrupalCon change your life? Now is the time to share your story with thousands of your closest friends! ... or the Drupal community.
What is this for? It's for the "Prenote" session at DrupalCon Amsterdam. Every DrupalCon, Jam and I collaborate to show some aspect of the Drupal experience through humor, drama, song, cheesy costumes, and famous Drupal guest stars. We'd like to include some of these stories in Amsterdam!
Thanks for sharing!Which DrupalCon? * Austin, 2014 Prague, 2013 Portland, 2013 Sydney, 2013 Munich, 2012 Denver, 2012 London, 2011 Chicago, 2011 Copenhagen, 2010 San Francisco, 2010 Paris, 2009 Washington, D.C., 2009 Szeged, 2008 Boston, 2008 Barcelona, 2007 Sunnyvale, 2007 Brussels, 2006 Vancouver, 2006 Amsterdam, 2005 Portland, 2005 Antwerp, 2005 Which DrupalCon changed your life? Tell your story * What happened that changed your life? Was it meeting a specific person? Attending a session? Being in the right place at the right time? What aspect of your life now would not have been the same if you hadn't attended DruaplCon. Will you be attending DrupalCon Amsterdam? * Yes No E-mail * Skype or phone How can we contact you? What's your Skype ID or phone number?
Field Group Background Image module creates a field group display formatter that consists in a <div> wrapper with a background image. The source of the image is set from an image field of the entity being displayed.
By default, Drupal defines the "administer users" permission, which allows users of a given role to edit all users.
This module provides developers with a hook they can implement to allow certain users (which normally don't have the "administer users" permission) to edit particular users.
The latest rage in the Content Management world is the idea of a “decoupled CMS.” That is, rather than having a single monolithic system that handles everything from content entry to management to display and theming in one program spread, that responsibility is assigned to different systems: one that is really really good at content storage, one that's really really good at content management, one that's really really good at display and theming, etc.
At the same time, there has been a huge push for web services in almost every market. If you want content to be available anywhere besides an HTML page, then your answer is web services.
Drupal 8 will make huge strides in this area, but alas it's not out yet. Fortunately the answer to the second problem is the first; it is entirely possible to build a solid, scalable, performant RESTful web service with Drupal 7 by decoupling Drupal from the web service.
Recently, Palantir.net did exactly that for a major media client, video hosting service Ooyala, and it really drove home both the power of web services and the potential of a decoupled architecture.The Problem
Ooyala wanted us to build a video curation service for one of their customers.
The first part of the problem was that the customer had data that was regularly updated, but this existing data source was incomplete, occasionally unreliable, and could be enriched with additional metadata, so human management was required before it could be used in the desired context (to describe video content in end-user-facing video-on-demand applications). The solution to this particular problem was the CMS.
The second part of the problem was getting the data in the desired context: highly interactive video-on-demand applications where users could purchase access to individual movies or episodes, collections of movies, seasons of a show, or other arbitrary groupings. The solution here was a REST API separated from the CMS.
Not complex enough? Add in a requirement to merge in data from a third-party video service to compensate for incomplete data.
Make available the fields and text properties from referenced entities into the parent entity template and the manage fields display overview.Features
- You can control, for each compatible reference field instances, if the fields from the referenced entities would be available as extra fields. Disabled by default.
- You can manage the visibility of the referenced entities fields on the manage display form. Hidden by default.
Developers, take note: the upcoming Alt Ctrl Game Jam is an online 10-day game jam about experimenting with alternative controls in game design, and it starts September 12th. ...
This adventure presents a straightforward investigation and 'puzzle dungeon' aimed at mid-level (8-10) characters. Set in an arid desert environment, it begins with an encounter where passing nomads save the day, and then invite the party to visit their village.
Everything is well-described and atmospheric, with the scene being well-set by clear details and plenty of those little details that make everything come to life. Naturally, just as the party is getting to know people, something goes wrong during a traditional religious ceremony. Opportunities are presented for them to investigate and to talk to villagers before they are inevitably led towards the dungeon that awaits them... indeed, in many ways this is pretty 'old school' in concept.
The dungeon itself is laid out in considerable detail, and hangs together well (essential if a 'puzzle' dungeon is going to work for the party). The GM is provided with an overview map and more detailed ones of particular areas, whilst a mappack full of battlemaps and further plans is provided with the download to make life easier for those who like to use miniatures or at least show the players what their characters see rather than merely describe it to them. Due to the nature of the dungeon, however, it is suggested that the party be encouraged to map it for themselves.
If the dungeon itself is not confusing enough, there's an ingenious puzzle room buried in its depths which should challenge even seasoned adventurers. When all is explored and the reasons why behind what is going on have been revealed, there are a few options for continuing the plot - or, of course, the party may prefer to take their loot and continue the adventure elsewhere.
Well-presented (although the background is at times a little dark to provide adequate contrast to the text) and well-resourced, the adventure is a little bit linear, and not everybody likes puzzle dungeons - although at leaast this one makes overall sense both in structure and in the rationale for it being there - but ought to provide good entertainment.
I was given a problem: the (somewhat usual) error message showed up Warning: Invalid argument supplied for foreach() in element_children() (line 6396 of common.inc).. Trying to debug it with the usual print-and-see is entirely and totally hopeless. If you print just $elements from element_children? You get picture. If you try to print the backtrace? It's impossibly big. One hope is printing the backtrace with DEBUG_BACKTRACE_IGNORE_ARGS and then manually opening up every step in the rather big backtrace. Or you can set a conditional breakpoint on the problematic line with !is_array($elements) as a condition and immediately have access to the backtrace in a very nice structured/collapsed format where you can see the parent, grandparent etc render arrays, reach every caller with one click and eventually find this in a template:
<?php foreach ($content as $key => $item): ?>
<?php print render($item); ?>
I have worked for years without a debugger -- finding this without is really frustrating and slow. Finding it with one is a matter of minutes. And PhpStorm debugger is literally zero config.
You know how every box of LEGO® comes with that pretty picture on the front of what it’s supposed to look like at the end...and how you might build it that way once, just once, to see how it looks, before tearing it down and making a spaceship out of the oxcart? It’s the same with websites. We all start off with this great picture in our mind of what a website will look like. And yes, the website might actually make it to that glorious utopia...until someone decides, no, they don’t actually like that thing there. No, this should be bigger. Or smaller. “I know I asked for an oxcart, but please tear it down and make a spaceship out of it.”
At 4Site, when we go about ‘designing’ a website, we think of the website as a sum of parts--planning ahead to how the site’s going to look at the end, how it’s going to feel. It’s not just a set of fields that then get some css (or scss!) and js/php applied. It’s something that’s eventually going to be touched by dozens, hundreds, thousands of people, both as users and as content managers behind the scenes. It’s something that needs to be flexible. Something that can move on the fly, something that can be used on a wide-variety of platforms, in a variety of uses, by a variety of users. Something easy. Something modular.
That’s the beauty of Drupal and other modular CMS. You can take these pieces and make damn near anything out of them. So where is this metaphor leading? You need a great workflow to start, a great system to work within. You need your giant tub of pieces.
Once you have your basic “what do we need?” question answered, you can expand on what else you might want. The beauty of Drupal is that you have this extraordinarily flexible system--you can modify your content types on the fly. You can add taxonomies if you want to suggest related content to users. Your layouts are flexible, so you can use them to organize all types of content, albeit with a few minor tweaks. Add some fields to your content types and you can build a brand new view. Add some taxonomy terms and you can link your leaders together and allow them to connect with people that share the same interests.
The point of this is that you need the pieces first. To build a spaceship, you need to start with the 4x4 squares, the crystal cylinder things, and the LEGO® head with the 70s hair. It’s the same with websites. Karen McGrane says to use chunks, not blobs. So you break down your content into consistent and logical pieces. And that will give you the most flexibilty on the back end to organize and display that information, for different audiences, on different platforms, and over time as your needs evolve.
What don’t you want to do? You don’t cram every last bit of information you have into a WYSIWYG, because if you need it later, too bad, you’re writing it again. That would be akin to gluing your LEGO® together. If you ever want to use those pieces for anything else, too bad.
If you had a custom field or post type, you’ve got that piece already at your fingertips, ready for use wherever and whenever you want. You need that information later? No worries, it’s a custom post type. It’s a taxonomy reference. It’s right there in front of you. You decide you want your author on something else? It’s a term reference. An entity reference. A node reference.
So go build your castle or spaceship, your saloon or alien moon-base. Just make sure you have your big tub of pieces first, in case you decide later you want to add a mean laser cannon on the top. Or a Mars rover. I don’t know. You're the designer.
We just provide the pieces.
This blog post is an extrapolation of a session I presented at FuseCon 2014. Please let us know if you'd like any help sorting out your content into manageable, reuseable pieces.
The problems we've seen these past weeks are all born out of fear. And fear is often born from the potential of losing something. ...
The Drupal community's commitment to cooperation and sharing is one of its defining characteristics, and the Drupal Extension to Behat and Mink is a powerful example of that cooperation in action. It is not a Drupal module. Rather, it extends the functional testing framework of Behat and Mink in order to provide Drupal-specific functionality. You'll find its detailed documentation at Read the Docs.
The extension helps site builders automate tests for Drupal 6, 7, and 8 without having to write custom code for common Drupal features. It currently provides support in three major areas: setting up test data, mapping page regions, and auto-discovery of Behat tests provided by modules and themes.Setting Up Test Data
To test any Drupal site, at some point you'll need to set up test data. You can do this in a blackbox fashion, using pre-built steps to create a user – and log in via the interface – then fill out the appropriate form. This approach takes time to write, time to run, and becomes tedious to read. Adding data in this detailed way is warranted at times, but you're typically better off inserting data as a single step in the Given section of your scenario. The Drupal extension provides a driver system to help you.Blackbox
The default driver assumes you have no privileged access to the Drupal site. All your data setup has to take place through the normal user interface. The blackbox driver exists so you can benefit from other Drupal Extension features.Drupal API
When your tests run on the same machine as your Drupal installation, you can use the Drupal API directly to create users, nodes, taxonomy vocabularies, and taxonomy terms, without writing any supporting PHP code and without the tedium of blackbox steps. To do so, you configure your testing instance to point at the local path to the Drupal site, tag the scenario with @api, and then use pre-built steps.@api Scenario: Given I am viewing “article” node with the title “Drupal API”