Although Webform module comes with limited integration to expose the submitted data in Views, it lacks the fine control to make View by Webform field as rows and columns. There is a workaround to achieve this though which I would like to briefly run through in this blog.
Webform MySQL Views together with Data and Schema modules with a patch to Webform MySQL Views from issue #889306: Allow the designation of a primary key for MySQL views makes this feasible.
Webform MySQL Views, as the name implies, allow us to create MySQL view from Drupal, leveraging the Data module which counts on Schema module.
Data module wraps a bundle of sub-modules, among them Data Search provides Views Integration and Data Admin UI for accessing its administrative pages.
Once the mentioned modules are enabled. You can see a sub-menu "MySQL Views" under Administration » Content » Webforms. Tick the Webform node whose fields are needed in Views. This form is only meant to create MySQL view.
Today we’re proud to announce the launch of Drupal Jobs, a career site dedicated completely to Drupal. The Drupal job market is hot (more on that in a moment) and we hope this new tool will help match the right talent with the right positions.
For job seekers, you can start searching for positions by location, position, skill level and more. You can create a profile with your job preferences and salary requirements, and even choose whether you wish to be contacted by employers and recruiters. All for free.
For employers and recruiters there are a variety of packages available, giving them the opportunity to highlight their company with a branded page and feature select postings in newsletters and social media. The great thing is that proceeds from postings are invested back into Drupal.org and its subsites (including Drupal Jobs) and community programs.
The website is launching today and, as with any new website, we expect there will be some kinks to work out. But we know Drupal Jobs will be a valuable addition to the current options for employers, recruiters and job seekers.
The Drupal job market shows no signs of slowing. Our recently conducted survey points to a strong need for talent (see the chart below). In the next few days we’ll publish the full results of the survey. In the meantime, check out Drupal Jobs and let us know what you think.
One challenge the Drupal community has faced for some time is a labor shortage. There are, quite simply, not enough skilled Drupal developers to go around. That's quite a problem when the Drupal market is continuing to grow steadily.
One of the challenges to finding good Drupal talent is that Drupal has historically been, well, weird. And by "weird" I mean "entirely unlike any other system on the market". That makes few skills transferrable between Drupal and any other PHP framework, application, or system. Developers trained on Drupal cannot easily transition to any other system and developers trained on any other modern PHP system get lost in arrays the minute they set foot in the door. It's a sufficiently large problem that I've talked to other development shop owners that have said outright they have more success hiring fresh, junior developers and training them on Drupal as their first system than hiring anyone with experience, as those with more extensive PHP experience run for the door.
That's a big problem. Fortunately, that's about to change.
For the past several years, the Drupal project has been working to Get Off the Island. Drupal 8 will be using more standard, common PHP and programming-in-general tools, techniques, and architectures, making it more accessible to more developers than ever before, even non-PHP developers. The number of Drupal developers showing up at non-Drupal events is rising; For example, Lonestar PHP 2013 had two; Lonestar PHP 2014 had 10 (which for a 200 person conference is a very respectable number). I've noticed similar trends at other PHP conferences.
But to really seal the deal and help fill the Drupal employment gap, it's time for Drupal employers to step and do their part: Selling off the island.
With Drupal 8, and the buzz around it in the general PHP community, there will be an increasing number of general PHP developers interested in working with Drupal and who are better qualified to work on Drupal. (Not with no training, but with far less retraining than Drupal 7 requires.) Those developers, though, won't just walk in the door. They have no reason to come to a DrupalCamp, and probably not even a DrupalCon. As a Drupal consultancy or Drupal-based company you need to go out and find them. The core team has done its part, now it's time to do yours.
A friend of mine once said that if you want to meet people with whom you have a shared interest you need to go where people with that interest hang out. That applies for hiring, too. So where does the next round of Drupal talent hang out? At non-Drupal events. If you don't then someone else will hire the next generation of senior developers before you do.
- Have a presence on stage: Make no mistake, presenting is hard work. It takes a lot of preparation to give a good talk, and that takes time. But the impact of having someone from your company on-stage is 10x that of having them walking around the hallway with other attendees. If someone from your team can present on work that you've done that's fantastic. But even just presenting on something cool, interesting, insightful, or otherwise useful can be a big help to your company's brand. Also, light branding of the presentation itself is completely OK as long as it's not gratuitous. That's a much more targeted form of marketing than exists anywhere else, online or off; you have a self-selecting group of potential hires in one room together. Let your team be what they're there to see.
At the start of 2013 I laid out a challenge to Drupal developers: Attend at least two non-Drupal events that year. I'll now lay the same challenge out to Drupal-based companies: Encourage your team to present at at least two non-Drupal events in the next year, and sponsor at least two non-Drupal events in the next year. There's no shortage of them; there's over a dozen PHP conferences just in the USA every year and more around the world.
Your next Drupal hire is going to come from a non-Drupal background, especially a senior-level developer. If you want to hire them before someone else does, get out to where they are. It's a whole new market if you're willing to embrace it.
So at DrupalCon Austin I had a great time at the contribution sprints. I worked on some issues affecting Drupal.org, it was great fun!
The issues we worked on over the week range from simple things through to some pretty difficult issues.
Although Drupal core can always use more contributors, I would suggest that Drupal.org is also desperately short of contributors too.
The notion that people contributing to Open Source don't get paid is false. Contributors to Open Source are compensated for their labor; not always with financial capital (i.e. a paycheck) but certainly with social capital. Social capital is a rather vague and intangible concept so let me give some examples. If you know someone at a company where you are applying for a job and this connection helps you get that job, you have used social capital. Or if you got a lead or a business opportunity through your network, you have used social capital. Or when you fall on hard times and you rely on friends for emotional support, you're also using social capital.
The term "social" refers to the fact that the resources are not personal assets; no single person owns them. Instead, the resources are in the network of relationships. Too many people believe that success in life is based on the individual, and that if you do not have success in life, there is no one to blame but yourself. The truth is that individuals who build and use social capital get better jobs, better pay, faster promotions and are more effective compared to peers who are not tapping the power of social capital. As shown in the examples, social capital also translates into happiness and well-being.
Most Open Source contributors benefit from social capital but may not have stopped to think about it, or may not value it appropriately. Most of us in the Open Source world have made friendships for life, have landed jobs because of our contributions, others have started businesses together, and for others it has provided an important sense of purpose. Once you become attuned to spotting social capital being leveraged, you see it everywhere, every day. I could literally write a book filled with hundreds of stories about how contributing to Open Source changed people's lives -- I love hearing these stories.
Social capital is a big deal; it is worth understanding, worth talking about, and worth investing in. It is key to achieving personal success, business success and even happiness.
At PreviousNext we rely heavily on vagrant for development environments and phing for performing automated tasks to speed up site building and project development. These tools are hugely beneficial in the long run. In this blog we'll have a look at how we as drupal core developers can automate the tedious tasks like site install/ re-install, testing, coding standards validation and enable modules.
As the year continues to progress, our momentum as a team continues to build. We're accomplishing more and more with the community, which is fantastic to see. That said, it's also been a challenging year. This is the first year we have attempted to systematically measure the impact of our work. On the one hand, it's been wonderful to start to accumulate a baseline of data we can measure against for the future. On the other hand, the data is also a little all over the place. In some cases, we had very little to go on when setting the goals, which means that we aimed way too high or low. In other places, we have some areas of real concern to address.
Here the topics we tackled on Wednesday:Drupal.org Improvments
Overall, we've begun to see some significant improvements to the stability and performance of Drupal.org. Although many of our metrics related to performance are still in the red for the year, the last few months have seen significant improvements in page load times, etc. In short, things ARE getting better. Additionally, as the tech team has begun to gel under new CTO Josh Mitchell's leadership, they have begun to rapidly turn out great work on the feature side of Drupal.org. We've tackled a remarkable number of issues in just the last few months:
- Implemented user pictures on Drupal.org profiles
- Conducted 30 User Research interviews and began developing personas for a skill acquisition model of user design (more to come from the DCWG)
- Implemented RESTws API for Drupal.org
- Implemented Semantic Versioning for Drupal 8
- Added Supporting Organizations field on projects (entity reference to an organization with an explanation field - we need to promote this change as it was part of the overall efforts to give credit to organizations)
- Took over maintenance of the PIFT and PFFR testbots so that the community could continue with improvements to a modern, best-practice alternative
- Updated the Bakery module to allow us to better integrate with subsites like Drupal Jobs
- Responded to spam on several subsites where the basic Mollom configurations were overwhelmed by human spammers
- Responded to and deployed several security release updates including the recent XMLRPC response where we teamed up with WordPress
- Launched a new landing page on Drupal.org for designers and front-end developers
- Automated process for publishing supporting partners on Drupal.org
Although Drupal.org is chock full of data, this is an area where we had very little longitudinal or granular data to guide our goal setting. Combined with our slow hiring cycle, we've had a tough time really making a dent in some of our red numbers, but we ARE making progress and most importantly will know so much more for next year than we did for this year.DrupalCons
We shared a very in-depth review of DrupalCon Austin at this board meeting, as well as trends for Amsterdam. The long and short is that we had, in almost every way, a very successful DrupalCon in Texas. We were able to compare evaluation, finance, and attendance numbers to Portland and show our year over year trends, which was very helpful. While there is a lot to be happy about, we also have reason for concern. While DrupalCons have sustained growth year over year since their beginning, Texas was basically flat compared to Portland in terms of attendees. Looking ahead at the Amsterdam numbers, we're also finding that we may be at or slightly below our Prague numbers.
There are many reason we could be seeing a plateauing of these numbers. It could be a natural by product of where we are in the product development cycle. No Drupal 8 and a really mature Drupal 7 product means there is less to talk about and learn. It may be that our demographics are shifting and the Con is not needing their needs. It may be a combination of many things.
What we DO know is that we need to get to the bottom of the issue so that we can adjust our strategy accordingly. After Amsterdam, you will see a survey from the Association to help understand your DrupalCon motivations. So whether you've always gone to DrupalCon or have never entertained the notion, we will want to hear from you.Licensing Issues on Drupal.org
I've heard from lots of volunteers on Drupal.org recently that our policies for enforcing GPL v2 licensing on Drupal.org have been problematic. In short, there are too many issues, those issues are reported inconsistently, and volunteers are not trained on our licensing issues and apply remediation to those issues inconsistently. It's a pretty typical story - great volunteers getting stuck in an escalating situation.
To help mitigate these issues, I pulled together a call with folks who had been working on these issues for advice about how we can help fix the process. The advice of the group is to form a Licensing team (like the Security Team), that receives training from the Association's lawyers and works together to resolve licensing issues quickly and consistently. We would create a separate queue for licensing issues and get this off the plates of the webmasters queue volunteers (where most issues end up now).
The board agreed that this woudl be the logical next step and a meeting has been scheduled for September 9th to begin work on a charter for the group. We'll share more details as we have them.Quarterly Financials
Finally, in executive session we reviewed and approved the financials for the second quarter of 2014. Here they are:
The next board meeting was scheduled for 17 September 2014. However, given the proximity to the 3 October board meeting at DrupalCon Amsterdam, the board decided to cancel that meeting. Remember though, you can always review the minutes and meeting materials in the public GDrive.
Flickr photo: xjm
Thank you to the Drupal Community for 10 years of prosperity: I hope you take this challenge too, and find it in your heart to give to ALSA.org or a charitable organizations of your choice.
This video is dedicated to Aaron Winborn. Aaron's family could also use your donations, as he is suffering from ALS.Drupal Planet
Tech Coast Angels is the largest angel investment organization in the United States. With over 300 members throughout Southern California, Tech Coast Angels' members have invested over $120 million in over 200 startup companies since their inception in 1997.
Since 2013, Exaltation of Larks has been working with Tech Coast Angels with their online systems, including an extensive Drupal web application that their members use as a deal flow tracker and document management system. Services we’ve provided include support, maintenance, security improvements, performance optimization, and mobile integration.
The web application that Tech Coast Angels uses allows its members to view startup companies' applications for funding, discuss each company's application, and collaborate with one another in researching each company, which then helps them make individual decisions on funding.Key modules/theme/distribution used: ServicesPHP Filter LockAPC - Alternative PHP CacheSecure Password HashesFeaturesACLOrganizations involved: Exaltation of LarksTeam members: focal55
In the last installment of multiple views you will learn how to change the look of the view using the two classes you set in the previous video. By using CSS, you will be able to display content in two ways depending on the choice of the viewer. This is a nice advantage to provide options for the visitor to your site.Tags: DrupalViewsDrupal 7Theme DevelopmentDrupal PlanetUI/DesignCSS
In this post, I will share my experience on trying to learn Drupal 8 during its alpha stage, talk about some of the challenges of keeping up with the ongoing changes while trying to learn it, and end with some tips and resources which proved useful for me.
Lets say you are building a site for an institution with multiple locations, each of which have varying hours depending on time of year or other variables. What is the best way to manage this data? This is a pretty common type of content modeling problem. The easiest thing to do is to just give each location a text field for their hours, but that limits display options and is prone to data entry errors. You could also build out a whole fancy content type with multi-instance date fields, but that could get bloated and difficult to maintain pretty quickly.
Promet Source: <a href="/blog/johnnie-fox-has-legal-issues-tale-software-development-and-geekery">Johnnie Fox Has Legal Issues: A Tale of Software Development and Geekery</a>
What follows is part one in a series of posts on web performance that I've wanted to write for quite some time. In this series of posts I'll not only be talking about optimizing web performance generally, but also providing specific guidance for speeding up Drupal sites.
Although I'm not a web performance specialist or expert, I have taken a keen interest in the topic in my work as a frontend developer building responsive websites. I love building fast sites and have gained some experience over the years getting Drupal to shed some its inherent sluggishness.
As a way of systematically tackling what can be a complex subject, we'll use the results of a test from WebPageTest.org, a Google-sponsored tool that provides very in-depth information about the performance of a site in nice, easily digestible chunks.How Fast Is Fast Enough?
Before we get into the details of web performance we should first stop to ask how fast a site should be in order to qualify as "fast". Here are some research results courtesy of Radware that might help bring things into focus:
- 64% of smartphone users expect pages to load in less than 4 seconds.
- The performance poverty line (i.e. the plateau at which your website’s load time ceases to matter because you’ve hit close to rock bottom in terms of business metrics) for most sites is around 8 seconds.
More guidance comes courtesy of Ilya Grigorek of Google. In his recent presentation at the Velocity conference, he cited research that indicates a target page render time should be 1000ms - or one second - to avoid "context switching" among users.
Basically, if it takes a page longer than one second to render, you risk losing the attention of the user. If it takes longer than eight seconds for a page to render, it's similar in terms of business metrics (conversions, sales, etc) as if it took 30 seconds or a minute.
If one second sounds impossibly ambitious, there is further research showing that a load time of three seconds or less is probably OK.
The bottom line: your pages should load in under three seconds on desktop, and under 4 seconds on a mobile.
Pretty harsh reality check, huh? Let's see what can be done to get our sites whipped into shape.Test Results for this Analysis
In order for us to have a practical example for our discussion, I ran the Friendly Machine site through WebPageTest. Here are the results (click to enlarge image):
I recently completed a refresh of the design of this site with a lot of attention focused on keeping things fast. My target page load time was one second, so I was happy when the results consistently came in below that.
Let's start our analysis by looking at the first number in the above table - under the heading "Load Time". You'll see the value is 0.662 seconds. That's pretty darn good, but if you scan across the table you may see something on the far right that's a bit confusing - a Fully Loaded Time of 0.761 seconds.So what's the difference between Load Time and Fully Loaded Time?
Load Time is calculated from the time when the user started navigating to the page until the Document Complete event is fired. The Document Complete event is fired by the browser once the page has completed loading.
Whenever talk turns to web performance, it seems a lot of folks immediately start thinking of what's happening on the server. Although it's a very important piece of the puzzle, as we walk through this analysis, you'll see that most web performance issues actually reside on the frontend.
Before we get ahead of ourselves, though, let's return to the results from our test and look at the next metric in our table, First Byte Time (highlighted in blue below) which tells us about performance on the server.
This First Byte Time represents the time from when a user began navigating to the page until the first bit of the server response arrived at the browser. The target time for this on WebPageTest is a meager 87 ms!
This metric is also represented as the first in the series of letter grades you see at the top of the test results. You'll notice Friendly Machine got an "A" and I really wish I could take credit for it, but the truth is my host Pantheon - and the awesome backend performance they provide - are responsible for this metric scoring well.Backend Drupal Performance
Let's pause here and talk specifically about backend Drupal performance. How would we address this metric if it hadn't scored well? This topic can get pretty deep, so we'll only review the most popular options, but they'll still be able to do wonders for improving this key metric if your site is not performing well.
Let's start by discussing server resources (with a brief, tangential mini-rant about shared hosting).
If you want a fast Drupal website, you really shouldn't be on a shared host, period. Although many of them will claim to be Drupal specialists, very few of them actually are. One giveaway is the number for PHP memory limit.
Although this number doesn't directly impact performance, it can break your site if it's too low and is also useful for smoking out hosts that don't know Drupal. You can find this number at admin/reports/status and it will look something like the image below.
You can see on my site this number is at 256 megabytes and this is most likely where you want it, although if you have a simple site without Views or Panels, then 128M might work. If it's set at 64M, then it's too low and this is often what you'll find with shared hosting arrangements.
Another issue with shared hosting - and one that does impact performance - is that your website is on a server with perhaps hundreds of other sites. If one of those sites gets hit with a large spike in traffic or some other issue, it can affect all the sites on that server as it gobbles up the available resources.
Perhaps the biggest issue with shared hosting, however, is that advanced caching using tools like Memcached and Varnish are rarely, if ever, available. And when it comes to Drupal backend performance, caching is critical. The best you'll probably be able to do with regard to caching on shared hosting is using the Boost module, which we'll talk about in the next section.
To ensure that server resources aren't an issue for your website, consider either a managed VPS or a Drupal host like Pantheon, both of which start at around $25 per month. Pantheon is what I recommend for small to medium sized sites because your site will scale better with them and they offer tremendous value, although they are a great fit for enterprise clients as well. If you have a bigger budget, Acquia or BlackMesh might fit the bill.
Sure, these options cost more than the $7 per month the cheap hosts offer, but they will provide a professional level of service that will more than pay for itself over time.Caching for Drupal Websites
We said caching was critical, so here are five of the most important caching solutions for a Drupal website:
- Drupal's built-in caching
- Boost module
- Views caching
There are other options, of course, but these five cover most of the ground. Let's briefly go through them one at a time.Drupal's Built-in Caching
Most of a Drupal site is stored in the database - nodes, information about blocks, etc. - and enabling the default caching will store the results of these database queries so that they aren't executed every time a page is requested. Enabling these settings alone can have a big impact on performance, particularly if your pages use a lot of views. This one is kind of a no-brainer.Boost Module
The Boost module is pretty great. It works very well in tandem with Drupal caching, but it requires some additional configuration. What you end up with after you have the module installed and configured is a caching system that stores the output of your Drupal site as static HTML pages. This takes PHP processing out of the equation, leading to another nice bump in performance.Memcached
Memcached can speed up dynamic applications (like Drupal) by storing objects in memory. With Boost and Drupal caching, the data being cached is stored on the server's hard drive. With memcached, it's being stored in memory, something that greatly speeds up the response time for a request. Memcached works great in conjunction with both Boost and Drupal caching.Varnish
Varnish is an HTTP accelerator that, similar to memcached, stores data in memory. It's capable of serving pages much faster than Apache (the most common web server for Drupal sites). It can also be used in conjunction with memcached, although it's often the case that they are not used together and other advanced caching methods are instead implemented alongside Varnish.Views Caching
Another type of database caching is Views caching. Views is a very popular, but rather resource intensive, Drupal module. Implementing Views caching can give your site a nice additional performance boost by possibly removing a few database queries from the build process.
To set views caching, go to your view. On the right hand side, under Advanced > Other, you'll see a link for Caching. Just go in and set a value - an hour is usually a good default - for each view on your site.Wrapping Up Part One
Wow, long post and all we've really covered so far is backend performance and caching! This discussion hasn't been comprehensive by any means, but it does provide a great start.
Next time we'll start digging into frontend performance, the area where most of our performance issues reside. What should be obvious so far is that web performance is a subject that is both deep and wide, but also critically important to building successful websites.
If you have any comments about this post, you may politely leave them below.Drupal Web Performance