After a great week in Bogota and some time to reflect I can say the first DrupalCon in Latin America was even better than I expected - yes it did feel more like a DrupalCamp than a DrupalCon - but it was still a great event! The quality of sessions were very good and as usual the greatest part was the chance to get together with a lot of friends from all over and especially Latin America.
Here my highlights:Training:
Our Community Trainings - Intro to Symfony, Getting Ready for D8
This is the first article of a long series (I hope :P ). Every Wednesday we get to know a new module, little known or just published on the Drupal official web site.
In this article we will review Focal Point.
In the first two installments of this series we looked at a general introduction to creating WOW with Drupal and adding some "Technical Wow". Today's let's tackle ...Creating Wow - Aesthetic
This is part 3 of a 5 part series. Read the rest of the series here.
Can you help Fuzion take the Drupal 8 integration module that was developed as part of 2014 Google Summer of Code and get it working with the most recent version of Drupal 8 and publicly available for testing?
Getting CiviCRM ready for Drupal 8 was always going to be a task with many stages. Thanks to the funding from the Google Summer of Code 2014 in August last year Torrance, was able to get CiviCRM functioning well on what was then the latest alpha of Drupal 8. Highlights of this work included a native, Drupal-side installer for CiviCRM, Views integration using CiviCRM to discover the database schema (cutting the Views module from 15,000 lines to code to under 2,000), and a set of integration tests for both CiviCRM and Views.
But as Drupal 8 has continued active development, many core APIs have changed and ….. the integration has regressed.
Lots of these changes are relatively minor: during alpha there were still plenty of structured arrays hanging around which have now mostly been moved into well defined interfaces; or similarly plenty of hard dependencies on object classes have been abstracted into interfaces. There’s also been a few slightly more significant code changes, with several hooks that were still hanging around having been pulled into the new plugin system for example.
Drupal 8 is now at beta 6 and is becoming much more stable; APIs have settled down and the code churn is much reduced. Now is a good time to work through the existing Drupal 8 integration code, update function signatures to match the new interfaces, and get CiviCRM working correctly on Drupal 8.
By getting through this next tranche of work we can set the ground for thorough testing of the module in the lead up for Drupal 8.0 final.
Fuzion is proposing to fund 1 hour for every 4 hours funded for the next tranche of 50 hours of work (our estimate for getting Drupal and CiviCRM playing nicely enough that we can get this pushed out). So yes we are looking for others in the CiviCRM community to chip in and help fund this important work to make sure CiviCRM is set for Drupal 8.
Can you help us push on with this next stage so we can get the integration available for public testing? If so please drop by this page and chip in.
NTEN’s Nonprofit Technology Conference is nearly upon us! We’re gearing up to ship out to Austin, and we’re putting the finishing touches on Drupal Day. This is one of our favorite events of the year, as it’s when we get to meet up with many of our nonprofit partners, learn about new organizations and their causes, and share our expertise with the folks that need it to further their missions. We’re especially excited about the Drupal Day we’ve been coordinating for the last several months.
What’s Drupal Day? Well, the name pretty much gives it away, but specifically, it’s a full-day, pre-conference event that we’ve been organizing for the past few years. It’s full of Drupal trainings, discussions, and nonprofit technology staff sharing their successes with their community. Breakout session topics vary from content strategy, accessibility, fundraising, CRMs, design, and more, all led by Drupal experts. The day concludes with our keynote presentation on the future of Drupal and Drupal 8 by Zack Rosen, CEO of Pantheon. All Drupal Day attendees and speakers are invited to join us for a sponsored Happy Hour at the Brass House that evening. Want to stay in the loop on Twitter? Look for the hashtag #15NTCDrupal. Of course, Drupal Day wouldn’t be possible without the help of its co-sponsors, Aten Design, Forum One, Gorton Studios, Message Agency, and Zivtech.
That’s not all we’re up to, though. This year, you can find the ThinkShout team at booth #301 in the Science Fair on Wednesday and Thursday. Our friends at MailChimp couldn’t attend the NTC this year, but they made sure you wouldn’t go home empty handed. Stop by our booth for your NTC MailChimp swag, and come talk to us about how we’re integrating Drupal with MailChimp. We’ve also got a few ThinkShout goodies we’ll be handing out, so be sure to stop by. We’re happy to discuss just about anything under the sun.
This has been a big year so far for ThinkShout’s open source contributions. We’re particularly thrilled about our recent release of RedHen Raiser, the first peer-to-peer fundraising tool built on Drupal and RedHen. This is something we’re very excited to share with the nonprofit world, and we’d love to talk to you more about it at our booth.
You'll also be able to see some of the ThinkShout team in action as part of the NTC programming. On Thursday, March 5th, catch Lev Tsypin on the panel "Sync All the Things! How Progressive Nerds are Changing the Future of Political Data and Integration" at 3:30 p.m. On Friday, March 6th at 10:30 a.m., Brett Meyer will be co-leading the session “Content Strategy 101” with Katie Carrus from the Humane Society Legislative Fund. Brett will also be co-leading the session “Managing a Tech Project (Or Two or Three)” with Lisa Goddard from the Capital Area Food Bank of Texas, Melissa Barber and Brian Pickett from North Peak Solutions on March 5th at 1:30 p.m.
Don’t forget to follow us on Twitter @ThinkShout for our real time updates. Feel free to tweet us questions, or just say hi! (You can totally do that in person, too.) We’ll see you in Austin!
OK, so you are a site builder or a privileged role building a view. In the preview you see a certain result set, but regular and/or anonymous users see only subset of those results or no results at all.
You checked all your basics. Views permissions look good; Content permissions look correct as well. You double checked above by previewing nodes included in the view (same for related nodes if any) as a regular or anonymous user. But, alas, they are not seeing expected view results. This issue caused me a lot of grief and made me believe in gremlins for a minute, so I hope this blog post saves you some time and few gray hairs.
If you are experiencing similar issue and your case meets the following criteria:
- You are using entityreference module and there is a relationship between two entities via field entity reference.
- Your view includes those entities and joins the tables via relationship.
- You use one of the modules that works with node_access (e.g. content_access, og_access etc.). You can check node_access table in the database and if you see more than one entry in that table, you meet this criteria.
- Entity reference field which you use to form view relationship between your entities is not a required field and there are some nodes without reference.
Then this post applies to your case (skip to the bottom for solution).
In my scenario this occurred, during local testing of a D7 to D7 migration and the offending content and view worked just fine on the source D7 website. Same versions of core and all modules involved. To make things more interesting that view was a services_view and was used to generate RESTish endpoint. I had no obvious suspects. It can be many different things. Could be a bug in services, views, entityreference or something getting lost during migration. It is my first time writing migration scripts so it's very likely. Least suspicious in that list is Drupal core. This somewhat complex relationship clouds my google foo and I'm not really finding much. I scanned through each of the module's issue queues, but I'm failing to find anything similar to issues I am having. This increased my suspicions that it is probably something with my migration scripts.
It was time to roll up the sleeves and get the good ole step debugger and follow drupal execution path, recursive calls, inspect memory and generated queries on both websites and find out what's different. After hours of staring at code, refining breakpoints and looking at different drupal configs and maze of join queries I noticed something. Destination D7 had one of the subqueries altered via node_query_node_access_alter while the source didn't. In addition, this is where the query checked for existence of referenced entity's id, but didn't check for null values. Given that my view didn't enforce relationship, this was a drupal core bug.
If we have a left join, that is 'Require this relationship' is not checked (inner join otherwise), then the null value for referenced entity should be a valid one. Awesome, I need to write a core patch and check for this condition. This is super exciting. My first core contribution, my time to shine... Before I submit a new core issue and a patch, let me look at the existing queue and see if someone posted about it there. Now that I know what I'm looking for it only takes one search and I find the issue from 2 years ago: https://www.drupal.org/node/1969208.
The Drupal community delivers again. While I was a bit disappointed that I didn't get to write the patch, I found some consolation in the fact that I wasn't the only one struggling to figure this one out. Couple of days after I found this, one of the teams at Metal Toad ran into the same issue on a different project so I was able to help there as well.
While the working patch and tests for D7 are done, this won't get a D7 merge until the solution has been ported to D8. It might take a bit for merge to occur. I wrote this blog post to help increase visibility to the issue and perhaps save couple of hours of work for the readers.
On February 17, Facebook announced the launch of Dynamic Product Ads. You may want to pay attention to that, because it can be a very big deal to your customers that have Drupal Commerce based ecommerce stores.
According to Facebook:
"Facebook dynamic product ads helps you promote relevant products to shoppers browsing your product catalog on your website or mobile app."
"Dynamic Ads allow advertisers to create Link Ads that are rendered and targeted based on a set of products. The ads are rendered based on a template and filled in by product metadata. They are targeted based upon a set of actions that a person has taken on that product or product group.
For example, Dynamic Product Ads allow you to serve users an ad for exactly the product they have left in their cart, without creating an individual ad for each product SKU."
Here's an overview of how it works:
Here's more information about the tracking / retargeting pixel:
Did I mention Facebook allows to dynamically turn off out-of-stock items and/or items that are already purchased?
Hello marketing awesomeness :DIs there a module for that?
Not that I'm aware of. To my knowledge Drupal Commerce lacks a convenient way (a.k.a. a module) for
- integrating conversion tracking pixels that attach product price, product title & product category information (you'd be able to create product audiences based on that, for example targeting high-paying customers, purchasers of a certain category of products, etc.)
- allowing dynamic product ads
So I'm hoping by making you aware of the fact that these powerful Facebook marketing methods exist, that it allows you to provide value for your client,
and in the Drupal community spirit: that it will spark (at least) 1 developer to create a module for this.
I'm happy to help beta-test its features, ponder about features and create a bit of documentation for it.
Category: Drupal Planet Drupal Commerce Facebook marketing
Last year at DrupalCon, we proudly declared the front end to be the equal of our back end counterparts in practice and skill.
This year, we reaffirm the unique importance of our role: the front end is the intersection of presentation and structure, content and experience, and design and engineering.
As we hurtle through 2015, DrupalCon Los Angeles is appearing on the horizon — and with it, the deadline for session submissions. This Friday, February 27 at 11:59 PM PST is the last day to submit your proposals for sessions and training, and your last opportunity to apply for grants or scholarships if you need a little help getting to DrupalCon.
We're working on a lot of new hosting infrastructure projects we though you might be interested in. A lot of this is in preparation to provide a better development and hosting enviornment for Drupal 8. We are re-imaging web servers and other servers to do a better job for modern Drupal hosting. Things you can look forward to include:
- Composer baked into our servers for easier development.
- Compass baked into the servers for better development with CSS pre-processing.
- Starting to move new servers into CentOS 7 to provide newer hosting binaries.
- Better support for resellers.
- Easier setup for use of varnish and memcache on our higher-end server packages.
- Better support for Drupal 8 on shared hosting. We want to be able to offer a reasonably-priced environment for hosting Drupal 8 sites.
This is all part of our commitment to provide useful hosting services to the Drupal community. We expect that although Drupal 8 is great, it's going to require more specialized hosting in a lot of cases. We're committed to the Drupal community, and look forward to getting more input from you on your Drupal hosting needs now and in the future.
Yesterday, we began this series with a short introduction to creating the wow factor on a Drupal website. Today we'll look in a bit more detail at (drum roll) ...
Events in Drupal 8 allow various system components to interact and communicate with one another while remaining independent, or decoupled. The event system is built on the Symfony event dispatcher component, and is an implementation of the Mediator design pattern. This post takes an in-depth look at how module developers can subscribe to events in Drupal 8.
After many years of discussion and debate in the Drupal community, Acquia launched the Acquia Certification Program in March 2014. This past year, there were three exams published and offered on a global basis with participants from over 45 countries and several hundred earning credentials. The exams focus on real world experience and the overriding comments we've heard this past year are the exams are tough but fair. There is now a registry posting successful candidates as well.
Most credentials have been earned with the first exam, Acquia Certified Developer, a core exam which cuts across Web Development, Site Building, Front-end and Back-end topic areas. This exam demonstrates an ability to work across these key areas, which in turn helps make successful developers and great team members.
The two following exams, the Acquia Certified Developer - Back-end Specialist, and Front-end Specialist, demonstrate an even deeper grasp of a specialization. Professionals working with Drupal 7 have been testing out successfully as well.
While the current exams are Drupal 7 focused and will continue to be available, we will also have Drupal 8 exams in the coming year.
There is also a new Acquia Certified Drupal Site Builder exam just made available.
Listen to Richard Jones, CTO at i_KOS, talk about his recent experience taking the exam while at DrupalCon Amsterdam, and what it means to him personally, as well as for his business.Keys to Success: Building Scenario-based Exams
All the Acquia Certification exams are almost entirely scenario based. In this manner, you are testing skills and knowledge instead of just memorization. You are also testing for comprehension in a timely manner, and real world experience is validated through a well constructed and well written scenario-based exam pool.
The scenario for each question is challenging to write, and the test writers draw upon their experiences to do so. The information provided in each scenario is required to answer the related question properly.
To have an exam almost entirely scenario-based is a great accomplishment. We have had an outstanding group of subject-matter experts craft these exam questions based on job task analysis research and they follow sound psychometric best practices.
The latest effort for the Acquia Certified Drupal Site Builder certification exam is no exception.The Exam Writing Workshop
This month, the Acquia Certified Drupal Site Builder exam was created and the Acquia Certified Developer exam was updated in one combined exam writing workshop. The exam writing workshop is a very intensive and focused effort. The latest effort had a great cross section of the company represented for the workshops, which I facilitated, with Jeff Beeman, Erik Webb, Alex Ward, Adam Malone, Kenny Carlile, and Jonathan Webb serving as Subject Matter Experts.
The exam writers, Subject Matter Experts, are put through a rigorous workshop to write items with supporting documentation. They must agree as a team that each item is relevant, technically accurate and readable.
Several rounds of tech reviews are conducted throughout the workshop and each item must be able to stand up to scrutiny. Test writers have reported that they even dream of test items at night during the course of an intense multi-day workshop, as total immersion to the process is needed to be successful. Team dinners usually end up turning into great debates on something from earlier in the day.
Happy testing!About Peter
Peter Manijak @PeterManijak: Peter is an experienced Certification and Learning Professional, responsible for creating and managing successful global programs.
Tags: certification acquia drupal planet cert developers drupal
Kraftwagen is a drush extension containing a set of Drupal modules enabling you to get a tighter grip on the distribution and subsistence of your (or your customer’s) website.
With Kraftwagen you can easily set up multiple environments like development, staging and production. It also lets you store configuration settings in your code instead of your database saving you a vast amount of time setting up a new environment. This feature enhances the use of version control so every update can be traced or restored.
Another great feature is the ability to maintain third party code like modules and libraries. You tell Kraftwagen which modules you need and it will download and install them for you. New version? No problem, just change the version number.How does it work?
Your entire website is stored in a profile. Forget Drupal core and the sites folder. This profile contains your custom modules, your theme and configuration settings. So far nothing new on the horizon.
There are three files that make the magic happen:
- The make file (your_site.make), which defines all the contrib modules and libraries you want to download. Drush handles this, so still no Kraftwagen involved here.
- The info file (your_site.info), which defines what modules must be enabled. Just a standard Drupal file.
- In addition to the previous files, Kraftwagen adds the build.make.tpl, which provides a template for your make file. It defines your profile and Kraftwagen directory, which Drupal version you want to use and optionally which patches you want to apply to it.
If all files are in place and you are satisfied with your configuration, you just give the build command and wait. Drupal core will be installed along with all your modules and settings. When the build is done, all you have to do is give the update command and you’re good to go.
Easy as pie.How to start?
Visit http://kraftwagen.org/get-started.html and install Kraftwagen. You’ll also find some instructions here on setting up a new project or update an existing project.
But what if you want to convert your existing non-Kraftwagen site to a Drupal profile? That’s what we will be covering in the following paragraphs.To Kraftwagen and beyond!
First, create a new Kraftwagen folder because we will create a fresh installation of your site. Now, run the drush command drush kw-np (or drush kw-new-project) inside that folder and enter a human name (like Your Site) and machine name (like your_site). You can just press enter when asked for a skeleton and branch.
You’re folder structure should look like this:
We’ve got ourselves an empty Drupal profile here. Time to merge your existing site in here.
Specify your desired Drupal core version in tools/build.make.tpl in this line:
projects[drupal][version] = "7.23"
Congratulations! You’ve just upgraded your site!
Next, copy all your custom modules to modules/custom/. Now, assuming you don’t know all the contrib modules you’ve been using from the top of your head, we will generate a list from your existing site.
Go to the root directory of your existing site and run drush make-generate. Drush generates a make file with all the modules you have installed. Open it and copy this list into your_site.make in your Kraftwagen folder. Notice that there are already some modules prefilled. If you don’t need them, you can erase all modules except the Kraftwagen modules (starting with kw_).
Next up is checking which modules are enabled in your existing site. Again, go the the root of your existing site and run drush pm-list --type=Module --status=enabled.
Unfortunately, this list is not as user friendly as the generated make file. Copy it and paste it into your_site.info in your Kraftwagen folder. Convert every line to:
dependencies = modulename
Preferably grouped and sorted by core, contrib, custom and optionally features. You may remove the prefilled dependencies except for the Kraftwagen ones. You’ll notice there are also env_dependencies, these enable the given module only when the defined environment (like development or staging) is set.
Now the modules part is done, copy your theme folder to src/themes/.
As the final part of the setup, navigate to the src directory and run drush kw-s (or drush kw-setup). When you navigate to the parent directory, you’ll find two new folders: builds and cnf.
Every time you make a build, it will be stored in the builds folder. The foldername always matches the date and time of creation, for example: 20150125-135919 (2015-01-25 13:59:19). Every build gets it’s own directory so remember to remove some old builds in a while to save some space.
The cnf folder holds your settings file and files directory. The environment file defines in what kind of environment you’re working, this would be development, staging or production. Open up settings.local.php and set your database info. Also make sure the files directory is writable and has the correct ownership and permissions. The Drupal handbook provides a useful script which handles this for you, you’ll find it at the bottom of this article: https://www.drupal.org/node/244924.Build it!
Duplicate your database so we don’t overwrite the existing one. Always make a backup of your database before you make a new build.
Navigate to the src directory and run drush kw-b (or drush kw-build). This will download Drupal core and all contrib modules specified in the make file and copy your custom stuff in site/profiles/your_site/.
It also creates symlinks in site/sites/default/ to the settings.php and files folder in your cnf directory. When the build is finished, a symlink build is created to the newly created build in the builds folder so you don’t need to remember the full build name (20150125135919) and to switch easily between build folders if necessary.
So when the build is successful, you can find your profile in an entire Drupal installation in kw/build/.Adapt your database
Making a build is not enough. We need to tell our database some major stuff is going on in here. Navigate to kw/build/. Normally, drush kw-u (or drush kw-update) would be sufficient. This enables the modules specified in the info file, executes module updates, reverts all features and runs manifests. All in one command.
However, since this is the first time we’ve made a build from a converted website, we need to do some more.
First, we need to tell our database what profile and theme should be used. This can be achieved by executing the following SQL queries:UPDATE variable SET value = 's:9:"your_site";' WHERE name = 'install_profile'; UPDATE variable SET value = 's:10:"your_theme";' WHERE name = 'theme_default';
Note that the value is a serialized string, so the number in 's:9' should be the character count of 'your_site'. The same goes for 'your_theme'.
Manually clear the cache with:TRUNCATE `cache`; TRUNCATE `cache_block`; TRUNCATE `cache_bootstrap`; TRUNCATE `cache_field`; TRUNCATE `cache_filter`; TRUNCATE `cache_form`; TRUNCATE `cache_image`; TRUNCATE `cache_menu`; TRUNCATE `cache_page`; TRUNCATE `cache_path`; TRUNCATE `cache_token`; TRUNCATE `cache_update`; TRUNCATE `cache_views`; TRUNCATE `cache_views_data`;
Then we need to update the registry by running drush rr (or drush registry-rebuild). This is necessary because all contrib and custom modules have moved from sites/all/modules/ to profiles/your_site/modules/.
Now, as finishing touch, we can run drush kw-u.
You may need to clear the cache (drush cc all), point your browser to kw/build/ and you’re good to go.Conclusion
You’ve just turned your website into an easily manageable and deployable Drupal profile.
Need to add a new module? Just add it to your make file and make a new build. Module update? Just change the version number and make a new build. Or do you want to add a staging environment for your customer to check things out? Make a new copy of your Kraftwagen folder (or clone it if you’re using git), change the environment variable to staging and start building.
You should also notice that basically, the contents of kw/src/ folder are copied to site/profiles/your_site/, which means that if you are using git, you can happily code further in the profiles directory.
There are lots of useful things you can do with Kraftwagen. First get comfortable with the build procedure, then you should also check out manifests and the way patches are handled.
For now, as stated in the conclusion at Kraftwagen.org: Enjoy the ride with Kraftwagen...
On February 9, 2015 the Cheppers team decided to start rebuilding the company’s website with Drupal 8. At the time, Drupal 8’s version was Beta 6 with 50+ critical issues, 10+ upgrade path blockers, and it was potentially going to be about a year before the stable version’s release.
A while ago I made a tool named Sheet2Module, which uses the Config in Code (CINC) module to allow Drupal site builders to make content types and fields directly from Google Spreadsheets. This made a lot of people interested in CINC, but I've found much of that interest was based on a misconception that CINC is focused on spreadsheets. So I recently spent a couple hours making another tool with CINC, to hopefully demonstrate how this is interesting beyond spreadsheets.
Fast Content Type UI is a simple module that lets you edit all your Drupal content types on the same screen. You can't change everything about a content type on that screen, just the things I've found myself adding and editing most often: display name, machine name, and comment status. When that's all you're editing, this is a better, faster UI. And if you need more than that, the standard UI is still there.
And Sheet2Module is also still there. So now you have three very different interfaces for managing your content types in Drupal, or five if you count YAML and PHP as interfaces. The interesting point here isn't really any of these interfaces, it's what these interfaces are hopefully starting to demonstrate: that you can use any interface you want to work with Drupal configuration.
Many of us in the Drupal community spend our days giving clients custom-tailored interfaces to suit their specific needs. Yet when we use Drupal, as administrators, we do our work entirely in the default interfaces. For most of Drupal's history it was a lot of work to create a new interface, because every module managed its configuration in a different way. That's no longer the case. Today it's easy to make your own UI for existing configuration. Fast Content Type UI is one example of that. We should have many more.
We can’t imagine Drupal without Views. It comes in fresh Drupal installation and new modules are being attached to it as the time passes. This additional modules affect the work of Views, extending the functionality and adding new useful features.
Here is a short review of modules that could be combined with Views successfully. If you’d like to get a detailed instruction about the installation of certain module, go to this module’s Drupal.org page and use readme. Hopefully, this article would be useful for you.Read more
- Getting #2,000 requests per second without varnish
- When PHP crashes: how to collect meaningful information and what to do with it
- Node Comment and Forum working together to boost user participation
- Setting up Code Syntax Higlighting with Drupal
- Distinct options in a views exposed filter: The Views Selective Filters Module
- Bypassing Form Validations and Required Fields in Drupal: the BFV module.
- Installing Drupal on Windows and SQL Server
- Drupal Session Handler: everything you need to know
- Drupal on IIS or Apache
This post is more of a demo rather than a blog post. I have created a Free Drupal 8 theme called Monoset.
Steve Burge (steveburge), founder of OSTraining.com joins Andrew, Ted, and Mike to talk about a new blog post series about cities transforming themselves into tech-friendly places with smart investment and forward thinking leaders. We also dive head-first into Drupal.org's content strategy, the evolution of Drupal.org forums, and various ways to pronounce the word "route". Picks of the week includes some free videos, BackDrop on Pantheon, and DrupalCon India.