Skip to Content

Planet Drupal

Syndicate content
Drupal.org - aggregated feeds in category Planet Drupal
Updated: 1 day 16 hours ago

Annertech: Thoughts on DrupalCon LA's Front End Forum

14 May 2015 - 4:34am
Thoughts on DrupalCon LA's Front End Forum

At DrupalconLA, I had the opportunity to go to an Open Front End Forum, wherein people chatted about the state of the front end. It was good fun, and the moderator did a good job of keeping the conversation flowing.

First question: "Where is the line that separates front end from back end?"

There was some disagreement on that. There is a line, there is no line, it's a permeable line... Going on to explore what defined front end or backend, people cited tasks and tools like PHP, HTML/CSS/JS, the browser, Photoshop, in favour of one argument or another.

Categories: Drupal

Trellon.com: Agile Design Techniques - Video Is Live

13 May 2015 - 5:47pm

Trellon presented a session about Agile design techniques at Drupalcon Los Angeles which was very well received. Over 100 people were in attendance to hear Blake Maples, Mike Haggerty and Jake Tooman talk about the way we introduced Agile design within Trellon and made it work for the groups we serve.

Slides from the presentation are available at the following URL:

https://docs.google.com/presentation/d/1XwXELD7pIQ8CQUuNCv00hxaavUWeaKBj...

Categories: Drupal

Pixelite: Drupal Migrate D2D :: Taxonomy terms on nodes

13 May 2015 - 5:00pm

A migration project I am currently working on hit a small hurdle with taxonomy terms on a content type. This took too long to resolve. Hopefully posting this here will save others the time and hassle I went though.

Migrate D2D

I am going to assume that if you are reading this you are already using the migrate_d2d module so I won’t go into the big explanation about what it is, why you should use it and just how greatful we all should be to Mike Ryan.

Node migration and taxonomies

After following the docs I found that my taxonomy field was not being populated. A little digging led me to the conclusion that this was not something d2d handled out of the box and it was something I would have to deal with myself. There are a number of moving parts involved with this and due to all of these I can understand why it is not something migrate d2d could do.

public function prepare($entity, $row)

The magic happens here. The prepare() function is the final thing to be called before the node object is saved. This is where we get to do any final tweaks or tidyups. You can find full detail on this in the Commonly implemented Migration methods page in the Migrate handbook.

In the prepare() function the $entity is the new object that we are about to save and the $row is our source object. At this point the taxonomy has been added to the $row.

Within the $row object the taxonomy has been added with its vid as the root level attribute. If you don’t know to watch for that it can catch you. Added to that it is the vid of the destination vocabulary that is used which caught me off guard. The situation I had did not have me migrating the vobacularies, just the terms within them and the vid for the Categories vocab was not the same on my development environment as it was on my staging environment. This caught me out initially as I don’t have direct access to the staging database to examine the content of tables.

source $row->{destination vid} = array({source tid}, {source tid}, {source tid})

Once it was realised that the vid was from the destination vocabulary things got easier. This is how the code looked in the end for me;

<?php public function prepare($node, $row) { // The node's terms are in an array under their destination vocab ID and // this is different from environment to environment. However, we've only // got one taxonomy... $keys = array_keys((array) $row); foreach ($keys as $key) { if (is_numeric($key)) { $cat_vid = $key; break; } } if (!empty($row->{$cat_vid})) { foreach ($row->{$cat_vid} as $tid) { // We want the tid of the term we have migrated. This lets us look it up // our migrate_map table. $new_tid = db_select('migrate_map_tncategoryterms', 'm') ->fields('m', array('destid1')) ->condition('sourceid1', $tid) ->execute() ->fetchField(); $node->field_category[LANGUAGE_NONE][]['tid'] = $new_tid; } } } ?> Caveats

This worked for me because I only had one taxonomy field to worry about. The moment you get more than one you will want to revisit the assignment of $new_tid to the appropriate field. This shouldn’t be a problem to hand code and if you have migrated the vocabularies too you may be able to use the migrate_map table to make something more dynamic.

Comments

If you have (or are currently) using migrate I would be interested to hear how you found it. Especially if you are migrating terms, but not the vocabulary.

Categories: Drupal

Midwestern Mac, LLC: Ansible for Drupal infrastructure and deployments - DrupalCon LA 2015 BoF

13 May 2015 - 2:57pm

We had a great discussion about how different companies and individuals are using Ansible for Drupal infrastructure management and deployments at DrupalCon LA, and I wanted to post some slides from my (short) intro to Ansible presentation here, as well as a few notes from the presentation.

The slides are below:

Notes from the BoF

If first gave an overview of the basics of Ansible, demonstrating some Ad-Hoc commands on my Raspberry Pi Dramble (a cluster of six Raspberry Pi 2 computers running Drupal 8), then we dove headfirst into a great conversation about Ansible and Drupal.

Categories: Drupal

Drupal Easy: DrupalEasy Podcast 152: DrupalCon Los Angeles - Day 1 Recap

13 May 2015 - 1:20pm
Download Podcast 152

Live (almost) from Los Angeles, Ryan, Ted, and Mike are joined by a few familiar voices for a quick recap of day 1 of DrupalCon. We talk highlights, songs from the prenote, special Drupal moments, and Ryan interviews Rob Loach from Kalamuna about Kalabox 2.0.

read more

Categories: Drupal

Another Drop in the Drupal Sea: DrupalCon LA Tuesday Recap

13 May 2015 - 9:26am

I followed my own advice from my DrupalCon for n00bs post, and took part in some great sessions, checked out a BOF, ran a BOF of my own and hung out a bit in the Exhibition Hall. I loved finding out about Symfony and Drupal 8 and am super excited about what the combination has to offer. I was pleasantly surprised by the attendance in my BOF. And, I picked up some great swag in the Exhibition Hall and had some nice conversations.

Let's just hope that they get the lunch situation sorted out better today!

read more

Categories: Drupal

Microserve: DrupalCamp Bristol 2015 - Speakers and Sponsors needed!

13 May 2015 - 9:24am

We're proud to say DrupalCamp Bristol 2015 is taking shape nicely; tickets are selling well, sessions are being submitted and we already have a number of Sponsors on board!

With just under 2 months to go we're now keen to get more sessions submitted and the remaining Sponsor spaces filled up. If you wish to propose a session for the Business day on Friday 3rd July then please get in touch with Rick Donohoe - rick@drupalcampbristol.co.uk. If you wish to submit a session for the Saturday conference day then please use the form on the website to submit your idea.

Looking to Sponsor the event? Get in touch here.

Lastly, thanks to everyone who has purchased a ticket so far and a big thanks to all the committee members for their hard work to date.

Rick Donohoe
Categories: Drupal

Vardot: The Drupal Ecosystem: How to Productize Your Drupal Services

13 May 2015 - 4:40am
Resources

As a web development firm scales, it will inevitably run into a complicated dilemma: whether or not to productize its services. Particularly with a complex and labor intensive content management system like Drupal, turning away from a business model built around providing specialized service to each individual client becomes increasingly logical as a web development firm expands and builds a reputation.

But, as you may have already noted, this comes at a cost—productizing your Drupal services means that each client ostensibly receives less individual attention from its web vendor. However, if done correctly, productizing your Drupal services will not only improve a web development firm's services, but will streamline the design and development process and insure that clients consistently receive excellent customer service, support, and, ultimately, superior web products.

So contemplating productizing your Drupal services doesn't need to run hand in hand with your company having an existential crisis. Here's why:

Productizing your web services means that you'll only need to develop a platform once, instead of starting from scratch each time you take on a project. It also means that a development firm only needs to maintain one system instead of several, which allows software engineers and customer support managers to focus all their energy on that particular system, and thereby improving overall experience for all of a firm's clients collectively.

So in short, what does productizing your web development services achieve? It reduces the total cost of ownership; reduces operational costs for the vendor; makes higher quality standards easier to attain; and finally, delivers a dependably high-quality product to clients. 

Check out this presentation assembled by Vardot's CEO, Mohammed Razem, that outlines the product vs. service debate by breaking down the phases of developing a website using Drupal. It details how consolidating these practices into a streamlined product will provide a more refined development and implementation process and will allow a team to produce more consistent products by cutting down on the unnecessary and time-consuming aspects associated with a service-focused model, and how that will result in better overall results.

Dig in: 

http://www.slideshare.net/doublethink/the-drupal-ecosystem-for-drupal-services

 

Tags:  Productize Drupal Drupal Services Drupal Planet Title:  The Drupal Ecosystem: How to Productize Your Drupal Services
Categories: Drupal

Midwestern Mac, LLC: Thoughts on the Acquia Certified Drupal Site Builder Exam

12 May 2015 - 10:16pm

After taking the trifecta of Acquia Developer Certification (General, Back-end, Front-end) exams and earned a new black 'Grand Master' sticker, I decided to complete the gauntlet and take the Acquia Certified Drupal Site Builder Exam at DrupalCon LA.

Categories: Drupal

ThinkDrop Consulting: Continuous Deployment, Integration, Testing & Delivery with Open DevShop

12 May 2015 - 4:34pm

Well before "DevOps" was a thing, and long before DevShop existed, was "CI". Continuous Integration is a critical part of successful software development.  As a web CMS, Drupal has lagged a bit behind in joining up with this world of CI.

One of the reasons that we don't see CI being used as much as we'd like is that it is hard to setup, and even harder to maintain long term.  Wiring up your version control systems to your servers and running tests on a continual basis takes some serious knowledge and experience. There are a lot of tools to try and make it easier, like Jenkins, but there is still a lot of setup and jerry-rigging needed to make everything flow smoothly from git push to test runs to QA analysis and acceptance.

Setup is one thing, keeping things running smoothly is another entirely. With a home-spun continuous integration system, the system operators are usually the only ones who know how it works. This can become a real challenge as people move to new jobs or have other responsibilities.

This is one of the reasons why we created DevShop: to make it ridiculously easy to setup and keep up a CI environment. DevShop's mission is to have everything you need out of the box, with as little setup, or at least as simple a setup process as possible.

Continuous Deployment

DevShop has always had Continuous Deployment: When a developer pushes code to the version control repository, it is deployed to any environment configured to follow that branch.  This is usually done on the main development branch, typically called master, and the environment is typically been called dev.

However for the last few years, DevShop has had the ability to host unlimited "branch environments".  This means that individual developers can work on their code on separate branches, and each one can get it's own copy of the site up and running on that branch.  This reduces the chances for conflicts between multiple developers and helps reduce the time needed to debug problems in the code because if you find a problem, you know what branch it came from.  

We've found that having branch environments is a much more productive way to code than a shared dev environment on the master branch.

Pull Request Environments

DevShop has been able to react to GitHub Pull Requests by creating a new environment since last year.  Each project can be configured to either clone an environment or run a fresh install every time a Pull Request is created. It will even tear down the environment when the Pull Request is closed.

Developers have less management to do using Pull Request environments: They don't need access to DevShop at all.  Everything is fully automated.

This method is even better than setting up branch environments, since Pull Requests are more than just code: anyone on the team can comment on every Pull Request, offering advice or asking questions about the proposed code.  Users can even comment on individual lines of code, making the peer review process smoother than ever by letting teams communicate directly on the code..

Continuous Testing

Recently we've added built-in behat testing to DevShop: When a "Test" task is triggered, the logs are saved to the server and displayed to users through the web interface in real time.   The pass or fail result is then displayed in the environment user interface as green or red, respectively, along with the full test results with each step highlighted with Pass, Fail, or Skipped.

This gives developers instant feedback on the state of their code, and, because it is running in an online environment, others can review the site and the test results along with them.  

The future of DevShop testing is to incorporate even more tests, like PHPUnit, CodeSniffer, and PHP Mess Detectors.  Having a common interface for all of these tests will help teams detect problems early and efficiently.

Continuous Integration

Continuous Integration can mean different things to different people.  In this context I am referring to the full integration of version control, environments, tests, and notifications to users.  By tying all of these things together, you can close the feedback look and accelerate software development dramatically.

GitHub, the most popular git host in the world, got to be that way in part by providing an extremely robust API that can be used to setup continuous integration systems. Each repository can have "Post commit receive" webhooks setup that will notify various systems that new code is available.

The "Deployments" API" allows your systems to notify github (and other systems) that code was deployed to certain environments.  The "Commit Status" API can be used to flag individual commits with a Pass, Fail, or Pending status.  This shows up in the web interface as a a green check, a red X, or an orange circle both on the commit and on each open Pull Request in the repository.  A failing commit will notify developers that they should "Merge with Caution", making it much less likely that code reviewers will merge bad code.

DevShop now leverages both the Deployments and the Commit status APIs for Pull Request environments.

Deployments are listed right in line with the commit logs of a pull request, and give the team direct links to the environments created by devshop.

Commit Statuses display not only a pass or fail status, but also link directy to test results, giving developers the instant feedback needed to respond quickly to issues.

Continuous Notification

An important part of any CI system is the notifications.  Without them, developers and their teams don't know that there is anything for them to do. GitHub has great integration with just about any chat service, and now so does DevShop.  

When your CI system is integrated with a chat service, the entire team gets visibility into the progress and status of the project.  New commits pushed notify others that there is new work to pull, and test notifications alert everyone to the passing or failing of those code pushes. Having immediate feedback on these types of things in crucial for maintaining a speedy development pace.

Continuous Delivery

With all of the pieces in place, you can start to think about Continuous Delivery.  Continuous Delivery is the act of "going live" with your code on a continuous basis, or at least very often.

DevShop allows your live environment to track a branch or a tag.  If tracking a tag, you must manually go in and deploy a new tag when you are ready to release your code.

If tracking a branch, however, your code will deploy as soon as it is pushed to that branch.  Deploy hooks ensure all of the appropriate things run after the code drop, such as update.php and cache clearing.  This is what makes continuous delivery possible.

If using Pull Requests for development, you can use GitHub's Merge button to deploy to live if you setup your production environment to track your main branch.  With the Commit Status and Deployment APIs, you can be sure that not only did the tests pass but the site looks good with the new code.

Merging to deploy to live is a great way to work.  You no longer need to access devshop to deploy a new tagged release, and you no longer need to manually merge code, hoping that everything works.

If it's green, it's working.  If your tests are robust enough, you can guarantee that the new code works.

If your tests are so complete that you start to reach 100% code coverage, you can start thinking about true continuous delivery: Tests Pass? Automatically merge to live and deploy.  This requires that your tests are amazing and reliable, but it is possible.

DevShop doesn't have the ability out of the box to setup true continuous delivery, but it would not take too much work.  You could use the hosting task status hook to fire off a merge using GitHub's API.

As more people start to use Continuous Delivery, we can work on incorporating that into the devshop process.

All wrapped up in a Bow

With DevShop, you will spend (much) less time on your support systems so you can focus on your websites.  We hope to continue to find ways to improve the development process and incorporate them directly into the platform.

We encourage everyone to embrace continuous integration principles on their projects, whether it is using DevShop or not.  Not only does efficiency go up, but code quality and morale does too.  

If you are a software developer, having tests in place will change your life. Everyone involved in the project, from clients to quality assurance folks to the dev team, will sleep better at night.

Tags: devshopcontinuous integrationPlanet Drupal
Categories: Drupal

Drupal core announcements: Drupal 8 beta 11 on Wednesday, May 27, 2015

12 May 2015 - 3:56pm

The next beta release for Drupal 8 will be beta 11! (Read more about beta releases.) The beta is scheduled for Wednesday, May 27, 2015.

To ensure a reliable release window for the beta, there will be a Drupal 8 commit freeze from 00:00 to 23:30 UTC on May 27.

Categories: Drupal

Amazee Labs: DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

12 May 2015 - 11:15am
DrupalCon Los Angeles - Day 1: Dawn of the Drupalistas

Yesterday, just shortly after the sun sprung up and sparked southern California’s beautiful coastal lines, the doors of LA’s Convention Center opened. Welcoming with it, a first wave of eager Drupalistas and surrounding them by its air conditioned walls. And for the subsequent days that are surely to follow, it will continue to receive and house those, transforming it, to the home of DrupalCon 2015.

To some of us, this day began just like two previous iterations in the past, with the Drupal 8 Training for Drupalistas. And like the preceding ones before, the turn out was again, lovely. A fresh batch of new ambitious students took their seats and embarked on a cinematic journey, led by our resident training director, Diana Montalion.

From lively exchanges of know-how, to focused, almost silent moments, the classroom experienced a day of captivating performances. And in-between those, pupils were given hourly breaks to take a breath and pick from a variety of delicious beverages (there were cookies!) and the oh so essential, mandatory coffee.

After a wholesome feast around noon-ish, the reins were passed on to Jason, who expertly guided the keen students through the inner workings of Drupal 8’s translation system. Shortly thereafter, Kathryn took over to introduce them to the beautiful side of Drupal 8 (theming!) before finally ending again within Diana’s experienced hands.

Meanwhile, the lower floor saw a much more handy development: the exhibition hall of large, empty at first, but slowly building up to a small but respectable miniature city of brands. Replacing muffled sounds of classroom keyboards with the repeating cracks of rising booths, only to be broken apart by the occasional clash of shouty staff members.

Thus the day drew to an end, and our students were being led on their way, charged with knowledge and filled with cookies. The building emptied its walls again to prepare for tomorrow, when at dawn, the drupalistas will rise again.

Categories: Drupal

Jim Birch: Dude, Where are my Templates? Using the Drupal 7 Theme Developer to find the way.

12 May 2015 - 10:11am

The first line of the description of the Drupal Theme Developer Module says that it is "Firebug for Drupal themeing".  I couldn't agree more.  This is the ultimate tool when you need to find out which theme hook, or which template file to modify based on your design and layout needs.

It is a finicky module though, it doesn't work with the latest version of one of it's dependencies, simplehtmldom API, and when turned on it can break your layout. 

Note that this module injects markers into the DOM to do its magic. This may cause some themes to behave erratically and less capable browsers may make it worse (especially IE)/. Enable it when needed, and disable it afterwards.

To ensure I install the correct branch of the modules, and to speed up enabling and disabling, I set up some aliases in my local/development computer's .bash_profile:

Read more

Categories: Drupal

Nikro: Moldcamp 2015 - Session Submissions!

12 May 2015 - 6:56am

If you haven't heard yet, we've announced earlier that Moldcamp 2015 is on it's way! Second edition of the Drupal Camp hosted by a small country in the Eastern Europe - Moldova.

Tags: 
Categories: Drupal

Drupalize.Me: Installing and Configuring Dreditor

12 May 2015 - 6:02am

With DrupalCon Los Angeles underway we thought it might be a good time to introduce (or reintroduce) folks to [Dreditor](https://dreditor.org/) (short for "Drupal editor"). Dreditor is a collection of user scripts, which alter browser behavior on specific pages on the drupal.org domain. The features of dreditor are mostly helpful in the issue queue and during the patch review process.

We have a video [Installing and using Dreditor](https://drupalize.me/videos/installing-and-using-dreditor) if you'd like to follow along, but since recording installation of Dreditor is even easier. Let's take a look at the changes, and how we can use this powerful tool to make interacting with the issue queue easier.

Categories: Drupal

Cocomore: MySQL - Setup

12 May 2015 - 5:58am

When setting up a MySQL Server there are a lot of things to consider. Most requirements depend on the intended usage of the system.

read more

Categories: Drupal

ERPAL: Manage agile projects with structure and control

12 May 2015 - 3:45am

In the previous part of our blog series, we talked about unrealistic budgets and deadlines. Today our focus is on structure and control in agile projects.

In software development, there’s a lot of conjuring and experimentation going on with agile projects, and many homemade definitions for the word "agile" are floating around. But agile only means that one reacts to changing project requirements, and is thus flexible during development, with the result being a software product that really provides value when used.

In large projects that extend over a longer period of time, conditions change; it’s natural. In order to maintain the defined project objectives despite these new conditions, the existing requirements need to be checked. To achieve this, it’s necessary to know what’s already been implemented and what’s still outstanding. Scrum and agile approach do not imply that:

  • there’s no planning in advance,
  • there’s no concept, or that
  • there aren’t any acceptances.

An agile project follows the same rules as I’ve described earlier, but changes are allowed. As always, you have to consider that unplanned things cannot be controlled. Often, the billing procedures are controversial. I’ve already written a post on this topic: Agile work at a fixed price. The very concept of an agile project provides a framework within which to move and control changes. This framework ensures that a path that was possibly set wrong from the start – that won’t lead to the defined target – simply is not taken. If the plan in an agile project doesn’t exist in the form of a concept, the current status of the project can’t be determined and evaluated.

 

Other blog posts of this series:

6 steps to avoiding unrealistic budgets and deadlines in projects

6 rules to follow to promote communication in projects

3 things to consider when creating project specifications

Agile projects for a fixed price? Yes you can!

Setting objectives in projects with these 3 rules

These 3 questions help you to ensure satisfactory project results

Categories: Drupal

Deeson: We're hiring: Creative Director

12 May 2015 - 12:23am
Could you be the one to make your mark here at Deeson?

We're looking for a Creative Director. That's a brand new role for us so you'll be the very first CD to grace our offices.

A lot of expectation? Maybe. But the perfect opportunity to lead our team of talented designers and put your stamp on some award-winning work.  

Why now? 

In short, we've increased our portfolio of clients and our designers are in demand. 

It's a perfect time for someone new to come and join our dynamic leadership team, contributing to key decisions as we enter our next phase of growth.

We're at a stage where we feel ready for a strong-minded Creative Director to help develop the team and help shape the direction of the agency.  

Why me?

We're looking for someone talented, that's a given.

But as well as a killer portfolio, we want someone who has an interest in nurturing the skills of those in their team. Development is really important to us at Deeson; we'll be looking for ideas about how you would grow your team's skills and confidence.    You could be a Senior Designer with tonnes of managerial experience looking for your next move or a Creative Director looking for your next challenge. If you fit the criteria we'd love to hear from you.   What else? A great bunch of people to work with and a progressive agency culture.   A huge range of benefits, including flexi working, team lunches and an unlimited training budget.    Oh, and we're located in one of the UK's most beautiful cities too. Check out our full story here.   Read the full job spec and apply here.       

 

Categories: Drupal

Deeson: Site configuration strategy (or how to manage your settings.php files)

12 May 2015 - 12:10am

Managing site configuration across multiple hosting and staging environments can get complicated, and if each one of these requires a settings.php file making sure that you consistently apply configuration can be a nightmare.

This is especially true when you start requiring different files at different points – it's very easy to lose track of which setting is where.

A typical example here at Deeson might be a site that's usually hosted on Acquia's platform, but that we need to be able to work locally on (we use VDD for this).

That probably gives you 3 settings.php files: one for your local, one for the live domain name and one for Acquia's staging URLs. We'll also have different configuration for each of these. An example is where both reroute email and shield need to be disabled only on live, if our site has 3rd party integrations then we'll configure different API keys on staging and caching is always on on live.

So, how do we solve this?

In much the same way that we don't create a site-wide views feature, and instead we use a modular approach – for example one feature for news and another for events, we should do the same with our configuration and split it up. We don't do this by environment, but by module. So all the performance stuff together, all the security stuff together etc.

For example, you might have a reroute email file, that could read something like this:

$conf['reroute_email_address'] = "rerouted_mail@example.com"; $conf['reroute_email_enable_message'] = TRUE; $conf['reroute_email_enable'] = TRUE; if (SETTINGS_LIVE_DOMAIN) { $conf['reroute_email_enable'] = FALSE; }

This is clearer and less error prone than the situation that can occur where you can't instantly tell which setting will apply in a given situation. And by coding your conditions defensively you'll improve security.

So it's possible that you might still have those three settings.php files, but instead of adding config directly to them all they do is define the database settings and then do something like this:

// e.g. dev, stage or prod or read from $_ENV['AH_SITE_ENVIRONMENT'] on Acquia. // Master.inc could read this instead of the “scopes” concept? define('SETTINGS_ENVIRONMENT', 'prod') // e.g. local or acquia define('SETTINGS_HOSTING', 'acquia'); <?php // TRUE only on the actual live domain - so any testing domains, including the "live preview" should give this FALSE. define('SETTINGS_LIVE_DOMAIN', FALSE | TRUE); foreach (glob('sites/all/conf/*.settings.inc') as $file) { require_once $file; }

See that glob call? Create files in a new dir – sites/all/conf – like thing.settings.inc and place your config in there, using 'if' statements to react to the different envrionments.

Glob sorts by file name, so prefix each of these files with a number if you need them to be in a specific order, e.g 00-master.inc, 10-reroute-email.inc.

Here are some suggestions for files you might create (all to end in .settings.inc):

  • drupal-defaults (Maybe copy settings.default.php in here and update it keep it in sync with core updates?)
  • master
  • warden
  • shield
  • reroute_email
  • mandrill
  • performance (caching, aggregation etc. Only force these on live, if you must)
  • your-api-here

In this manner we can create sets of default settings php files which are likely to be common across projects. This makes initial setup to our standards and best practice simple. Any deviation from the standards can then be configured and described in the main settings file for the site.

Categories: Drupal

DrupalCon News: Session Submission Live!

11 May 2015 - 9:21pm

With the call for papers officially open, we wanted to take a moment to give you all of the details you should know about sessions: what new and cool tracks we are offering, how to submit an awesome session submission, and how session selection works.

 

Categories: Drupal


Google+
about seo