After hours of searching Google, lots of trial and error, and a bunch of grumbling, I had a breakthrough and finally figured out how to get Source Maps to work under Chrome and Compass. The problem is that this functionality has been around for over a year in various forms in the pre-release versions of Sass and Chrome. As such, many of the posts I found were out dated and didn't work with the current, stable versions. So this post is partially to document the process for myself (and a small victory lap!), but hopefully someone else will get something out of it.
The admin toolbar is a user's first look at Drupal. A complex, cluttered toolbar gives the n00b a sense that things in this site are too much to handle. A clean, well-curated interface that presents content tasks first gives the n00b a sense that Drupal is easy to use. Drupal 8 promises a simplified toolbar that gives the user the this cozy sense of belonging.
The big news this week is we're still on one beta-blocker. Patches for the remaining beta blocker are coming rapidly with @effulgentsia, @plach and @fago working hard to get it over the line. Could we have zero beta blockers by DrupalCon?
Other keys issues to land this week include Remove ArrayAccess from FormState - never again deal with random arrays - rejoice - $form_state is a first-class object!. Thanks to @timplunkett and others who helped get this through. If you have any contrib projects accessing $form_state in an array fashion eg $form_state['values']['fooey']; then you need to familiarize yourself with the change record.
In a further sign that Drupal 8 is maturing into a modern HTTP framework, we now have support for a stack-php based middleware this will allow us to clean up how page caching, conent negotiotiaton, implementing ban.module's functionalty, options requests and various other elements of the request processing pipeline work. For more information on middlewares see Stackphp.com and this article or see the list of existing middlewares supported by stack-php, and therefore likely to be compatible with Drupal.
In the same vein Modularize kernel exception handling brought some much needed cleanup to to the way we handle exceptions and enables contrib modules to easily add their own exception handling, particularly for custom REST formats.
Over in Convert UnitTestBase to PHPUnit and Remove UnitTestBase, @sun, @Berdir and @tim.plunkett have been working towards removing Simpletest-based Unit tests. There are plenty of sessions around the future of testing at Drupalcon Amsterdam so be sure to check these out if testing is your thing.
The Consensus Banana is moving full-steam ahead with loads of issues resolved to move classes out of preprocessing and into templates landing this week. Meanwhile in Split Seven's style.css into SMACSS categories @LewisNyman has been making great strides towards bringing sanity to Seven's CSS structure.
@WimLeers, @alexpott and @chx worked tirelessly in Add cacheability metadata to access checks to harmonize our access-checking systems and add cacheability to the access results in the form of an AccessResultInterface, great work!
Over in Remove text_processing option from text fields, expose existing string field types as plain text in UI @Berdir, @Wim Leers, @dawehner consolidated our text field types, an important change for Site Builders.
Finally, PHPStorm 8 has been released with lots of support for Drupal 8 APIs!Where's Drupal 8 at in terms of release?
Since the last Drupal Core Update on Sept. 4, we've fixed 19 critical issues and 24 major issues, and added 12 criticals and 19 majors. That puts us overall at 97 release-blocking critical issues and 644 major issues.Where can I help? Top criticals to hit this week
Each week, we check with core maintainers and contributors for the "extra critical" criticals that are blocking other work. These issues are often tough problems with a long history. If you're familiar with the problem-space of one of these issues and have the time to dig in, help drive it forward by reviewing, improving, and testing its patch, and by making sure the issue's summary is up to date and any API changes are documented with a draft change record, we could use your help!
- SqlContentEntityStorage::onFieldStorageDefinition(Create|Update|Delete)() is broken for base fields is the final step of the our last beta blocker. Reviews and manual testing welcomed.
- [Meta] Untangle Drupal 8 page rendering lays out the final steps to standardize the page building process. While it's not the result the SCOTCH initiative was hoping for it does line up the pieces needed to allow contrib to experiment with layout mechanisms in a clean and supported way. There are a bevy of child-issues for you to sink your teeth into.
There are also several beta deadline issues that, while not quite critical, will need to be done before the beta if they're to be done at all. The following beta deadline issues are especially important:
- #2002138: Use adapters for supporting typed data will improve developer experience for the Typed Data API, which in turn improves numerous other APIs.
- Field type (item) classes implementing AllowedValuesInterface::getPossible(Values|Options)() is incompatible with Views and possibly other use cases will make an important difference for Views as well as contributed modules like Rules.
- #2312093: Rename FieldInstanceConfig to FieldConfig is a final step to bring consistency and clarity to naming in the Field API.
- Now that we're nearing beta, its time to turn our attention to release-blocking criticals.
- Beta target issues are issues that can be added to Beta 1, Beta 2, or later, but would be best done sooner rather than later for solid beta releases.
- With a looming beta, now we can ramp up our efforts on contrib modules - there's a sprint at Amsterdam just for that - so put your name on the list if this is your thing.
As always, if you're new to contributing to core, check out Core contribution mentoring hours. Twice per week, you can log into IRC and helpful Drupal core mentors will get you set up with answers to any of your questions, plus provide some useful issues to work on.
You can also help by sponsoring independent Drupal core development.Notable Commits
The best of git log --since "2014-09-04" --pretty=oneline (200 commits in total):
- Issue 2333113 by effulgentsia, plach: Add an EntityDefinitionUpdateManager so that entity handlers can respond (e.g., by updating db schema) to code updates in a controlled way (e.g., from update.php).
- Issue 1857256 by dawehner, xjm, tim.plunkett, jibran, ParisLiakos, hussainweb, pcambra, ekes, InternetDevels, rhabbachi, rdrh555, tstoeckler, oadaeh, Gábor Hojtsy, vijaycs85: Fixed Convert the taxonomy listing and feed at /taxonomy/term/%term to Views.
- Issue 2333501 by swentel | marcvangend: Implement ThirdPartySettingsInterface in EntityView|FormDisplay.
- Issue 1740492 by dawehner, damiankloip, dasjo, xjm: Implement a default entity views data handler.
- Issue 2331019 by slashrsm: Implement ThirdPartySettingsInterface in Vocabulary.
- Issue 2320157 by moshe weitzman, Wim Leers, penyaskito, tim.plunkett: Generate placeholder content for Field types - essentially devel generate in core.
- Issue 2329485 by damiankloip, dawehner: Allow permissions.yml files to declare 'permission_callbacks' for dynamic permissions.
- Issue 1898478 by joelpittet, Cottser, lokapujya, m1r1k, jstoller, er.pushpinderrana, duellj, organicwire, jessebeach, idflood, Jalandhar, Risse, derheap, galooph, mike.roberts, tlattimore, nadavoid, LinL, steveoliver, chakrapani, likin, killerpoke, EVIIILJ, vlad.dancer, podarok, m86 | c4rl: Menu.inc - Convert theme_ functions to Twig.
- Issue 1915056 by Arla, Berdir, amateescu | catch: Use entity reference for taxonomy parents.
- Issue 2321745 by larowlan, tim.plunkett: Add #type => 'path' that accepts path but optionally stores URL object or route name and parameters.
- Issue 474004 by mdrummond, kim.pepper, Wim Leers, jibran, tim.plunkett, joachim | JohnAlbin: Add options to system menu block so primary and secondary menus can be blocks rather than variables - essentially menu block module in core.
- Issue 2068331 by roderik, slashrsm, pcambra, Sharique, piyuesh23, vijaycs85 | plach: Convert comment SQL queries to the Entity Query API.
- Issue 2226493 by Berdir, Wim Leers, m1r1k, mr.baileys, andypost, scor, cbr, joelpittet: Apply formatters and widgets to Node base fields.
- Issue 2302563 by chx, dawehner: Fixed Access check Url objects.
You can also always check the Change records for Drupal core for the full list of Drupal 8 API changes from Drupal 7.Drupal 8 Around the Interwebs
- Joe Schindler of Drupalize.me gave us Unravelling the Drupal 8 Plugin System an expansive run-down on Drupal 8's plugin architecture.
- Addison Berry, also of Drupalize.me tells us about what to expect now that a Drupal 8 beta is so close
- Dcycle gave us An approach to code driven development in Drupal 8
- Hernani Borges de Freitas of Acquia tells us about Web services in Drupal 8 Core
- Josef Dabernig of the D8 Rules team gives us a rundown on all the comings and goings around Rules in Drupal 8 in Amsterdam
- September 19 - October 3: DrupalCon Amsterdam in Amsterdam, The Netherlands is going to be amazing with lots of opportunities to learn about and get involved with Drupal 8. Be sure to sign up for the extended sprints!
- September 18 - Milwaukee:
Drupal414 meetup: Building a Drupal 8 theme with new fangled awesomeness - Marc Drummond will present on building a Drupal 8 theme
- September 18 - Washington, DC:Drupal 8 code sprint with Forum One - join Forum one to work on Drupal 8.
- September 20 - Helsinki: Join Wunderkraut to sprint on Drupal 8
- October 17 - Austria: Drupal 8 starter day a free workshop style introduction to Drupal 8
Do you follow Drupal Planet with devotion, or keep a close eye on the Drupal event calendar, or git pull origin 8.0.x every morning without fail before your coffee? We're looking for more contributors to help compile these posts. You could either take a few hours once every six weeks or so to put together a whole post, or help with one section more regularly. Read more about how you can volunteer to help with these posts!
Finally special thanks to KatteKrab for assisting with compiling this edition.
The granularity of cache expiration in Drupal has been a long-standing problem.
One can have the most effective cache in the world, but if it clears entirely on any content change, it is not really workable. A “page” in Drupal can have blocks, listing, entities, regions, and many other objects. When one contained item changes, the container of that item needs to be fully rebuilt; often, that is the whole page, a problem requiring a much-needed solution.
Why can't we just rebuild the parts that have actually changed?
Consider what would be the best case scenario here. Assume that every item listed above can be cached separately. Now if one single entity changes, the following would be our "perfect" page request:
- Drupal bootstraps.
- Drupal builds the page.
- Drupal notices that only the “content” region has changed and retrieves the remaining regions from cache.
- Drupal re-builds the content region.
- Drupal notices only one listing in the content region has changed and retrieves the remaining blocks from cache.
- Drupal builds the “missing” block.
- The block contains a listing of entities.
- Drupal re-builds the listing, and entity_view() is called on these entities.
- Drupal retrieves all entities except the changed one from cache.
We would have a bootstrap, then we would see just one region call, one block call, one listing call, and one entity building call. Is this really possible?
Yes and no.
There are certain implementation limitations – especially around page assets – and a unified caching strategy needs to take them into account.State of the Art
Render Caching is the saving of HTML content in a storage cache, while retaining assets like CSS and JS files and other “out-of-band” data. It can be used for reconstructing the page content, without changing the state the page would have without render caching active. The render cached HTML markup needs to be removed from the cache, or updated in the cache when the objects used for generation of the markup change.
Part 2 of a 2-part conversation with Angie Byron in front of the cameras at NYC Camp 2014, held at United Nations headquarters in New York. In this part of our conversation, we talk about improvements in the Drupal developer- and learning-experience thanks to the major changes under the hood in Drupal 8; the "PHP Renaissance"; and about being welcomed "back into the fold" of the greater PHP world thanks to the nature of Drupal 8 being a sort of "meta project" (my words) that includes parts of many others.
This summer, ThinkShout was named the 9th Fastest Growing Private Company in Portland, Oregon. Admittedly, this came as sort of a shock to me and Lev. Over three and a half years, we’ve grown the company from two dudes renting desks in an incubator space to a full-time team of 17 professionals averaging 10 years of experience each. But most of the time, it doesn’t feel like we’ve come up with any secret sauce for running a successful business. We try to listen to our employees and our peers in the industry. We partner with nonprofit clients trying to make the world a better place, and we do our best to treat them with integrity in all aspects of our work - from our design and engineering practices to our approach to project management and our billing process.
Perhaps there are a few things that we do particularly well. We win our fair share of work in coopetition with our peers in the nonprofit tech industry. But then again, in talking with our friends at ZivTech, Gorton Studios, Aten Design Group, Jackson River, Forum One Communications, and others, what we consistently hear is that there is more than enough work to go around in the world of technology for good.
How is that? What are the mechanics of "the small business of open source" that work for all these firms and, more importantly, for their customers?
You could tackle this question from a number of angles. Conventional wisdom suggests that the business value of open source, both in the for-profit and nonprofit sectors, is simply: you get a lot of stuff for free. This is true. With open source, you avoid licensing fees. With an open source platform such as Drupal, you can pick and choose among literally tens of thousands of free tools and extensions.
But this perspective speaks only to open source’s initial customer appeal. It speaks to the coarse outlines of the sales cycle of open source. You can’t just build a sustainable business off the idea that a platform like Drupal provides a lot of stuff for free.
So, what is the guiding principle of growing a small business around open source? For us, it boils down to:
Our customers benefit tremendously from their own contributions to open source.
Put a bit more bluntly:
Our customers benefit from paying us to give away their code.
To illustrate this point, I’d like to run through some of our numbers as a small business of open source. The following statistics are relative to the publication date of this blog post:
ThinkShout’s team includes 8 engineers with a total of 4,269 commits to contributed modules hosted on Drupal.org.
We actively maintain 24 contributed modules that represent over 100,000 lines of code.
The combined installation base of these modules (i.e., the aggregated number of websites using each of these modules) is over 42,000.
Interestingly, our staff has grown 750% from the end of our first quarter. The growth in adoption of our contributed tools by the community (1,400% since the end of Q1 2011) tracks closely with the growth of our quarterly revenues (1,300%).
Obviously, these statistics are only related anecdotally. On their own, they don’t prove that our open source contributions drive our success.
Still, it is interesting to look at some of the statistics around our client work:
Averaging the last four $80-$150K Drupal website projects we’ve completed, a typical project in this price range is made up of 36,289 lines of custom code and exported site configuration (excluding the theme, or the implementation of the graphic design).
In addition, most of these projects include the release of 1,000-5,000 lines of contributed code. In other words, clients who engage with us on these sorts of projects pay for us either to contribute back major features to a contributed module, or to release one or two stand-alone modules.
But what’s most interesting is that each of these projects leverage at least 4 to 5 of the contributed modules that other clients have paid for on previous projects. Each leverages around 20,000 lines of contributed code that our team has written for similar use cases.
Of course, these statistics reflect the significant cost savings to our clients in going with an open source solution. They get a lot of free stuff…
But more importantly, our clients benefit from becoming financially invested in the direction and cultivation of these open source projects. By becoming committers, they are ensured that their requirements will continue to be prioritized in the future development of the modules their website depend on. They benefit too by the tens, sometimes hundreds, of open source developers reviewing their contributed code for bug fixes and improvements.
Moreover, by releasing the code that powers their websites, our clients connect with other organizations with similar requirements who, in turn, will often contribute additional features to these projects over time. As a case in point, we released the Leaflet module, a web-based mapping solution, on behalf of the Intertwine Alliance in the summer of 2011. The Alliance paid for the initial release, which included a modest yet highly-innovative feature set. Since then, 36 different Drupal developers have contributed code to improve the module, and over 4,500 websites have adopted it.
Similarly, we initially released RedHen CRM, a native CRM solution built entirely within Drupal, for a small cohort of nonprofits with similar needs. In this case, we actually got these nonprofits to work together to brainstorm and prioritize their CRM requirements. Pooling funding, this group helped us launch RedHen publicly in the spring of 2012. Since then, over a dozen of our clients have continued to invest in RedHen, and it has been adopted on over 850 websites around the world. Most impressively, those initial clients that funded our early work on RedHen continue to upgrade their sites with each new release, benefitting from hundreds of thousands of dollars of free development.
Client investments in open source present many less tangible benefits as well. While our developers are inspired to support our mission-driven nonprofit customers, they are particularly excited (and therefore, keenly focused) when their work leads to open source contributions. Not only does this lead to high-quality engineering, it helps reduce turnover among our engineering team, which can be costly for clients. Among our team’s contributors to Drupal, our average turnover is less than half of the industry standard in information technology.
For readers of this post who represent agencies that also contribute to open source, I’d be curious if your data and experience track to ours. Business and nonprofit readers whose teams have paid for open source contributions, I’d be curious to hear your stories as well. After all, open source is all about transparency, which we believe makes us a more effective business.
In this episode you will learn:Tags: DrupalDrupal 7Drupal Planet
In a recent project I got the opportunity to tweak Drupal’s Apache solr queries.In this blog p
With Drupal 8 looming on the horizon, everyone is talking about doing their part to contribute. In fact — shameless plug alert — Forum One is running a Drupal 8 Code Sprint tomorrow night! Come on out and code with us.
Wanting to get involved but new to Drupal development, I wasn’t really sure where to start. Through a Drupal DC meetup, I was introduced to the Drupal Ladder. Following the Drupal Core Ladder, I got a practice Drupal environment set up, got familiar with the issue queue, and tested some patches! Of course, all the issues and patches written and tested for the LEARN portion of the ladder only affect the sandbox version of D8 used in the tutorials, but it gives you a great idea of what to expect.
After working through the Ladder, I felt ready to attend some Drupal code sprints. However, one of the biggest problems new people have at code sprints is setting up their Drupal environment. As a newbie, I found the quickest way to set up a test environment on my Mac was through the Acquia Dev Desktop. This is a stack built specifically for Drupal (it’s pre-loaded with Apache, MySQL, PHP, etc.), so no downloads other than Drupal itself should be necessary. For this tutorial, we’ll be using Acquia Dev Desktop 2 Beta.
Note: although I am using the Mac version, the Windows instructions should be the same.Installing Acquia Dev Desktop 2 Beta
From the downloads page, click on Mac / Win Download within the, “Get the Acquia Dev Desktop 2 Beta” box at the top of the page. Locate your download file and double click the file to launch the installer.
- Click Next on the initial screen. The following screen will give you an overview of what is included in the Dev Desktop package: Apache, MySQL, PHP, etc. Review these and click Next.
- Review the license agreement, click Yes if you accept the terms, and then click Next.
- Make note of this next screen. This lets you choose the install locations of your stack and Sites folder. I would recommend leaving these as the default selections.
- The next screen displays the port settings that will be used by Dev Desktop. Do not change these. Simply make note of them and click Next.
- Review your information, then click Next, then Next again to begin the installation.
- Once the installation has completed, click on Finish. If the program pops up, minimize it. We must first download a copy of Drupal 8.
After installing Dev Desktop, we can now get our Drupal 8 environment running:
- Download your desired version of Drupal 8 (use Drupal 8.0.x-dev if you are going to help test and develop D8) by clicking on the .tar file for Mac or .zip for PC in the Download column. Be sure to extract the tar/zip folder if your system does not automatically do it!
- You can place the files inside your Sites folder, or simply leave it where it downloaded. It is advisable to change the name of the directory from “drupalx.x-x.x” to something simpler (e.g. drupal8, drupaltest, d8dev, etc.).
- Bring back up Acquia Dev Desktop, or launch it. Click on Start with an existing Drupal site located on my computer.
- For Local codebase folder, select the Drupal root folder you just downloaded and click on Open. You can leave Local site name as is, or change it up.
- Drupal 8 requires at least PHP 5.4, so select the PHP version 5.4 your Dev Desktop came with.
- For Database, select Create a new database. You can leave New database name as is, or alter as you like.
- Click OK, and your site will be imported into Dev Desktop.
- Select your site from the left, if it is not already selected. At the top of Dev Desktop, click on your Local site URL and it will come up in your default browser.
- On initial launch, your site should go to /install.php. If not, manually enter /install.php to the end of your site URL (e.g. http://drupal8.local:8083/install.php). Select your language, and click on Save and continue.
- Leave Standard selected as your installation profile. Click Save and continue.
- The database info should transfer and auto-fill into the fields, but just in case, enter the following info:
- Database name: name you created during the import (New database name)
- Database username: drupaluser or root
- Leave the password blank
- Under the Advanced Options: Host: 127.0.0.1 & Port number: 33067
Click on Save and continue once the information has been filled out.
Drupal will now install your site. Once finished, enter whatever you’d like for the site name, email, and user configuration, and your Drupal site should be up and running! Be sure to remember the username and password for the account you created, as this is your main administrator account (user 1).That’s All, Folks
Installing Acquia Dev Desktop is fairly quick simple if you follow these steps. Don’t let not having a dev environment stop you from participating in Drupal 8 code sprints, as there are plenty of other AMP stacks available to install, making sure you’re comfortable with one goes a long way. With my development environment setup all that’s left to do now is to actually write a patch…Maybe I’ll take care of that during Forum One’s code sprint tomorrow night!
Have you always wanted to get involved with Drupal core development but don’t know where to begin? Have a Drupal 6 site that you’re looking to upgrade to Drupal 8? The Drupal 8 Migrate in Core initiative aims to provide a robust and extensible migration path from Drupal 6 and Drupal 7 to Drupal 8. A lot of work has already been done, but we’re looking to increase our throughput by training up some testers and developers to contribute to the cause.
To that end, we’ve planned two in-person events and an ongoing virtual event where you can get some facetime with other contributors to get you up-to-speed on the current progress and how you can help. Development experience isn’t required! It takes all types of contributors to complete a project of this scope. We have opportunities for manual testing, documentation writing, UX, theming, patch testing, and patch creating. If you need more of a challenge, I’m sure that chx, benjy, and mikeryan can find something for you to sink your teeth into!
If you can’t wait to get started, please check out how you can properly configure your system in order to contribute. Even if you just want to do some manual testing, you’ll want to check this out. Once your system is ready to go, then find me in IRC (#drupal-migrate) or find us at an upcoming event.-->
This post originally ran on the ADCI blog, and has been reposted with their permission.
On August 30th ADCI Solutions and Omsk Drupal community participated in a worldwide event and organized the first Drupal Global Training Day.
This unique program is being conducted around the world since 2012. Every quarter training activities take place in different countries and cities in a single day. The Drupal Association promotes Drupal Global Training Days where various organizations across the globe host free events to bring people into the Drupal community.
Simultaneously with us 36 companies in Rome, London, Sydney, Madrid, Milan, Chicago, New York, Pakistan, India, and other far-away places conducted trainings for Drupal beginners.
Drupal is an advanced platform with open source software, which is developing dynamically, because about six hundred of thousands of developers around the world are constantly working on the project. Drupal is used for websites of any complexity: from blogs to public and government portals. Sites of the White House, The Beatles, Aeroflot, MTV, Forbes, GEO are working on Drupal.
Learning about Drupal
More than forty people came to get and share knowledge, among them were students, programmers, content managers, experienced developers and newbies who are at their start on the Drupal-way. The training program was built so that students first learned what Drupal is, where it comes from and who it is developed by, what its characteristics are, what open source technology and drupal community are. Then followed a report about advantages and disadvantages of Drupal, for what types of projects it is most effective to use.
During the coffee break, we gave T-shirts with the logo of the Omsk Drupal community to the wiiners of our competitions and made a group photo.
Then we moved on to the practical part. Audience took the basic steps of creating a site. Everybody learned how the Drupal looks and what opportunities it gives out of the box. Without writing a single line of code we made a news site with flexible content filters and sponsors' logos in the footer. Drupal allows an individual, a community of users, or an enterprise to easily publish, manage and organize a wide variety of content on a website. Its modular architecture allows you to put together the components you need to build practically any site. For those who have a general idea of how it works, but have no practical experience, the course was an excellent start.
The day ended with a report on theming. Students learned basic rules that should be followed in order that work with the theme was simple and clear, got aquainted with popular themes and learned how to create their own theme effortlessly.
A Community of Amazing People
As it was the first meeting in the new format of the training, we asked the guests to fill out a short feedback questionnaire. We wanted to know what people are interested in, and what they would like to hear next time. Thanks to the participants, we are pleased to see you. Everyone appreciated the initiative of free educational software. Most noted that they came to learn how to work with Drupal, and this training helped them to make the first step. We were pleased to see the live chat during the break, when the speakers are willing to explain something to beginners with a cup of coffee.
Of course, in the technical sense, Drupal is a CMS/CMF, but for thousands of people it is much more. This community is full of amazing people who are open to dialogue and able to inspire. Last year, the Drupal Association registered 2765 Drupal events. Glad that this year we will fill up this number.
My blog has been suffering alongside my work with DrupalCamp Gothenburg. It's hard work since we're only two guys making it happen this year, and there's a lot done and more to do. It brings me great pleasure to say that we just passed a major mile-stone when releasing the website for DrupalCamp Gothenburg. It's a new take on camp-sites, at least what I can gather. This site wont disappear after a couple of years, when the community looses interest in it. This site will not only promote this year's camp, it will also act as a collection of the earlier sites, tying sessions together, acting like a "blast from the past" - one site to rule them all.
Why, you might ask? Well, time is limited and since it's hard to get volonteers in Gothenburg to help out, this is a way to tighten the information flow and a way to skip doing the same thing year after year (making, coding and releasing a new site). Instead, we will focus on presenting the information from former DrupalCamps in a good way on the site, perhaps making it more interesting for our sponsors since their sponsoring presence won't disappear after a couple of years.
This year, though, we have a new design, since it's a new take on the website all together, and Daniel Andréasson is the one pulling the strings behind the curtain. He has done a lot of work on it, and I'm truly grateful for his help. His effort has given me the chance to focus on the sponsoring part, talking to hotels to bring good rebates to our visitors during the camp-weekend, and also see if some of all the other ideas might come to life at the camp.
Ever have wanted to import data into your Drupal site from JSON or a big ol' PHP array? You don't need to sweat all the gory details of matching up nodes and fields and coding massive for loops. Let the Drupal Feeds module do that for you.
In the immortal words of Queen: “all I wanna do is bicycle!” If you’re heck on two wheels and love nothing more than the feeling of the wind on your face and pavement whizzing underneath your wheels, you may want to consider joining in the Tour de Drupal leading up to DrupalCon Amsterdam.
Drupalers from countries all across Europe are teaming up for the Tour de Drupal, an epic bike ride from the UK and Switzerland to Amsterdam. Taking place the weekend before DrupalCon Amsterdam, the triumphant arrival of the Drupalcyclistas is expected on Sunday, September 28th between 4 and 5 PM at Eta Vondelpark in Amsterdam.
It’s not too late to join in on the bike ride, where you can find information here. Of course, if cross-country bicycling doesn’t do it for you but you still want to cruise around with a crew of awesome folks, consider renting a Yellow Bike during DrupalCon Amsterdam. For €50, you can rent a bike, a bike helmet, two bike locks, a bike map of greater Amsterdam, and insurance. The rental is from Monday-Friday. You can find more information here.
There are a lot of passionate bikers in the Drupal community— and we all care about our causes, too. UK Tour de Drupaler Alan Burke is combining his love of biking and charity by participating in a two-day, 360 kilometer cycle around Galway for charity. For more information about Alan’s ride, click here.
Regardless of whether you fly, bike, or take a train— we’re looking forward to seeing you in Amsterdam.
Image by Sonny Abesamis on Flickr.
Every modern framework nowadays provides a scaffolding tool code generator for speeding up the process of starting a new project and avoiding repetitive tasks. Now Drupal does, too! In this session you can build a module while following along with the live demo. You will learn how to take advantage of the Symfony Console Component to provide a CLI tool that automates the creation of Drupal 8 modules, automatically generating the module directory structure, controllers, forms, services, plugins, and required configuration files.
I just returned from my first CiviCRM sprint. It was called the DC Sprint, but as Jeremy has already posted, we were actually in Maryland.
As a first time attendee of a CiviCRM conference and sprint, I really did not know what to expect. I was very pleased that both WordPress and Joomla! received some real attention at the sprint and I hope we are heading to a place where CiviCRM can be truly CMS agnostic.
WordPress CiviCRM installs can now benefit from WP-CLI tools. WP-CLI is a Drush equivilant for WordPress. We were able to merge Andy Walker's port into 4.5 and Tim Otten added full API Explorer support for this. At the developer training day in DC on Saturday, we noticed an issue with civix and WordPress. This also fixed and now civix works with all CMSs without having to be directly tied to one as in the past. These two enhancements will help WordPress developers immensely.
Dana Skallman and I also worked through the unresolved tickets for WordPress. A great deal of progress has been made there, and in addition to all the new features in 4.5 users will find that the WordPress integration is better than ever.
What really made the sprint a great event were the people. We had three CMSs represented and while there was some good natured kidding going on, it is clear to me that the community is focused on the CiviCRM project and supporting Drupal, Joomla! and WordPress.
I cannot wait to see the 4.5 release and I encourage everyone to participate in the CiviCRM Community. Whether you go to a meetup, attend CiviCon in the spring or go to the next Code Sprint, you will not be disappointed and the community will be the better for it.
GSoC 2014 is over and it was a great summer for me. As a student, I lead the development of Entity Embed module for Drupal 8. I learnt a lot about Drupal 8 and the core values of Drupal community. Apart from working on my project, I also got involved with the Media Team and now I'm also trying to contribute to some of the other projects of the Drupal 8 Media initiative. It's been a fun journey with Drupal so far and I expect it to become even better.
To top it all off, I've been selected as a delegate to represent Drupal at the GSoC Reunion summit. Details at the original post on gdo. I'm absolutely delighted that I've been selected as one of the delegates given the fact that Drupal os such a big community. What makes it even better is the fact that Angie Byron, (webchick) will be accompanying me at the summit as she's the other delegate. Its going to be a great chance for me to meet her in person.
I'm all set for the summit. Visa approved, flight & hotel booked. I'm eagerly waiting for this summit and I'm extremely thankful to the Drupal community for providing me with this wonderful opportunity.Tags: Google Summer of CodeReunion SummitgsocDrupal Planet
There are many different ways to host a Drupal website.
Giving back to the Drupal community was one thing I wanted to make sure we did more of as a company. It's been a little over a year since I took ownership of LightSky and our Drupal contributions are increasing. We are actively contributing patches where we can, sponsoring local Drupal meetups and camps and even hanging out on IRC. One thing we have not done until now was to contribute a module. At some point, I would like all my development staff to contribute a module (or modules) back to the community and I figured if I was to ask this of my staff, it was only fair that I did it first. It took some time to figure out what to contribute back, but once I had an idea I was excited to get started.
My first attempt was to write a Tweet Embed module. It would create an input filter so that when you dropped a link to a tweet into it, it would embed it into the content. I spent a few weeks polishing the module and felt ready to submit it to review. After submitting it, it was discovered by an approver that there was an issue in the Twitter module issue queue to implement this exact functionality. That means this module was a no go since it would cause duplication. At the time I was frustrated, but only at myself. I should have been more diligent on ensuring that I was not duplicating functionality.
My second attempt, and the one that would be successful, was to write a module to encapsulate the LinkedIn Company API. The module would pull in shares and display them in a themeable block. I wound up writing two modules, one for the authentication and one to pull in the shares. I spent some time writing, testing and polishing and finally felt it was ready to submit.The Review Process
The review process was immensely helpful. It is encouraged that you do a peer review of three other modules that are awaiting approval. This allows your application to move a little more quickly through the process, but I would encourage you to do it even if that is not something you are interested in. For me, the review process did a few things. One, it allowed me to see how other people were solving problems in Drupal. I've been doing Drupal development for five years or so, but there are always things to learn. It also allowed me to become intimately familiar with what is expected of your module during the review process. After I did my initial set of reviews, I found myself going back to my module and making improvements that I may have not made otherwise.
After adding the reviews to my application issue, I started to get feedback on my module. The feedback that was given was very helpful and informative. I can confidently say that I learned a few things in the process. I got quite a few reviews of my module and each pointed out things that I should fix. At one point the reviewers asked me to contact the LinkedIn module maintainers and verify that my modules functionality was not something they intended to implement. It was not and I got the green light to move forward. From there my module sat in a RTBC state for 3-4 weeks. It was difficult during this time to remain patient, but with so many applications awaiting approval and so few approvers, this is what happens. Eventually, I was granted the ability to promote my module to a full project, and the ability to create full projects in the future.Final Thoughts and Tips
The review process is thorough, and that is a good thing. As a community we want to make sure that the people who are submitting modules are properly vetted and that they use best practices when coding. Although there was a bit of inactivity after the module was RTBC, it was not unbearable and if anything has encouraged me to remain involved in the review process to help alleviate some of the load. The biggest tip I can give is to not only be patient, but also be open to criticism. It's a little nerve wracking to have many people comb through your code line by line, but that is the nature of open source software. The feedback they provide will help you become a better Drupal developer and I know for me it was very exciting to learn how I could do things better. One of my big stumbling blocks the first time around was the fact that I did not do enough research when determining what module to write. Make sure that the module you are submitting doesn't duplicate functionality of another module. If there is a similar module out there, create an issue asking if they intended to implement your functionality. Sometimes a patch is a better place for a piece of functionality than a module and that is how it should be. Putting in a little extra research and effort on your end early on will prevent headaches during the review process.
If contributing is something you want to do, I would encourage you to take the jump and do it. I really do believe that you get back ten times what you give to the Drupal community.
If you have not already be sure to follow us on social media or subscribe to our RSS feed and newsletter. You can also contact us directly or request a consultation.