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...
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
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.
Last month, we posted a survey regarding your plans for learning Drupal 8. This was a follow-up to a similar survey we posted back in May, 2014. The responses we received in both instances were remarkably consistent, which is reassuring as we begin to publish our Drupal 8 tutorials. Here are a few big take-aways from our Drupal 8 surveys and some insight into our plans for Drupal 8 tutorials.
This year the Drupal Association Board of Directors has an opening for a single director At-Large position. With this opening, the association reached out to the community to allow anyone to self nominate for the position. As of the closing of the nomination round, there were 24 candidates, from 14 different countries, which I think is an incredible testament to the community.
When I saw this opportunity, I decided to ...Read More
Core Conversations is a place for people actively working on and contributing to Drupal core to meet, discuss and plan the future of Drupal.
Drupal 8 is very close to having a stable upgrade path, and the number of remaining critical issues is steadily decreasing. The timing of DrupalCon LA means that the focus on talks should be on the future of Drupal, either the short term of 8.1.x, or the future of 8.y.x, or even as far as Drupal 9.
Continuous integration (CI) is the practice of running a series of checks on every push of your code, to make sure it is always in a potentially deployable state; and to make sure you are alerted as soon as possible if it is not.Continuous integration and Drupal projects
This blog post is aimed at module maintainers, and we'll look at how to use CI for modules hosted on Drupal.org. I'll use as an example a project I'm maintaining, Realistic Dummy Content.
The good news is that Drupal.org has a built-in CI service for hosted modules: to use it, project maintainers need to click on the "Automated Testing" tab of their projects, enable automated testing, and make sure some tests are defined.
Once you have enabled automated testing, every submitted patch will be applied to the code and tested, and the main branches will be tested continually as well.
If you're not sure how to write tests, you can learn by example by looking at the test code of any module which has automated testing enabled.Limitations of the Drupal.org QA system
The system described above is great, and in this blog post we'll explore how to take it a bit further. Drupal's CI service runs your code on a new Drupal site with Drupal 5.3 enabled. We know this by looking at the log for a test on Realistic Dummy content, which contains:[13:50:02] Database backend [mysql] loaded. ... [simpletest.db] => [test.php.version] => 5.3 ...
For the sake of this article, let's say we want to use SQLite with php 5.5, and we also want to run checks from the coder project's coder_review module. We can't achieve this within the Drupal.org infrastructure, but it is possible using Docker, CircleCI, and GitHub. Here is how.Step 1: get a local CoreOS+Docker environment
Let's start by setting up a local development environment on which we can run Docker. Docker is a system which uses Linux containers to run your software and all its dependencies in an isolated environment.
If you need a primer on Docker, check out Getting Started with Docker on Servers for Hackers (March 20, 2014), and A quick intro to Docker for a Drupal project.
Docker works best on CoreOS, which you can install quite easily on any computer using Vagrant and VirtualBox, as explained at Running CoreOS on Vagrant.Step 2: Add a Dockerfile to your project
Because, in this example, we want to run tests which require changing things on the server, we'll use the Docker container management system to simulate a Ubuntu machine over which we have complete control.
To see how this works, download the latest dev version of realistic_dummy_content to your CoreOS VM, take a look at the included files ./Dockerfile and ./scripts/test.sh to see how they are structured, then run the test script:./scripts/test.sh
Without any further configuration, you will see tests run on the desired environment: Ubuntu with the correct version of PHP, SQLite, and coder review. (You can also see the results on CircleCI on the project's CI dashbaord if you unfold the "test" section -- we'll see how to set that up for your project later on).
Setting up Docker for your own project is just a question of copy-pasting a few scripts.Step 3: Make sure there is a mirror of your project on GitHub
Having test results on your command line is nice, but there is no reason to run them yourself. For that we use continuous integration (CI) servers, which run the tests every time someone commits something to your codebase.
Some of you might be familiar with Jenkins, which I use myself and which is great, but for open source projects, there are free CI services out there: the two I know of, CircleCI and Travis CI, synchronize with GitHub, not with Drupal.org, so you need a mirror of your project on GitHub.
Note that it is possible, using the tool HubDrop, to mirror your project on GitHub, but it's not on your account, whereas the CI tools sync only with projects on your own account. My solution has been to add a ./scripts/mirror.sh script to Realistic Dummy Content, and call it once every ten minutes via a Jenkins job on my personal Jenkins server. If you don't have access to a Jenkins server you can also use a cron job on any server to do this.
As mentioned above, two of the CI tools out there are CircleCI and Travis CI. One of my requirements is that the CI tool integrate well with Docker, because that's my DevOps tool of choice.
As mentioned in Faster Builds with Container-Based Infrastructure and Docker (Mathias Meyer, Travis CI blog, 17 Dec. 2014), it seems that Travis CI is moving towards Docker, but it seems that its new infrastructure is based on Docker, but does not let you run your own Docker containers.
Circle CI, on the other hand, seems to provide more flexibility with regards to Docker, as explained in the article Continuous Integration and Delivery with Docker on CircleCI's website.
Although Travis is a great, widely-used tool (Drush uses it), we'll use CircleCI because I found it easier to set up with Docker.
Once you open a CircleCI account and link it to your GitHub account, you will be able to turn on CI for your mirrored project, in my case Realistic Dummy Content.Step 5: Add a circle.yml file to your project
In order for Circle CI to know what to do with your project, it needs a circle.yml file at the root of your project. If you look at the circle.yml file at the root Realistic Dummy Content, it is actually quite simple:machine: services: - docker test: override: - ./scripts/test.sh
That's it! Commit your circle.yml file, and if mirroring with GitHub works correctly, Circle CI will test your build. Debug any errors you may have, and voilà!
Here is the result of a recent Realistic Dummy Content build on CircleCI: unfold the "test" section to see the complete output: PHP version, SQLite database, coder review...Conclusion
We have seen how you can easily add Docker support to make sure the tests and checks you run on your code are in a controlled environment, with the extensions you need (one could imagine a module which requires some external system like ApacheSolr installed on the server -- Docker allows this too). This is one concrete application of DevOps: reducing the risk of glitches where "tests pass on my dev machine but not on my CI server".Tags: planetblog
Recreating and simplifying a multiple site platform by creating a re-usable distribution.
#1 Getting started.