Upgrading a Drupal distribution

Posted by Colan Schwartz on September 2, 2015 at 10:54pm
del.icio.us logo Digg logo Facebook logo Favorite logo Google+ logo identi.ca logo LinkedIn logo Reddit logo SlashDot logo StumbleUpon logo Technorati logo Twitter logo Topics: 

Upgrading Drupal distributions, technically referred to as installation profiles, can be tricky. If you aren't using Drupal Core, but rather a distribution of it, it's not possible to follow standard processes for upgrading Drupal core and contributed modules. You must upgrade the distribution as a whole.

In this article, we'll be working with the Web Experience Toolkit (wetkit) as the example distribution.

Assumptions Steps
  1. Switch to your Web directory and make sure your working tree is clean.
    1. cd $(drush dd @site); git status
  2. Note any commits made to the distro since it was last upgraded. These will have to be reapplied (cherry-picked in git-speak) after the upgrade unless they were explicitly added to the distro in the latest release. Find them with this command.
    • git log profiles/wetkit/
  3. Make sure that you read and understand any distro-specific information on upgrading it. In this example, the documentation is available over at Release Cycle / Updates.
  4. This is a workaround until Drush up should update contrib profiles as well is fixed. Download the distro with the following command. For the version number, use the version that was released immediately after the version that you currently have installed. For example, if you have 7.x-1.4, you need to download 7.x-1.5. If you're multiple versions behind, you'll need to repeat these instructions multiple times. Jumping more than one release ahead could cause problems.
  5. Unpack it.
    1. tar zxvf /tmp/wetkit-7.x-Y.Z-core.tar.gz --directory /tmp
  6. Move your sites folder out of the way so that it won't be overwritten. It's necessary to do this as the administrator to maintain permissions on the files directory.
    1. sudo mv sites /tmp
  7. Copy the new release's files into your Web dir. Don't copy core's Git ignore file; keep ours. This is a workaround for Rename core .gitignore file to example.gitignore and add explanatory comments.
    1. cp -r /tmp/wetkit-7.x-Y.Z/.htaccess /tmp/wetkit-7.x-Y.Z/* .
  8. Replace the new default sites dir with our own.
    1. rm -rf sites
    2. sudo mv /tmp/sites .
  9. Remove the distro-specific Git ignore files, as they'll cause us to ignore files we shouldn't.
    1. rm $(find profiles/wetkit -name ".gitignore")
  10. Stage all of the changed files.
    1. git add --all
  11. Commit the upgrade with a comment like, "Issue #123: Upgraded the WxT distro from release 7.x-A.B to 7.x-A.C."
    1. git commit
  12. Cherry-pick each of the commits that you noted in the first step. Ideally, these are upstream patches that you either found or posted yourself while working on the distro. For each commit message, use something like "Issue #567: Applied patch from https://www.drupal.org/node/1417630#comment-6810906." so you'll know if you'll be need to re-apply it again, or if it's been committed (and you no longer need to worry about it).

    1. git --edit cherry-pick COMMIT_ID_1
    2. git --edit cherry pick COMMIT_ID_2
    3. ...
  13. Update the database schema.
    1. drush updb
  14. Clear all of the application caches.
    1. drush cc all
  15. Test the local site to ensure everything is working.
Notes
  • Whenever we override the distro's module versions in sites/all/modules/contrib (this should be an extremely rare occurence, if ever), we should set up Profile Status Check. In fact, it probably wouldn't hurt to include this module in all of the official distributions.

This article, Upgrading a Drupal distribution, appeared first on the Colan Schwartz Consulting Services blog.

Categories: Planet Drupal

From Our Sponsor: Managing Data with Drupal

Posted by DrupalCon News on September 2, 2015 at 9:08pm

There has been a radical shift in how enterprises want to use Drupal. Their focus is moving from sites to integrated services., and this change is typically accompanied with a set of new technologies, such as MongoDB and Node.js. Still, the role of Drupal has become more central than ever. How?

Categories: Planet Drupal

Drupal: Add new operators to views filters (such as contained in CSV) or how to override default view's handlers

Posted by DrupalOnWindows on September 2, 2015 at 8:21pm
Language English

Today I'm going to show you how to turbo boost Drupal's default views filters with an example on how to add  a "Conatained in CSV" operator for Numeric and String filters.

Imagine a user wants to perform a batch operation on entities with ID's X, Y and Z. Unless they all appear on the same page, or you set the page size to inifinte this is impossible because Views Bulk Operations won't let you manually pick items between searches and/or pages.

We want something like this to happen:

More articles...
Categories: Planet Drupal

The Top 7 Reasons To Use Drupal In Higher Education

Posted by Axelerant Blog on September 2, 2015 at 6:00pm

In recent years, using Drupal in higher education is a popular choice among leading schools. It has become the preferred website platform for hundreds of higher education institutions around the world. Schools like Harvard University, University of Adelaide, Bentley University, Uncommon Schools, University of Waterloo, and Yale all agree that Drupal is the content management framework that supports the current and future needs of students, faculty, alumni, and their communities.

In short, Drupal has proven it serves higher education website needs. Here are seven specific reasons it's best for your school.

The Top 7 Reasons To Use Drupal In Higher Education I am Ready for College - Drupal at Universities

1. Multi-Site Functionality

Most universities and colleges maintain multi-faceted websites, ones that serve a broad range of purposes. By leveraging Drupal's inherent multi-site functionality, institutions provide their departments with a substantial toolbox and relevant media types for communicating with students, staff, and other users via a single system.

This multi-site capability helps institutions break out independent websites by giving control and ownership to individual departments. This significantly reduces administrative overhead from the IT office.

2. Easy Responsive Design Implementation

According to an eMarketer study, an estimated 90 percent of US college students will own a smartphone by the time they graduate in 2016. Another study done in 2012 has published findings that "nearly half of all 18 to 29 year-olds using the Internet, do most of their online browsing on their mobile device."

Academic centers can use Drupal to stay up-to-date and relevant to users by delivering smoother, responsive website experiences. Experiences from each user's device of choice. Drupal sites adapt to user evolutions, making it optimal for institutions with student demographics.

3. Workflow Modules

Drupal's Workflow modules and features set allows universities and colleges to control and manage the publication process effectively, without limiting its use as a mere content management tool. There's granular control available for every content publishing processes. At each step, employees can be notified to complete their tasks (like copy editing). This keeps team members from performing tasks out of order.

4. Content and User Access Control

With Content and User Access Control, site administrators can create privileges grouped together by access level, function, and role. These permission sets can be assigned to groups of users rather than manually granting privileges to each and every user. Permission sets help decentralize task responsibilities like creating, editing, and managing content. All without putting extra workload on your IT hub. These access control features are exceptionally handy with respect to university websites where professors, students, alumni, and site visitors require unique user experiences and different access rights.

5. Efficient Use of Taxonomy System

Drupal's taxonomy system is a robust method for classifying website content into groups. Taxonomy systems can be designed and deployed on a per-content basis. This ensures extremely efficient content categorization on the site, resulting in ease of access for site visitors or users. Through taxonomy usage only relevant content is delivered to user; this avoids distractions and simplifies navigation.

6. Collaboration Modules

Apart from forward-facing content—static pages, forums, course schedules, blogs, and articles—Drupal provides powerful collaboration features and document management for back-end users. These systems are not typically part of the public front-end, but are critical for faculty and students who require access to manuals, handbooks, procedural guides, and research documents. Because of its tools for collaboration, Drupal is arguably the best tool for supporting internal teams and research for university and college websites.

7. Single Sign-On

Most every higher education institution has existing authentication systems for email or other internal accounts. Through Drupal using LDAP and CAS, single sign-on academic websites are easily possible. These single point access integrations result in a secure environment for users to multiple resources and services through a single login.

Drupal Distributions for Higher Eduction

Want to get started with Drupal? There are complete Drupal distributions like OpenAcademy, OpenEDU, and OpenScholar for kickstarting educational sites. These higher education Drupal distributions will provide your academic website with relevant and highly useful features with little effort from your end.

Want More Help?

Axelerant has worked on multiple higher education projects, like SUNY Maritime's Drupal migration. Contact us below and we'll talk about how we can make Drupal happen for your institution.

[contact-form-7]

The post The Top 7 Reasons To Use Drupal In Higher Education first appeared on Axelerant.

Categories: Planet Drupal

Drupal 8 beta 15 on Friday, September 4, 2015

Posted by Drupal core announcements on September 2, 2015 at 4:38pm
Start:  2015-09-04 00:00 - 23:30 UTC User group meeting Organizers:  catch xjm

The next beta release for Drupal 8 will be beta 15! (Read more about beta releases.) The beta is scheduled for Friday, September 4, 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 September 4.

Beta 15 will include a couple of important API changes. See SafeMarkup::set(), SafeMarkup::checkPlain(), and other methods are removed from Drupal 8 core for details.

Categories: Planet Drupal

SafeMarkup::set(), SafeMarkup::checkPlain(), and other methods are removed from Drupal 8 core

Posted by Drupal core announcements on September 2, 2015 at 4:21pm

Before the release of the first Drupal 8 beta, Twig's autoescape functionality was enabled in Drupal 8 core. At the time, the SafeMarkup class was added in order to integrate Drupal core's own filtering and escaping APIs with Twig's.

Following extensive critical work on Drupal 8's sanitization APIs, most of the public API for the SafeMarkup class has been removed. Of particular note: for the next beta (beta 15), SafeMarkup::set() will be removed and SafeMarkup::checkPlain() will be deprecated for removal before 8.0.0.

SafeMarkup::set() will be removed

The SafeMarkup::set() method was documented for internal use when it was originally added. However, Drupal 8 core (as well as some contrib and custom modules) used it incorrectly to avoid unwanted escaping, because at the time there were not good examples for all usecases, particularly for code that assembled together multiple different strings of markup. Now, all core usages have been removed, and the change record has been updated to include recommended strategies for concatenating markup strings. Refer to this change record to replace any remaining usages of SafeMarkup::set().

SafeMarkup::checkPlain() is deprecated and will be removed

In Drupal 7 and earlier, check_plain() was important for sanitizing untrusted input for output to the page. In Drupal 8, Twig's autoescape provides this functionality for any variables passed to a Twig template, and other APIs are used in other circumstances.

When explicit escaping is needed, the most direct replacement for check_plain() or SafeMarkup::checkPlain() is Html::escape(). See the change record section on escaping text in Drupal 8 for details.

The correct use of t() and SafeMarkup::format() is not affected and these functions will still automatically escape input passed in the second parameter for a @variable or %variable placeholder. See the SafeMarkup::format() documentation for details.

Categories: Planet Drupal

VIDEO: DrupalCon Los Angeles Interview: Jen Lampton & Nate Haug

Posted by Drupal Watchdog on September 2, 2015 at 3:53pm

Jen Lampton and Nate Haug (co-founders, BackDrop CMS) explain their fork of Drupal 7: why they felt the move was necessary; who benefits from it; and the Drupal community’s reaction.
There’s also a blatant plug for Drupal Watchdog. (Which you should subscribe to, right now, before you forget: https://drupalwatchdog.com/subscribe/2015)

Tags:  DrupalCon DrupalCon Los Angeles Video Interview Video: 
Categories: Planet Drupal

Between Releases: When Should I Adopt the Newest Version of Drupal?

Posted by Lullabot on September 2, 2015 at 3:30pm

Watching the Drupal release cycle ebb and flow reminds me of sitting on the beach as the waves roll in. There is Drupal 5! It’s getting closer and closer! Finally it crashes on the beach in a splash of glory. But immediately, and initially imperceptibly, it starts to recede, making way for Drupal 6. And so the cycle goes, Drupal 5 recedes and Drupal 6 rushes in. Drupal 6 is overcome by Drupal 7. And now, as I write this, we’re watching as Drupal 7 washes back and Drupal 8 towers over the beach.

Each new version of Drupal is a huge improvement on the one before. But each version also introduces uncertainties. Is all that new functionality necessary? Has Drupal core become ‘bloated’? Does it do too much (or too little)? Will it be performant? How much work will it take to implement? Is it still buggy? And, arguably, the most important question of all, when will the contributed modules we need catch up?

So when is Drupal “ready” for our clients? If clients want a new site in this between-releases period, do we build it on the solid, safe, predictable older release? Or jump in with the shiny, new, improved release that is just over the horizon, or just released? Or do we wait for the new version to mature further and delay building a new site until it’s ready?

We’ve dealt with these questions over and over through the years. Knowing when to embrace and build on a new major release requires careful consideration along several axis, and making the right decision can be the difference between success and failure.Here are the guidelines I use.

How Complex is the Site?

If the site is simple and can be built primarily with Drupal Core, than the shiny new version is likely a safe bet. Contributed modules may add nice features, but creating the site without many (or any) of them will mitigate your risk.

Each new Drupal release pulls into core some functionality that was previously only possible using contributed modules. Drupal 5 allowed you to create custom content types in the UI. Drupal 7 added custom fields to core. Drupal 8 brings Views into core. And every Drupal release makes some contributed modules obsolete. If the new core functionality is a good match for what the site needs, we’ll be able to build a new site without using (and waiting for) those contributed modules, which would be a good reason to build out on the frontier.

Correspondingly, if the site requires many contributed modules that are not included in core, we’ll have to wait for, and perhaps help port, those modules before we can use the new version. If we can’t wait or can’t help we may have no choice but to use the older version, or wait until contributed modules catch up.

How Tight is the Deadline?

It will probably take longer to build a site on a new version of Drupal that everyone is still getting familiar with than an older version that is well understood. It always takes a little longer to do things when using new processes as when repeating patterns you’ve used many times before.

Delays will also be introduced while waiting for related functionality to be ready. Perhaps there is a contributed module that solves a problem, but it hasn’t been ported yet, so we have to stop and help port it. Or there may not be any contributed module that does anything close to what we need, requiring us to plan and write custom code to solve the problem. Latent bugs in the code may emerge only when real world sites start to use the platform, and we might have to take time to help fix them.

In contrast, if we’re using the mature version of Drupal, odds are good that the bugs have been uncovered and there is code somewhere to do pretty much anything that needs to be done. It might be a contributed module, or a post with examples of how others solved the problem, or a gist or sandbox somewhere. Whatever the problem, someone somewhere probably has already run into it. And that code will either solve the problem, or at least provide a foundation for a custom solution, meaning less custom code.

Basically, if the deadline is a key consideration, stick with the tried and true, mature version of Drupal. There just may not be enough time to fix bugs and create custom code or port contributed modules.

How Flexible is the Budget?

This is a corollary to the previous question. For all the same reasons that a deadline might be missed, the budget may be affected. It takes more time (and money) to write custom code (or stop and port related contributed modules). So again, if budget is tight and inflexible, it might be a bad decision to roll out a site on a shiny new version of Drupal.

How Flexible is the Scope?

If we use the latest, greatest, version of Drupal, is the scope flexible enough to allow us to leverage the way the new code works out of the box? If not, if the requirements of the new site force us to bend Drupal to our will, no matter what, it will require custom code. If we build on a more mature version of Drupal we may have more existing modules and code examples to rely on for that custom functionality. If we build on the bleeding edge, we’ll be much more on our own.

Where is the Data Coming From?

If this is a new, from-scratch site, and there’s no need to migrate old data in, that would be a good use case for building this shiny new site with the latest, greatest version of Drupal.

But if there is an existing site, and we need to not only create a new site, but also migrate data from the old site to the new, the question of which version to use gets more complicated. If the source is another, older Drupal site, there will (eventually) be a supported method to get data from the old site to the new site. Even so, that may not be fully ready when the new version of Drupal is released. Drupal 8 uses Migrate module for data migration, but only the Drupal 6 to Drupal 8 migration path is complete, and that migration process will likely improve in future point releases. The upgrade path in previous versions of Drupal was often fraught with problems early on. It's something that never gets fully baked until the new version is in use and the upgrade process is tested over and over with complex, real-world sites. So the need to migrate data is another reason to use the older, more mature version of Drupal (or to wait until the new release is more mature).

How Important Is the New Hotness?

Every version of Drupal has a few things that just weren’t possible in previous versions. CMI (Configuration Management) in Drupal 8 provides a much more rational process for deploying code and configuration changes than Drupal 7 does. Drupal 7 requires banging your head against the limitations of the Features module, which in turn is hampered by the fact that Drupal 7 core just isn’t architected in a way that makes this easy. And Drupal 8 core has built-in support for functionality previously only possible by using one or more additional Services modules in Drupal 7.

If these new features are critical features, and if struggling to solve them in older versions has been a time sink or requires complex contributed modules, it makes sense to dive into the latest greatest version that has this new functionality built in.

How Long Should It Last?

A final question is how often the site gets re-built. If it is likely to be redesigned and re-architected every two or three years to keep it fresh, there should be little concern about rolling out on the older, mature version of Drupal. Drupal 7 will be supported until Drupal 9 is released, and that is likely to be a long time in the future. If it will be many years before there will be budget to re-build this site that might be a reason to build it on the latest version, delaying the project if necessary until the latest version is fully supported by contributed modules and potential problems have been worked out.

It’s Complicated!

The ideas above are just part of the thought process we go through in evaluating when to use which version of Drupal. It’s often a complex question with no black and white answers. But I take pride in our ability to use our long experience with Drupal to help clients determine the best path forward in these between-release periods.

Categories: Planet Drupal

Views Bulk Operations Makes Mass Updates Easy in Drupal

Posted by OSTraining on September 2, 2015 at 3:18pm
bolt module drupal

Views Bulk Operations (VBO) is one of those modules whose name and Drupal.org description doesn't indicate how useful it is.

Here's the short version of what VBO does it:

  • Allows you quickly select all the items displayed in a View.
  • Allows you to perform advanced operations on all the items you selected.
Categories: Planet Drupal

Use the Boost Module to Improve Drupal's Cache

Posted by OSTraining on September 2, 2015 at 3:06pm
bolt module drupal

Drupal has strong default caching systems, but the Boost module significant improvements.

Boost creates a cache in the file system rather than the database, so Drupal never needs to commuicate with the database. This provides major a performance and scalability boost for sites that receiving mostly anonymous traffic (it doesn't help so much with logged-in users). 

Boost will cache and compress your site's HTML, XML, Ajax, CSS and Javascript. There's also a built-in that will regenerate pages once they are marked as expired.

Boost isn't always this easiest module to set-up, but this video will help you get started.

Categories: Planet Drupal

Staying Ahead on Security: Why Acquia is Disabling PHP 5.3

Posted by Acquia Developer Center Blog on September 2, 2015 at 2:46pm
Isaac Sukin

The biggest risk for any website is security. Research has shown that the average cost of a data breach is several million dollars. The last two years have seen a number of high-profile security breaches affecting millions of people, including:

Tags: acquia drupal planet
Categories: Planet Drupal

settings.local.php for Drupal 8

Posted by Wizzlern on September 2, 2015 at 2:40pm
Categories: Planet Drupal

147 - Using Drupal Console with Drupal 8 with Jesus Manuel Olivas - Modules Unraveled Podcast

Posted by Modules Unraveled on September 2, 2015 at 2:00pm
Photo of Jesus Manuel OlivasPublished: Wed, 09/02/15Download this episodeDrupal Console
  • What is Drupal Console?
    • It is a suite of tools that you run on a command line interface (CLI) to generate boilerplate code and interact with a Drupal 8 installation.
  • How is it different from Drush? And are there overlapping features?
    • There are many similarities between these two tools, but the main difference is how it was built, using an object-oriented architecture and Symfony components.
  • Will we continue to use both? Or will Drupal Console replace Drush?
    • I think we will keep using both at least for now and maybe at some point we can merge both tools.
  • What are some of the things that you will keep using Drush for in Drupal 8?
    • Site alias (sync, backup), download modules, installing the site.
  • Are you planning to introduce those features into Drupal Console?
    • Yes we are actually working on site alias.
  • What are some things that Drupal Console can do that Drush can’t?
  • Who is the intended audience of Drupal Console?
    • You can use Drupal Console to help you developing faster and smarter with Drupal 8
    • Developers and SiteBuilders since you can Generate code and files required by a Drupal 8 module and Interacting with your Drupal installation (debugging services, routes) you can put your site in Maintenance mode or Switch system performance configuration.
    • But you can use this tool to Learn Drupal 8.
    • We are also working on a GUI so if you are afraid of CLIs we will provide a web site you will be able to use and select what you want to generate (module, controller, services, blocks, entities, etc…) and generate and download the generated code.
  • Would it be fair to say that right now, it’s most useful to developers who are actually writing code, while later, it will also be useful for sitebuilders who are used to using Drush to create site, install modules and themes, and perform routine tasks?
Use Cases
  • What are some things you can do with DrupalConsole?
    • Drupal Console help you developing faster and smarter with Drupal 8.
    • Generating the code and files required by a Drupal 8 module.
    • Interacting with your Drupal installation.
    • Learning Drupal 8.
Updates and Future
  • You were on the Drupalize.me podcast back in February talking about Drupal Console, what are some of the improvements that have been made since then? (Especially with Drupal 8 progressing the way it is.)
Episode Links: Jesus on drupal.orgJesus on TwitterJesus on GitHubSupport ChannelDrupal Console WebsiteDrupal Console on TwitterDrupal Console DocumentationDrupal ComposerPresentation slides DrupalCampLA 2015Tags: Drupal Consoleplanet-drupal
Categories: Planet Drupal

Update module the next generation

Posted by Tim Millwood on September 2, 2015 at 12:48pm
In a post last week I discussed versioning in Drupal and briefly touched on version numbers in info...
Categories: Planet Drupal

Use AdvAgg Information tab to debug or optimize CSS and JS aggregates in Drupal 7

Posted by Four Kitchens on September 2, 2015 at 10:08am

Although Drupal tries its hardest to combine CSS and JS in the most optimal way, sometimes it needs some guidance. Using a practical example, we’ll become familiar with AdvAgg’s information tab, letting us identify files within aggregates so that they can receive special processing within other Drupal hooks.

Categories: Planet Drupal

Get ready for DrupalCon Barcelona Sprints and Mentoring

Posted by Realityloop on September 2, 2015 at 5:26am
2 Sep Brian Gilbert

The Realityloop team have been contributing at DrupalCon sprints since 2010, mentoring at sprints since 2013, and I've personally been a lead mentor at sprints since DrupalCon Austin last year. To Realityloop the best way to help an open source project thrive is to contribute back and this is one of the ways that we do that.  The whole Realityloop whole team we be mentoring at DrupalCon Barcelona so we'd love to see you attending.

What is a Sprint?

A sprint is simply a get-together of people involved in a project to further a focused development of the project. In the DrupalCon context it's where we all get to sit in a room together and make Drupal better.

Come join us at the DrupalCon sprints

DrupalCon Barcelona is only a few weeks away, and as usual there will be a lot of sprinting happening around and during the event! 

If you are interested in contributing - and we'd love you to get involved - there are a lot of resources available. If you've never contributed in the past you shouldn't assume you don't have the skills to contribute. Many of the things being worked on need people with experience in things other than coding, such as; design, project management, writing documentation, dev ops, testing, user experience, marketing, or just helping hands. 

If you will be mentoring at the First Time Sprinters Workshop we really appreciate you giving your time to help get new people involved.

To all who contribute, open source projects thrive with contribution from their communities so by contributing you are changing the world and directly helping Drupal grow. For that we thank-you!

On the Internet

Check the Barcelona website for the sprint schedule and location information. Sprinting is generally happening all the time and at multiple locations, if you will be mentoring keep an eye on the BoF schedule for the mentoring and triaging sessions.

On the Drupal website you can also find a lot of information on ways to get involved in the Drupal project and core mentoring or how to set up a local Drupal development environment for the First Time Sprinters workshop, how to use the issue queue and tasks for new contributors.

During the conference

At the conference there will be a Core Mentoring booth in the Exhibit Hall (booth 100), It is staffed by mentor volunteers and if you have questions about getting involved, being mentored.. or becoming a mentor, or anything else related to contributing please pay us a visit we'll be happy to answer your questions.

On the Friday after a DrupalCon there is always an all-day sprint. The attendees of this sprint will typically be working on any one of Drupal core, contributed modules and themes, Drupal related project, and even Drupal.org itself.

    • First-Time Sprinter Workshop
      If this will be your first Drupal sprint or you need help setting up your computer, then the First-Time Sprinter Workshop in room 116 is especially for you. It is hed in the morning of the Friday sprint, and mentors will be on hand to help you get setup and learn about the various tools used for contributing. If you do not have a working Drupal 8 environment on your machine installed from the git repositry, please attend this workshop. The mentors at this workshop will be focused on getting you ready to contribute so you can spend the afternoon at the..
       
       
    • Mentored Core Sprint
      This is all day session is where new contributors can come to get mentored help. Mentors at the Mentored Core Sprint in room 115 will help you pair up with another new contributor or several contributors, find an issue or issues that you are interested in to work on together, and work through the process of contributing. All skill levels and roles are welcome. This is not a developer only event. If you don't yet have a Drupal 8 development environment installed via git then for your benefit it is suggested to attend the First-Time Sprinter workshop before coming to this room.
       
       
    • General Sprints
      Experienced contributors are encouraged to attend the all-day General Sprints in room 114. Typically contributors in this area form groups to work on key initiatives, or you can form your own.
       

       


A reminder to sprint leads, mentors and experienced contributors

Make some time before the conference begins to update your issues. If you have easier issues tag them as "Novice", and review your issues for missing tags, especially ones that less experienced contributors or non-developers can assist with. some of these might be; rerolls, manual testing, change notice updates, or documentation

The mentoring team will be triaging the issue queue throughout the week. If you are interested in helping please attend the related BoF to discuss and pick issues appropriate for the Friday sprint.

Also, remember that extended sprints actually start on the 19th September, so it would be great if you can find time to update things before then.

Moral of the story

If your attending a DrupalCon and not attending the Sprints, your really missing out on a quite large part of the DrupalCon experience just one of the reasons I would urge anyone interested to get involved and contribute.

You'll get to make a lot of new friends and help make Drupal a better project, learn to be a better coder if that is your interest, find smart people to collaborate with, grow your karma quotient, have a lot of fun and maybe even get on stage for a live code commit!

Even if you're not a coder, you can be confirming bug reports, testing patches, writing documentation, creating marketing or training materials, planning event logistics, or even organizing your own local code sprint or camp... and this is just a small selection of the stuff that you'll be able to do as a contributor. Come change the world!

drupal planet
Categories: Planet Drupal

Local .htaccess environment conditionals, HTTPS example

Posted by Zoocha Blog on September 1, 2015 at 2:41pm
Platform DevelopmentWeb Development

Adapted from a post by the Nerdary  that basically deals with the problem of having .htaccess files that are different on your local and other environments.

This example deals with the headache of https and not wanting your local environment to automatically redirect to HTTPS. I am only posting the relevant code that sets up the environment variable.

<IfModule mod_rewrite.c>
  RewriteEngine on

  ### SET UP ENVIORNMENTS ###

  # Default environment is master ###
  RewriteRule .* - [E=ENVIRONMENT:master]

  # Environment is set to develop if the server names ends in local.com
  RewriteCond %{SERVER_NAME} .local.com$
  RewriteRule .* - [E=ENVIRONMENT:develop]
  ## END SET UP ENVIRONMENTS ###

  # Redirect HTTP to HTTPS only if environment is master
  RewriteCond %{ENV:ENVIRONMENT} master
  RewriteCond %{HTTPS} off
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

</IfModule>

Another cool thing about this is that we've also created a new $_SERVER['ENVIRONMENT'] variable that we can access in php. 

 

Categories: Planet Drupal

Dependency Injection

Posted by Red Crackle on September 1, 2015 at 2:06pm
If you are starting to learn about Drupal 8, you must have come across a term called "Dependency Injection". If you are wondering what it means, then this is the post you should read. Through examples, you will learn why dependency injection is useful for decoupling the code as well as unit testing effectively.
Categories: Planet Drupal

Avoid Using the node_load_multiple API Function

Posted by Wuinfo on September 1, 2015 at 12:26pm

In a large website with many nodes, stop using the node_load_multiple function. It potentially limits the site growing.

According to the document: "This function should be used whenever you need to load more than one node from the database." But, I want to say that we should avoid using this function as this open the door to system crash in the future.

I had written a blog before Design a Drupal website with a million nodes in mind. I had used this function as an example. It is true that node_load_multiple function enhance the performance. But, it comes with a price. When we load thousands of node into the memory, it exhausts the web server memory instantly. Then we get this infamous message: "Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate XYZ bytes) in ...".

This issue brought me to an attention when I am reading the code done by one of the well-known Drupal shops. In one of the recently launched high-profile project, the function is used to load all the show nodes in the system. It sounds to be troublesome to me at the beginning. We can not load all nodes if we are not sure how many it will be? Where there are a small amount of node in the system, that is fine. But if it is for a system there are over hundred thousand nodes, that is a big problem. As time goes by, we add more shows into the system; The utility function needs more memory to handle it. The physical memory limits the ability to add infinity show nodes into the system.

What is the best way to handle this situation? Avoid using the node_load_multiple function. If we have to use the node_load_multiple, limit the number of the node for node_load_multiple to load.

Categories: Planet Drupal

Why and how to build a social shopping project with Drupal: case study

Posted by InternetDevels on September 1, 2015 at 11:11am
 case study

Discover the post on social shopping projects in Drupal with some of the best secrets
of ecommerce website development for you ;)

Read more
Categories: Planet Drupal

Pages

Subscribe with RSS Subscribe to Drupal.org aggregator