Planet Drupal

Subscribe to flux Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Mis à jour : il y a 27 min 2 sec

Greater Los Angeles Drupal (GLAD): Los Angeles Announced as Host City for DrupalCon North America 2015

lun, 09/06/2014 - 22:33

You are invited to DrupalCon Los Angeles!

We're excited to invite you to Los Angeles, home to Hollywood and Silicon Beach, where technology and creativity meet.

Some of the world's best and biggest museums, universities and entertainment giants are in Los Angeles — and they all use Drupal. A Drupal powerhouse, Los Angeles is one of the most active areas for Drupal in the world. The Drupal community in and around Los Angeles organizes hundreds of Drupal events each year, including GLADCamp, Drupal Design Camp LA and DrupalCamp LA.

While you're enjoying DrupalCon, your family can enjoy Disneyland, bike rides at the beach, and culture and science at the Getty, Museum of Modern Art and the California Science Center. The Downtown area has a thriving nightlife, walkable streets and contrary to popular belief, is the heart of the LA Metro and can be enjoyed car-free.

We welcome you to DrupalCon Los Angeles and look forward to sharing our love for all the things that make Los Angeles spectacular.

Many thanks to CloudNYNE for the splash image and to Exaltation of Larks for writing the announcement used on the DrupalCon Los Angeles website.

Tags: DrupalCon LAPlanet Drupal
Catégories: Elsewhere

OhTheHugeManatee: Authenticated User Caching Concepts in Drupal 7

lun, 09/06/2014 - 22:21

Drupal has a wide variety of highly effective solutions for caching anonymous user content. The typical setup is APC, Memcached or Redis, and Varnish in front, and this can easily serve thousands of concurrent anonymous users. There is excellent documentation out there discussing this kind of simple caching.

But what about authenticated users? You can cache elements of the page using a method like Render cache, Entity Cache, or Views Content Cache. But Drupal still has to assemble each page for your users, a relatively heavy operation! If you want to address hundreds or thousands of authenticated users, you’re simply SOL by these traditional approaches.

Enter the Auth Cache suite of modules. Though this project has been around for quite some time, it had a reputation of being finicky and hard to set up. It got a significant rewrite in the last year thanks to znerol, and is now a powerhouse of a module that brings authenticated user caching much closer to regular users.

I will say that this is still not for the squeamish. You have to really understand the building blocks of your site, and you will have to make a plan for each unique layout on your site. There are some page elements that are quite hard to build this way, but for the most part Authcache makes this easy.

The theory

The idea behind authenticated user caching is simple. We already have a great caching mechanism for pages that stay exactly the same for all users. So we simply identify the parts of the page that will change for each user, and use a placeholder for them instead. Think of it as a tag in HTML. This way the page caching mechanism can ignore the customized content, and focus on the stuff that IS the same across all requests.

There are three major ways of doing this placeholder: AJAX, ESI, and Cookies.

With AJAX, you just include a little JS that says “fill this DIV with the contents of http://example.com/user/customized/thing”. The client’s web browser makes a second call to the server, which is configured to allow /user/customized/thing through the cache all the way to your website. Drupal (or whatever you’re running) fills in the HTML that belongs in that div and returns it to the browser. Congratulations! You just served an authenticated user a page which was 99% cached. You only had to generate the contents of one div.

ESI is short for Edge Side Includes, a small extension to HTML which effectively does the same thing as that Javascript, but on the “Edge server”. The Edge server is whatever service touches the HTTP request last before sending it to the client. Apache, NGINX, Varnish, pound… you want this to happen as far down the stack as you control. An ESI tag in your HTML looks like this:

1 <esi:include src="http://example.com/user/customized/thing" onerror="continue"/>

It’s pretty clear, even to a human reader, what this tag means: “replace this tag with the contents of http://example.com/user/customized/thing”. ESI actually supports some simple logic as well, but that’s not really relevant to what we’re doing here.

The only difference between ESI and AJAX is where the placeholder is filled. With ESI it happens on the edge service, and with AJAX it happens in the client browser. There is a subtle difference here: a page with ESI will not be delivered until all the ESI calls have returned something, while an AJAX page will return right away, even if the components don’t immediately appear. On the other hand, ESI is much better for degraded browsers. YMMV.

The last method is using Cookies. You can store arbitrary information on cookies, as long as you’re careful about security. That can be a very effective way to get certain limited information through a caching layer. Authcache actually comes with an example module for just such a use case. It passes the user’s name and account URL in a cookie, so you can display it in a block.

This is effective for very small amounts of information, but keep it limited. Cookie headers aren’t designed to hold large quantities of data, and reverse proxies can have a hard time if you put too much information in there. Still, it’s a neat trick that can cover you for that “Hello Username” block.

Authcache in Drupal

The Authcache suite of modules tries to automatically implement AJAX and/or ESI for you. It actually goes one step further, and implements a caching layer for those “fragments” which are to be returned via ESI/AJAX. The fragments can be stored in any caching system which implements DrupalCacheInterface, ie any caching module you’ve heard of. Memcache, APC, File Cache, Redis, MongoDB. The full page HTML with placeholders can be cached in Drupal’s normal page cache, in Boost, or in Varnish.

Once you have these caching mechanisms defined, it’s just a question of marking sections of your site which need a second callback. Authcache presents a large number of modules to do this. You can define any of the following as requiring a second call:

  • Blocks
  • Views
  • Panels Panes
  • Fields
  • Comments
  • Flags
  • Forms
  • Forums
  • Polls
  • Votes

… and that’s all without writing a single line of custom code! Each one of those elements gets a new “Authcache” setting, where you can define it as needing a second callback, and set the method for the callback as either AJAX or ESI. You can even fall back to another method if the first one fails!

A good example of how this works is the Forms integration. Authcache will modify any and all forms on your site, so that they have an ESI or AJAX placeholder for the form token. This means that the form itself can be stored in your page cache (Varnish, Boost, or whatever), and the form token will be filled in automatically! That’s a phenomenal speed improvement without any configuration beyond enabling the module.

Setting up Authcache is a little complicated, and I’ll cover that in depth in my next post. But once the basic AJAX or ESI support is set up and these modules are enabled, caching authenticated users becomes a question of visiting each unique layout on your site and making a plan for each element that involves user customization. Authcache makes this easy.

Next post: How to configure Authcache on Drupal 7.

Catégories: Elsewhere

larsolesen.dk: Bug triage on Commons

lun, 09/06/2014 - 20:39
Tags: planet drupaldrupal

I will try to help out in the Drupal Commons issue queue for the 7.x-3.x version on Thursday. Come and join me. The main objective of the bug triage is to narrow down the bug count and maybe fix some low-hanging fruit in the issue queue, so it will be easier for the main developers to get stuff done and focus on the most important stuff.

Timeframe

On Thursday from 10.30 CEST til around 14.30 CEST I will be working an online in #drupal-commons.

Want to join?

Everybody can join. We will just meet up in the IRC channel for #drupal-commons. You can join at any time during that period.

There is plenty to do for people at different skill levels.

Sign up for the online event here.

Updates for the efforts

Updates for our efforts will be posted on this page. 

Ressources
Catégories: Elsewhere

LightSky: 5 Must Have Modules for SEO in Drupal

lun, 09/06/2014 - 20:25

I have been doing Drupal development for the last four years. During that time, one concern from potential clients has been that Drupal isn’t SEO friendly. While Drupal may not come ready for SEO out of the box, with a few additional modules and some proper configuration, Drupal can be a successful SEO platform. Below are what I consider must have modules for Drupal SEO.

1. Pathauto
Pathauto works by creating automatic URL aliases based upon tokens that you set in the configuration. By default, Drupal’s URL structure looks similar to “/node/75” where 75 is the node id of the page. With Pathauto, your urls will transform into keyword rich URLS such as “blog/five-must-have-modules-drupal-search-engine-optimization”. Each URL pattern can be configured on a per-content type basis, and you can add alias patterns for your taxonomies as well as your users.

2. Global Redirect
The Global Redirect module works by automatically redirecting visitors from the node/xx URL to the aliased version of the URL. This is important as it prevents duplicate content penalties within Drupal. This module also allows you to add a canonical tag to your pages as well.

3. MetaTag
The Metatag module allows you the option of configuring metatags for your site at both the individual and global level. As of the time of this writing, the Metatag module has support for the following tags:

4. XML SiteMap
The XML SiteMap module create sitemaps that you can use to submit to Google, Bing and Yahoo’s Webmaster tools. You can indicate which content types you’d like to see included and indicate the priority of those content type pages on your site. The benefit of submitting an XML Sitemap is so that the search engines know about all of the pages on your site. Without it, they will only know about the pages found during their normal crawling process which sometimes misses pages.

5. SEO Checklist
The SEO Checklist module doesn’t add any functionality to your site directly, but it does serve as a reminder for SEO related tasks that still need to be completed. It separates items by category and allows you to check off items as they are completed. SEO checklist also saves a timestamp of each completed action so that other site administrators will know when items are completed. This module is updated frequently with the latest SEO techniques and helps ensure that you are maximizing SEO for your site.

 

LightSky recommends Drupal as a solution to many of our clients who want easy to use and maintain websites that are also flexible and secure. One of the great features of Drupal is that it is so easy to customize. Adding the above modules for SEO is an example of how Drupal can easily be adapted for our clients’ needs. What are some of your favorite modules for SEO in Drupal?

Catégories: Elsewhere

EchoDitto Tech Blog: OS X 10.9 Local Development Environment: Apache, PHP, and MySQL with Homebrew

lun, 09/06/2014 - 15:55

code {display:inline;padding:0;margin:0;border:none;} There's nothing quite like setting up everything on your Mac for Drupal (or other PHP) development in a way that things just work and don't need constant fiddling. This guide will walk you through using Homebrew to install Apache, PHP, and MySQL for a "MAMP" development environment. We'll also use DNSMasq and Apache's VirtualDocumentRoot to set up "auto-VirtualHosts," and add a firewall rule to allow the default http port 80 to be used without running Apache as root.

At the conclusion of this guide, you'll be able to create a directory like ~/Sites/project and access it at http://project.dev without editing your /etc/hosts file or editing any Apache configuration. You'll also be able to use xip.io with auto-VirtualHosts for accessing your sites on other devices in your local network.

We also configure PHP and MySQL to allow for enough flexibility for complex operations generally only reserved for development and not production.

The OS X operating system comes with Apache and PHP pre-installed, and I've previously recommended utilizing them to some degree for getting a local PHP development environment on your Mac. Since then, the community around Homebrew has improved dramatically and I now recommend that our developers at EchoDitto use Homebrew exclusively for all components.

Homebrew Setup

If you've not already install Homebrew, you can follow the instructions at brew.sh, or simply run the following command:

ruby -e "$(curl -fsSL https://raw.github.com/Homebrew/homebrew/go/install)" brew doctor brew update PATH Variable

Since OS X already comes with PHP and Apache, we'll want to make sure that our brew-installed versions appear in the shell path before the built-in ones. The following command adds logic to your ~/.bash_profile to ensure the Homebrew directory is in the beginning of $PATH.

echo "export PATH=\$(echo \$PATH | sed 's|/usr/local/bin||; s|/usr/local/sbin||; s|::|:|; s|^:||; s|\(.*\)|/usr/local/bin:/usr/local/sbin:\1|')" >> ~/.bash_profile && source ~/.bash_profile MySQL

The following commands will download and install the latest version of MySQL and do some basic configuration to allow for large imports and a couple other miscellaneous configuration changes.

brew install -v mysql   cp -v $(brew --prefix mysql)/support-files/my-default.cnf $(brew --prefix mysql)/my.cnf   cat >> $(brew --prefix mysql)/my.cnf <<'EOF' # EchoDitto changes max_allowed_packet = 2G innodb_file_per_table = 1 EOF   sed -i '' 's/^# \(innodb_buffer_pool_size\)/\1/' $(brew --prefix mysql)/my.cnf

Now we need to start MySQL using OS X's launchd, and we'll set it to start when you login.

[ ! -d ~/Library/LaunchAgents ] && mkdir -v ~/Library/LaunchAgents   [ -f $(brew --prefix mysql)/homebrew.mxcl.mysql.plist ] && ln -sfv $(brew --prefix mysql)/homebrew.mxcl.mysql.plist ~/Library/LaunchAgents/   [ -e ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist ] && launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.mysql.plist

By default, MySQL's root user has an empty password from any connection. You are advised to run mysql_secure_installation and at least set a password for the root user.

$(brew --prefix mysql)/bin/mysql_secure_installation Apache

Start by stopping the built-in Apache, if it's running, and prevent it from starting on boot. This is one of very few times you'll need to use sudo.

sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null

Apache is not in the default repository of Homebrew formulas, nor are some dependencies, so we use the brew tap command to add other formula repositories.

brew tap homebrew/dupes brew tap homebrew/apache

We'll install Apache 2.2 with Apr and OpenSSL from Homebrew as well instead of utilizing the built-in versions of those tools.

brew install -v httpd22 --with-brewed-apr --with-brewed-openssl

We'll be using the file ~/Sites/httpd-vhosts.conf to configure our VirtualHosts, so we create necessary directories and then include the file in httpd.conf.

[ ! -d ~/Sites ] && mkdir -pv ~/Sites   touch ~/Sites/httpd-vhosts.conf   USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat >> $(brew --prefix)/etc/apache2/2.2/httpd.conf <<EOF # Include our VirtualHosts Include ${USERHOME}/Sites/httpd-vhosts.conf EOF

We'll create a folder for our logs in ~/Sites as well.

[ ! -d ~/Sites/logs ] && mkdir -pv ~/Sites/logs

Now to fill in the contents of ~/Sites/httpd-vhosts.conf that we included in httpd.conf earlier. Note that this is one command to copy and paste! Start with USERHOME through the second EOF has a single copy and paste block for the terminal.

USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat > ~/Sites/httpd-vhosts.conf <<EOF # # Use name-based virtual hosting. # NameVirtualHost *:80   # # Set up permissions for VirtualHosts in ~/Sites # <Directory "${USERHOME}/Sites"> Options Indexes FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all </Directory>   # For http://localhost in the users' Sites folder <VirtualHost _default_:80> ServerName localhost DocumentRoot "${USERHOME}/Sites" </VirtualHost>   # # VirtualHosts #   ## Manual VirtualHost template #<VirtualHost *:80> # ServerName project.dev # CustomLog "${USERHOME}/Sites/logs/project.dev-access_log" combined # ErrorLog "${USERHOME}/Sites/logs/project.dev-error_log" # DocumentRoot "${USERHOME}/Sites/project.dev" #</VirtualHost>   # # Automatic VirtualHosts # A directory at ${USERHOME}/Sites/webroot can be accessed at http://webroot.dev # In Drupal, uncomment the line with: RewriteBase /   # This log format will display the per-virtual-host as the first field followed by a typical log line LogFormat "%V %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedmassvhost   # Auto-VirtualHosts with .dev <VirtualHost *:80> ServerName dev ServerAlias *.dev   CustomLog "${USERHOME}/Sites/logs/dev-access_log" combinedmassvhost ErrorLog "${USERHOME}/Sites/logs/dev-error_log"   VirtualDocumentRoot ${USERHOME}/Sites/%-2+ </VirtualHost>   # Auto-VirtualHosts with xip.io <VirtualHost *:80> ServerName xip ServerAlias *.xip.io   CustomLog "${USERHOME}/Sites/logs/dev-access_log" combinedmassvhost ErrorLog "${USERHOME}/Sites/logs/dev-error_log"   VirtualDocumentRoot ${USERHOME}/Sites/%-7+ </VirtualHost> EOF Run with port 80

You may notice that httpd.conf is running Apache on port 8080, but the above are using port 80. The next two commands will create and load a firewall rule to forward 8080 requests to 80. The end result is that we can use port 80 in VirtualHosts without needing to run Apache as root.

The following single command will create the file /Library/LaunchAgents/com.echoditto.httpdfwd.plist as root, and owned by root, since it needs elevated privileges.

sudo bash -c 'export TAB=$'"'"'\t'"'"' cat > /Library/LaunchAgents/com.echoditto.httpdfwd.plist <<EOF <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> ${TAB}<key>Label</key> ${TAB}<string>com.echoditto.httpdfwd</string> ${TAB}<key>ProgramArguments</key> ${TAB}<array> ${TAB}${TAB}<string>sh</string> ${TAB}${TAB}<string>-c</string> ${TAB}${TAB}<string>ipfw add fwd 127.0.0.1,8080 tcp from any to me dst-port 80 in &amp;&amp; sysctl -w net.inet.ip.forwarding=1</string> ${TAB}</array> ${TAB}<key>RunAtLoad</key> ${TAB}<true/> ${TAB}<key>UserName</key> ${TAB}<string>root</string> </dict> </plist> EOF'

This file will be loaded on login and set up the 80->8080 port forward, but we can load it manually now so we don't need to log out and back in.

sudo launchctl load -w /Library/LaunchAgents/com.echoditto.httpdfwd.plist PHP

The following is for the latest release of PHP, version 5.5. If you'd like to use 5.3, 5.4 or 5.6, simply change the "5.5" and "php55" values below appropriately. (Note: if you use 5.3, the OpCache extension instructions are different. They will be posted below after the instructions for newer versions.)

Start by adding the PHP tap for Homebrew. PHP 5.3 needs an additional tap, so skip the second command if you are using 5.4 or higher.

brew tap homebrew/php   # Skip this if using PHP 5.4 or higher brew tap homebrew/versions

Install PHP and mod_php. This command will also load the PHP module in the httpd.conf file for you.

brew install -v php55 --homebrew-apxs --with-apache

Add PHP configuration to Apache's httpd.conf file.

cat >> $(brew --prefix)/etc/apache2/2.2/httpd.conf <<EOF # Send PHP extensions to mod_php AddHandler php5-script .php AddType text/html .php DirectoryIndex index.php index.html EOF

Set timezone and change other PHP settings (this is a single command). sudo is needed here to get the current timezone on OS X (in previous versions of OS X it wasn't needed, I'm not sure why it is now).

sed -i '-default' "s|^;\(date\.timezone[[:space:]]*=\).*|\1 \"$(sudo systemsetup -gettimezone|awk -F"\: " '{print $2}')\"|; s|^\(memory_limit[[:space:]]*=\).*|\1 256M|; s|^\(post_max_size[[:space:]]*=\).*|\1 200M|; s|^\(upload_max_filesize[[:space:]]*=\).*|\1 100M|; s|^\(default_socket_timeout[[:space:]]*=\).*|\1 600|; s|^\(max_execution_time[[:space:]]*=\).*|\1 300|; s|^\(max_input_time[[:space:]]*=\).*|\1 600|;" $(brew --prefix)/etc/php/5.5/php.ini

Add a PHP error log; without this, you may get Internal Server Errors if PHP has errors to write and no logs to write to (this is a single command; be sure to copy and paste the lines containing USERHOME through the last EOF as a single command).

USERHOME=$(dscl . -read /Users/`whoami` NFSHomeDirectory | awk -F"\: " '{print $2}') cat >> $(brew --prefix)/etc/php/5.5/php.ini <<EOF ; PHP Error log error_log = ${USERHOME}/Sites/logs/php-error_log EOF

This weird little "hack" is needed to fix a permissions problem with using pear or pecl.

touch $(brew --prefix php55)/lib/php/.lock && chmod 0644 $(brew --prefix php55)/lib/php/.lock

The OpCache extension will speed up your PHP environment dramatically, and it's easy to install for 5.4 and higher. If you are looking to install PHP 5.3, skip this block.

brew install -v php55-opcache

Skip this block unless you are using PHP 5.3. Because there is no php53-opcache Homebrew formula, we can install it with pecl and replicate the same configuration file.

pecl install zendopcache-beta   sed -i '' "s|^\(zend_extension=\"\)\(opcache\.so\"\)|\1$(php -r 'print(ini_get("extension_dir")."/");')\2|" $(brew --prefix)/etc/php/5.3/php.ini   echo "[opcache]" > $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini   grep -E '^zend_extension.*opcache\.so' $(brew --prefix)/etc/php/5.3/php.ini >> $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini   sed -i '' '/^zend_extension.*opcache\.so/d' $(brew --prefix)/etc/php/5.3/php.ini   # "php54" is not a typo here- I'm using a sample config file from # another recipe for my config file in php53 grep -E '^[[:space:]]*opcache\.' \ $(brew --prefix)/Library/Taps/homebrew/homebrew-php/Formula/php54-opcache.rb \ | sed 's/^[[:space:]]*//g' >> $(brew --prefix)/etc/php/5.3/conf.d/ext-opcache.ini

And continue with steps for all PHP versions: give OpCache some more memory to keep more opcode caches.

sed -i '' "s|^\(opcache\.memory_consumption=\)[0-9]*|\1256|;" $(brew --prefix)/etc/php/5.5/conf.d/ext-opcache.ini Start Apache

Start Homebrew's Apache and set to start on boot.

ln -sfv $(brew --prefix httpd22)/homebrew.mxcl.httpd22.plist ~/Library/LaunchAgents   launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.httpd22.plist DNSMasq

I've covered this before, but we'll list the commands here again for completeness. This example will have any DNS request ending in .dev reply with the IP address 127.0.0.1.

brew install -v dnsmasq   echo 'address=/.dev/127.0.0.1' > $(brew --prefix)/etc/dnsmasq.conf   echo 'listen-address=127.0.0.1' >> $(brew --prefix)/etc/dnsmasq.conf

Because DNS services run on a lower port, we need to have this run out of /Library/LaunchAgents, so we do need to use sudo for the initial setup.

sudo cp -v $(brew --prefix dnsmasq)/homebrew.mxcl.dnsmasq.plist /Library/LaunchAgents   sudo launchctl load -w /Library/LaunchAgents/homebrew.mxcl.dnsmasq.plist

With DNSMasq running, configure OS X to use your local host for DNS queries ending in .dev

sudo mkdir -v /etc/resolver   sudo bash -c 'echo "nameserver 127.0.0.1" > /etc/resolver/dev' Great! So, what did I do?

We set up Apache to run on boot on port 8080 with mod_php with auto-VirtualHosts for directories in the ~/Sites folder. The OS X firewall will forward all port 80 traffic to port 8080, so we don't have specify the port number when visiting web pages in web browsers. MySQL is installed and set to run on boot as well. DNSMasq and some OS X configuration is used to direct any hostname ending in .dev to the local system to work in conjunction with Apache's auto-VirtualHosts.

What do I do now?

You shouldn't need to edit the Apache configuration or edit /etc/hosts for new local development sites. Simply create a directory in ~/Sites and then reference that foldername + .dev in your browser to access it.

For example, use drush to download Drupal 7 to the directory ~/Sites/firstproject, and it can then be accessed at http://firstproject.dev/ without any additional configuration. A caveat - you will need to uncomment the line in Drupal's .htaccess for RewriteBase / to work with the auto-VirtualHosts configuration.

What about this xip.io thing?

If your Mac's LAN IP address is 192.168.0.10, you can access sites from any other device on your local network using http://firstproject.192.168.0.10.xip.io/. You can test a websites on your Mac with your phone/tablet/etc. Pretty great, right?

What if this "auto-VirtualHost" doesn't work for me?

If you need to create a manual VirtualHost in Apache because the auto-VirtualHost does not work for your configuration, you may need to declare it before the auto-VirtualHosts if you're also going to use .dev as the TLD. Otherwise the auto-VirtualHost block will be accessed first.

Photo by Florian Klien

Catégories: Elsewhere

Drupal Watchdog: Get Started Fast with Online Drupal Platforms

lun, 09/06/2014 - 15:11
Article

Create a database ... copy files onto a web server ... set file permissions....

If you’re new to website development, the standard instructions for installing Drupal are likely to be a bit daunting. Even if you’re a seasoned pro, setting up a well-designed development environment — then tweaking it for optimal Drupal hosting — takes time and effort that you might prefer to spend on building sites.

Luckily, there’s a growing set of online platforms that take the muss and fuss out of Drupal site building. As well as easing development, online Drupal platforms offer a range of server-side optimizations for fast and secure site hosting. Here’s a quick rundown of some of the options, with both features and limitations of each.

Drupal Gardens

Want to spin up a quick Drupal 7 site? Drupal Gardens is your easiest option. Think of it as the Drupal equivalent of wordpress.com.

Nedjo Rogers

Nedjo Rogers has been an active Drupal contributor since posting his first module, in 2003. He is the technical lead of the Open Outreach Drupal distribution for nonprofit organizations, and a partner at Chocolate Lily Web Projects.

Catégories: Elsewhere

Alexander Mikhailian: An incomplete inventory of ways to share code among Drupal initegrators

lun, 09/06/2014 - 14:40

Whenever a team starts working on a new Drupal-based website, there's an inevitable discussion on how to organize collaboration. Three questions come up regularly:

  1. How and when to use Features, Features Extra and Features Override modules
  2. How to organize production, testing and development environments and where to develop — on a shared server or locally
  3. How to share source code.

Out of the three, the question of the source code is the most contentious. One reason is that while everyone and their friend are already on git, most of the teams that implement Drupal websites do not really need a version control system where developers can cherry-pick and merge changes or analyze bugs by navigating commit histories. Instead, teams are usually interested in incremental backup systems where each team member can be sure that he can roll back his own and other people's changes until everything works again.

Below is the inventory of way to share source code in Drupal projects.

Incremental backup Incremental backup with drush

One way of ensuring incremental backups without the overhead of git or other version control system is to use drush. Drush keeps a backup of previous module versions in ~/drush-backups — there is enough info to revert manually to the previously known good state. This setup is ideal for small projects with a handful of custom modules that can be kept in their own git repositories.

When in doubt, don't put your Drupal project in git. Use drush and its build-in backup mechanism.

Catégories: Elsewhere

Stanford Web Services Blog: pushd, dirs, and popd

lun, 09/06/2014 - 13:49

If you spend a lot of your day at the command line (as I do), you're constantly on the lookout for new tools and tricks to increase your productivity and efficiency. Today we're going to take a look at the pushd suite of commands that exist in most shells (e.g., bash, tcsh and so forth).

Catégories: Elsewhere

Alexander Mikhailian: An Ansible playbook for a smallish and very simple Drupal cluster

lun, 09/06/2014 - 02:04

The cluster runs on apt-based systems. It is designed for high-availability: failure of one server is not critical. However, there is no automatic failover configuration. Instead, manual recovery is possible within minutes.

  • Load balancers run varnish. Its configuration file takse into account the context_breakpoint cookie that's used to implement responsive delivery. The same server also has memcached.
  • Application servers run nginx and a recent php5-fpm through unix sockets. There's also drush. The filesystem is shared through glusterfs.
  • MariaDb is configured in master-slave mode on database servers. They also run Apache Solr.

All servers set up exim to work as smarthost, sending mails through gmail. In practice, gmail limits outgoing emails to a few thousands per day, so it is better to replace it by a dedicated solution such as Mailchimp. There's also newrelic for server monitoring on all servers.

The playbook assumes that all servers have public IPs on eth0 and sit in the private network on eth1.

For the rest, check the code in github.

Catégories: Elsewhere

Drupal 8 and iOS: POST, PATCH and DELETE request with Drupal 8 REST services

dim, 08/06/2014 - 06:04
POST, PATCH and DELETE request with Drupal 8 REST services

 

Drupal 8 will have REST support out of the box. But at the time of this writing examples for how to use this REST end points are not much available. In this blog I want to show you how we can create, delete and update a node with REST services with Drupal 8.

 

First of all we have to enable REST services and related HAL , SERIALIZATION, HTTP Basic Authentication modules. I would also like to recommend you to use REST UI contributed module to configure REST services.

 

 

 

Now you have to enable REST services for particular entity type like a node, user etc. you can do it by two way:

 

  1. You may use REST UI to do that from configuration menu and Web services section.
  2. You may directly manipulate  rest.settings.yml file.

 

With any of above mentioned way you enable POST, PATCH and DELETE method for certain entity type and also enable ‘basic_auth’ as authentication type.

 

Now give enough permission to administrator so that he can POST, PATCH and DELETE an entity with REST services.

 

You may use REST Client or Postman - REST client or DHC to test you web services.

Now let’s try to POST a node with REST services.

 

 

 

As shown in the image on your site /entity/node ( as at the time of this writing Drupal 8  is still on alpha release so this path may change in stable release)  is  REST endpoint to POST a node. Pass credential details with Authorization header. Set Content-Type to be application/hal+json.

In body part you have to specify value for all mandatory fields for entity type. You have to specify “type” of node with “_links” in JSON body. This “type” will be /rest/type/node/{bundle name}  or in case of user entity type it will be /rest/type/user/user. A successful POST will result in 201 http status code.

 

Now lets try to update a node with PATCH request.

 

 

As you can see in the image URL for node it self works as PATCH end point other headers and body section will be same as POST request. If PATCH request done successfully you will get 204 http status code.

 

At last let’s see how to DELETE a node.

 

Deleting a node is simple. Set request type to DELETE and pass credential information with Authorization header. A successful deletion will result in 204 http status code.

 

By similar way you can manipulate user entity type.

 

You can find more about what other details we can specify in JSON body for POST and PATCH request by GET a node with JSON as Accept type.

 

I am open to discuss this topic. You can mail me at vivekvpandya@gmail.com.

 

 

 

Tags:
Catégories: Elsewhere

Drupal Watchdog: Drupal in Context

dim, 08/06/2014 - 00:44
Column The Way to Drupal Answers Isn't Always Clear; Here's How to Find It

They say “everyone starts as a beginner,” but that’s not quite true. Pianists easily apply their training to transition into conducting or composing; carpenters and stonemasons become sculptors. Likewise, former programmers intuit Drupal's inner workings on sight. Some beginners simply start out “more equal than others” — leaving the rest of us scrambling to catch up.

Commercial software incorporates the cost of training, documentation, and support into the product’s price: Without an easy “on-ramp,” the product will fail to gain new adherents and, eventually, fade away. Core Drupal, as a free, open source product, lacks this support-system advantage, so help must come either from volunteers or from the third-party market. Alas, volunteers are sometimes unreliable — or unavailable when needed — and the third-party market requires money. And so a “knowledge gap” has developed between those who hold information and those who need it.

But it's not hopeless, because the Drupal ecosystem has grown and diversified so much that those two sources of help can now serve just about everyone, including you — if you know where to look.

Getting Answers Fast

When problems grind your project to a halt, speed is of the essence. Your best bet for free, emergency support is the #drupal-support channel of Internet Relay Chat (IRC), staffed by helpful volunteers. Sadly, the demand for help there far outstrips the supply, so many questions go unanswered.

More reliable are the commercial offerings. These are sometimes provided as part of a subscription program, the best-known of which is the Acquia Network, where direct, ticket-based support starts at $2,500 per year. (Forum-based support is available as part of cheaper packages.) But Acquia is far from the only player, and http://drupal.org/drupal-services lists over 100 companies that offer some form of support.

Tom Geller

Tom Geller has been online for twenty-five years and building Web sites for fifteen. He switched to Drupal in 2007 and has since created eight video courses for lynda.com, written the book "Drupal 7: Visual QuickStart Guide", and consulted on communications for Drupal companies. His home is in Oberlin, Ohio; he's online at tomgeller.com.

Catégories: Elsewhere

Gizra.com: Introducing Emmet!

sam, 07/06/2014 - 23:00
Instant html and css

Emmet is a great tool that can enhance your productivity and save you a lot of time when coding or prototyping.
Some of you may know it as "Zen coding" and for quite some time (Since 2012) it’s known as Emmet.

Emmet is a plugin for a text editor which greatly improves html and css workflow.
The idea behind it is to instantly expand a simple abbreviation (shortened form of a word or phrase) into complex code snippet.
Emmet uses these abbreviations to parse them in runtime and transform them into structured code block: HTML, CSS, XML or any other structured markup.

Continue reading…

Catégories: Elsewhere

Drupal 8 and iOS: POST, PATCH and DELETE request with Drupal 8 REST services

sam, 07/06/2014 - 19:07
POST, PATCH and DELETE request with Drupal 8 REST services

Drupal 8 will have REST support out of the box. But at the time of this writing examples for how to use this REST end points are not much available. In this blog I want to show you how we can create, delete and update a node with REST services with Drupal 8.

First of all we have to enable REST services and related HAL , SERIALIZATION, HTTP Basic Authentication modules. I would also like to recommend you to use REST UI contributed module to configure REST services.

 

 

Now you have to enable REST services for particular entity type like a node, user etc. you can do it by two way:

You may use REST UI to do that from configuration menu and Web services section. You may directly manipulate  rest.settings.yml file.

With any of above mentioned way you enable POST, PATCH and DELETE method for certain entity type and also enable ‘basic_auth’ as authentication type.

Now give enough permission to administrator so that he can POST, PATCH and DELETE an entity with REST services.

 

 

You may use REST Client or Postman - REST client or DHC to test you web services. Now let’s try to POST a node with REST services.

 

 

As shown in the image on your site /entity/node ( as at the time of this writing Drupal 8  is still on alpha release so this path may change in stable release)  is  REST endpoint to POST a node. Pass credential details with Authorization header. Set Content-Type to be application/hal+json. In body part you have to specify value for all mandatory fields for entity type. You have to specify “type” of node with “_links” in JSON body. This “type” will be /rest/type/node/{bundle name}  or in case of user entity type it will be /rest/type/user/user. A successful POST will result in 201 http status code.

Now lets try to update a node with PATCH request.

 

 

As you can see in the image URL for node it self works as PATCH end point other headers and body section will be same as POST request. If PATCH request done successfully you will get 204 http status code.

At last let’s see how to DELETE a node.

 

 

Deleting a node is simple. Set request type to DELETE and pass credential information with Authorization header. A successful deletion will result in 204 http status code.

By similar way you can manipulate user entity type.

You can find more about what other details we can specify in JSON body for POST and PATCH request by GET a node with JSON as Accept type.

I am open to discuss this topic. You can mail me at vivekvpandya@gmail.com.  

Tags:
Catégories: Elsewhere

Midwestern Mac, LLC: DevOps for Humans - Ansible presentation at DrupalCon Austin

sam, 07/06/2014 - 03:17

I'm still recovering from an intense week of Drupal here in Austin, TX. I kicked things off by walking around the downtown area, then taking the intensive Acquia Drupal Developer Certification exam. Once the conference started, I attended a few sessions, met a few awesome Drupalists, and learned a lot. On the last day of the 'Con (the last session, in fact), I presented DevOps for Humans: Ansible for Drupal Deployment Victory!.

I think the presentation went well, and I heard some great questions at the end which really contributed to the discussion of Ansible and Drupal deployments in general. It was a great way to finish up the official DrupalCon sessions, though it meant I was revising slides for the hundredth time during the rest of the week, instead of relaxing and enjoying DrupalCon!

Before I post a video and slides from the session, I wanted to highlight some resources for anyone who attended (or didn't attend) DrupalCon Austin:

Below is the video and slides from the DevOps for Humans presentation. Please let me know what you think!

Catégories: Elsewhere

ShooFlyDesign: Revealed: DrupalCon 2015 in Los Angeles

sam, 07/06/2014 - 01:09

Every year there are two huge Drupal conferences: one in North America, the other somewhere else in the world. North America's was in Austin this year, and just wrapped up. The next one will be in Amsterdam at the end of September. It's a tradition at each con to announce the location of the next one, and next year's will be here in Los Angeles. Yay! I've been to many camps, but never to a con, so this gives me absolutely no way out of finally going. I'm definitely looking forward to this.

I found out about this very shortly before Austin, and helped some of the fine folks in LA's Drupal community put together a video that played during the closing session in Austin, revealing our fair city as the next location. I worked on the music for it, sourcing some material and playing a little bit of ukulele. Check it out!

Read more
Catégories: Elsewhere

LightSky: The State of Drupal: Our Take

sam, 07/06/2014 - 00:54
Download

Our take on Drupal creator Dries Buytaert's State of Drupal Keynote from DrupalCon Austin 2014.  We look a little deeper at what Dries had to say, and provide a little insight into what role this plays in Drupal.

Participants

Michael Hodge Jr - President/Owner at LightSky - @m_hodge

Bruce Clingan - Director of Business Development at LightSky - @astrocling

Comments/Questions

We are doing this podcast for our visitors. If you have any ideas for how we can improve our podcasts, or ideas for future topics please let us know. You can either reach us via email, twitter or in the comments below.

Catégories: Elsewhere

Nuvole: Configuration Management: Drupal 7 to Drupal 8

ven, 06/06/2014 - 22:23
Features done right? Features done wrong? What changed, what improved, what's still missing.

Nuvole gave two talks about the current status of Configuration Management in Drupal 8 at European Drupal events in the last few weeks: Drupal Days Milan 2014 and Drupal Camp Alpe Adria 2014.

Developers attending the events were mostly interested in how the future Drupal 8 Configuration Management capabilities will compare to Drupal 7, with and without the Features module (or, in general, with and without what we call the code-driven workflow).

Here is a comparison based on the current status of Drupal 8. Please note that CMI, the Configuration Management Initiative, is still under active development, and for example a couple issues mentioned in the slides have already been resolved, shortly after we gave our presentations. The very basic concepts, though, remain unchanged from our September 2013 post, so you might want to review that one if you have never heard about CMI before.

Configuration Management: Key differences between Drupal 7 and Drupal 8 Configuration is well-defined

In Drupal 7 it isn't always clear-cut whether something belongs in the "configuration" or "content" realm. Are vocabularies configuration? Are taxonomy terms configuration? And what about a taxonomy term whose ID is used as a contextual filter in a View? Several approaches to this are possible, like soft configuration.

In Drupal 8, configuration will be less subjective: Drupal has an "Export Configuration" function that exports all the site configuration; if something is not there, it is not considered to be configuration. Concepts like soft configuration still apply, but at least it's clear what is configuration and is not.

Configuration is stored in files

Drupal 7, generally, stores configuration in the database, together with content. Only a little subset of configuration is read from PHP files. In Drupal 8 configuration will live in text files. Then, for several reasons (performance, safety, security), those files will actually be stored in the database by default (one of the most visible recent changes), but will still be accessed and managed as files.

Unified format and approach to configuration

A particularly annoying issue with Drupal 7 is that modules are free to set their own standards for storing configuration, so it is common to find sites where configuration is scattered among variables, database tables, objects exported via CTools, Features, and other places. Modules like Features at times need some "black magic" to guess where and how relevant configuration is stored.

The unified approach in Drupal 8, where all configuration is in the form of text files in the YAML format, is a great step forward. It removes the guesswork needed by Features in Drupal 7 to understand how to find and export components.

Staging configuration

In Drupal 7 you can have "staged configuration" through Features and the Features revert operation. Drupal 8 will introduce, out of the box, an "Import Configuration" facility that you can use to import either the whole site configuration or a single configuration file. The approaches are mostly equivalent, but on one side Drupal 7 + Features offers better packaging functionality, on the other side Drupal 8 will allow to import a complete site configuration (all variables, permissions...), something that is highly unpractical to do with Drupal 7 and Features.

Interface to developers

From a developer's point of view, writing PHP code to access and/or set a component's configuration in Drupal 7 is tricky, since you don't have a global interface, let alone an "entry point" that allows you to explore all the site configuration: you are forced to use a mixed bag of tricks ranging from variable_get() and variable_set() to database queries, to Ctools hooks for making configuration exportable and so on.

Drupal 8 will bring a very welcome improvement by providing a dedicated type for configuration entities and the unified interface Drupal::config($name) for getting and setting all configuration values: as a typical example Drupal::config('system.site')->get('name') will return the site name, and the same pattern can be used for everything.

The shootout: Drupal 7 vs Drupal 7 + Features vs Drupal 8

A quick feature comparison table between Drupal 7 core, Drupal 7 + Features and the current state of Drupal 8. As you see, a developer that is now using Drupal 7 without features will see spectacular advantages in Drupal 8, while experienced users of Drupal 7 and Features will still miss something.

Functionality D7 Core D7 Core + Features D8 Core (current) Export full site config (no content) NO NO YES Export selected config items NO YES YES Track config changes (full site) NO NO YES Track config changes (selected items) NO YES YES Stage configuration NO YES YES Package configuration NO YES NO Reuse configuration in other projects NO YES NO Collaborate on the same project NO YES NO What is still missing?

It's important to understand the use case for CMI. The stated aim for CMI is not to replace Features. CMI aims at making it much simpler to transport configuration changes from development to production, and this aim was reached.

All other benefits of Features are out of scope for CMI. These include: packaging configuration, reusing configuration in other projects (and not simply moving it between the development and production version of the same site) and enabling real-time team collaboration (developer A and developer B build two separate features for the same site, like the News and Blog sections, simultaneously). So there is definitely room for a Drupal 8 version of Features.

Is CMI “Features Done Right”?

No. It is a nice way to replace and improve one use case for Features: making configuration exportable into text files.

Is CMI “Features Done Wrong”?

No. It is a huge step forward to developers and it paves the way for additional modules that could offer the same functionality of Drupal 7 + Features in a much cleaner and more reliable way.

See full versions of our Milan and Alpe Adria presentations as a Slideshare embeds or PDF files, below.

Configuration Management in Drupal 8: A preview (DrupalDays Milano 2014)
from Nuvole Configuration Management in Drupal 8: A preview (DrupalCamp Alpe Adria 2014)
from Nuvole Tags: Drupal Planet, Code Driven Development, Drupal 8Attachments:  Milano-2014-drupal-8-cmi-preview-en.pdf AlpeAdria-2014-cmi-d7-to-d8--dcaa-140517.pdfImage: 
Catégories: Elsewhere

Cafuego: DrupalCon Austin - Drupal Trivia Scores

ven, 06/06/2014 - 20:02
Many of the DrupalCon Trivia teams appear to have had rivalries (or actual feuds) with teams on tables nearby, as I've had a lot of people ask where they finished in relation to another team.

To help you to find out where your team finished, here is the final score table.

*/

RankTeam NameBonusONETWOTHREEFOURFIVESIXTIEBREAKSCORE1data-steak='cactus'589907382The Drop Bears24666462363We Hack Core33573581354We are not cheaters1665637345Development Steed577519346Drupal 6LTS478617337Cachfralca 801477446338Wonderwomen1477617339The Bats35663273210Foo Beer6576173211F*ck the bats15675263212The Meat Sweats14664373113Point Blood42465463114More Wine, Here!42765343115The Man32753373016The Local Branches34575153017\_("/)_/2867163018[marksonnabaum:sorrybeard]4765342919The Blinking Marquees25752172920Finns and friends13575172921Dependency Ejection4663372922We Know Drama4754182923check_plain(<script>ALERT("XSS");</script>);3575262824The Spanish Exposition33664062825Dries' Git Skillz4373382826Chang3555282827Bachm's Razer13756052728sudo rm -rf l14463272729Top of the bell curve12565262730Cache Killaz4564442731WWSD235531827324243463162733Zaphod32754322634Anonymous User13463362635Friends of Eithkhan32743342636Inmigration Reform33543262637Newbies52650352638Tuareg0.534641725.539Gobmint11465262540Something(dot)Ninjas23464152541Late Comers3564162542Jim,Jimmery22544252443MAMBO3564062444Heinz 57!?!11663432445Just put it down12363362446D.A. Barracus14362252347The Global Variables24471232348Team WordPress12852142349Lee Walker's Assless Chaps4445052250Lost Cause24561132251Victory Dirtwolves12354162252The Vikings22554222253The Amazing Stroopwafels3532272254DrupalChronic3464232255Batnado3343352156Flying Danes2364114215760345632158The DruPaul Show436421959Name that module255251960Austin Weirdos33233311861NXNW+1113631462Los Capos11631163Team Wordpress2002001564What the Fox Says101011465Miro00000101Tags: drupaldrupalcon
Catégories: Elsewhere

Kerasai.com: Features Builder: Sensible Configuration Management for D7 with Features

ven, 06/06/2014 - 19:40

Using Features to manage configuration for a Drupal project is a bit of an undertaking. Features was initially intended to make portable units of functionality to share between sites, but many folks out there are using it to manage configuration and deployments. This works, but is a bit of a burden to to manage and takes a bit of expertise to execute in the wild.

Catégories: Elsewhere

Paul Rowell: Content editors, the forgotten Drupal users pt.2

ven, 06/06/2014 - 19:05

A while ago I wrote a post on Content Editors being the forgotten Drupal user, and how we could improve their experience. Well it's been over a year now and, as with anything online, things have changed and new stuff has appeared or been found. So here's a few extra modules that I think can improve the CMS users experience of Drupal.

Catégories: Elsewhere

Pages