Nu ook in het Nederlands.
 

Feed aggregator

ComputerMinds.co.uk: Language lessons: Default language

Planet Drupal - Tue, 2014/06/10 - 2:00pm

When you are going to have multiple language set up on your Drupal site, it's important to set the default language appropriately before creating content. Once that is set, content will normally be set to be in that language, and any translations made on the site will be assumed to be from the default language as the source. So changing it is not a good idea, as there's no way to differentiate between translations made before and after the switch in Drupal 6 or 7! (This has been resolved in Drupal 8.)

So, once you've thought first about what is necessary for your multilingual site, the next step is to pick the right default language, ideally before setting up anything else, as everything is 'in' a language in some way. It's usually an obvious choice, but did you know that the Drupal software itself and associated modules (i.e. the codebase, referred to as the 'interface') is all written in U.S. English (as per the coding standards)?

Categories:

clemens-tolboom commented on pull request symfony/symfony-docs#3917

On github - Tue, 2014/06/10 - 1:49pm
June 10, 2014 clemens-tolboom commented on pull request symfony/symfony-docs#3917

I disagree with When we do that, we no longer need any of this. as it explains how the proces works thus learning something new. /me developer

Blair Wadman: Revert and update a Drupal feature module

Planet Drupal - Tue, 2014/06/10 - 11:59am

This is the third and final part of the series on Features. In the first part, we looked at how to create a feature module. In the second part, we looked at how to add a new component to a feature and recreate it. In this part, we are going to walk through how you can change a component that is already in a feature and then either update or revert the feature.

Tags: FeaturesDrupal Site buildingPlanet Drupal
Categories:

clemens-tolboom pushed to master at clemens-tolboom/symfony-docs

On github - Tue, 2014/06/10 - 10:04am
June 10, 2014 clemens-tolboom pushed to master at clemens-tolboom/symfony-docs

clemens-tolboom commented on pull request symfony/symfony-docs#3910

On github - Tue, 2014/06/10 - 10:03am
June 10, 2014 clemens-tolboom commented on pull request symfony/symfony-docs#3910

I should have said I merged master and did a forced push to my PR ... it this still workable or should I create a new PR ?

Web Omelette: 4 tools you should definitely use for Drupal development

Planet Drupal - Tue, 2014/06/10 - 9:05am

Developing Drupal sites can be quite a challenge and adventure. And this comes from those who call themselves Drupal developers. Men and women of PHP who work with other frameworks and applications most likely find it even more cumbersome to understand. However, Drupal is fostered by a big community of enthusiastic people who love it, myself included. But in all honesty, the more you work with it, the more you develop this love/hate relationship with all the quirks of Drupal development.

But one thing is certain, and this is applicable to other areas of web development as well: the tools you use for the job can make a big difference in the experience you have. And Drupal makes no exception. I mean, remember when we were writing PHP in Notepad and that one missing semicolon added 2 hours of debugging that day?

In this article I would like to share with you 4 tools that I use for Drupal development. I heavily rely on them to minimise frustration, increase productivity and lower development time. And I can guarantee you that if you are serious about Drupal development and you are not using them, you are missing out. But if you are, kudos, do share some of your experiences that further demonstrate their power.

So here we are, I guess in order of complexity, the 4 tools in my belt when I run vagrant up to spin up a project on my local environment. I will say a few words about each, but I can't go into all of their features. That's for you to explore after I give you a taste of what they can offer.

Devel and Search Krumo modules

Devel is the most used Drupal development module built for aiding with debugging code, generating content and all sorts of other dev tasks. Search Krumo is yet another cool module that plugs into it in order to give us a hand with navigating through huge array structures. And if you know Drupal 7, it is all about big arrays.

These modules are probably the first solution for debugging variables in Drupal. Using Devel's dsm(), dpm(), and krumo() functions in your code you can print out arrays, objects and whatever you need for a great overview of what you have in scope at that moment of execution. And they are not the only ones...

Another great use for the Devel module is content generation. It has a series of submodules that can generate nodes, taxonomy terms, users and more. Sometimes you need 500 nodes on the site to test something out. Additionally, you can use it to execute PHP code in the Drupal environment, switch between users on the site and other awesome functionality. So it's a must have on any Drupal development environment.

Drush

Drush is an awesome command line tool for Drupal that speeds up many tasks. Some people call it the swiss army knife of Drupal and you can't really argue the opposite.

Drush allows you to perform a host of Drupal tasks from the command line. You can download and enable/disable/uninstall/update modules or Drupal core and all sorts of other helpful jobs. This great list of core commands can give you an overview of what you can do with Drush. And if you are looking for some help with setting Drush up on your server, you can read this article I wrote on the subject.

Another great thing about Drush is that aside from all the awesome core commands, you can declare your own. This way, you can expose some of your custom functionality to the command line. This goes behind development and can help with maintenance or even production jobs that need to run with cron. So it truly is versatile.

A good IDE like PHPStorm

I mentioned before the good ol' times (not really) when Notepad was the editor of choice for many developers. Luckily nowadays we don't have to suffer through that as we can use IDEs for coding. I myself use PHPStorm and is of great help.

An IDE can speed up your development time by preventing code mistakes, highlighting syntax for great readability, code hinting for classes and functions in your project and many others. And with Drupal, all of these are important. Since Drupal 7 is mostly procedural you need to be aware of many functions and parameters. The IDE great reduces the time you spend online researching these APIs. And not to mention the integrations you can create with these API documentation resources.

Another great use of IDEs (which for me is the most important) is debugging. Integrating PHPStorm with XDebug on my local server really changed things around. But more on that in the next point.

Xdebug

As great as the Devel module is for printing out variables to the screen, it does not come close to Xdebug when we talk about debugging. After setting it up, all you have to do is place a breakpoint in your code and load your site page. The execution stops at the breakpoint (that was hopefully supposed to be executed) and you have access to a wealth of contextual information. You get all the global and scope variables that you can navigate through, a great callstack of what functions/methods have been triggered so far and many others.

Another cool feature is that you can play forward the execution line by line and jump inside of to be called functions to see where the code is heading. This is great for debugging where your code fails, at which point does that exception get thrown, or why that variable is null. So I do recommend checking it out.

Conclusion

And there you have it: 4 tools you can start using today to make you Drupal development experience more efficient. Using Drush and the Devel module are really only specifically for Drupal, but the use of a good IDE and XDebug is applicable to all other PHP projects as well. And I can guarantee you they are all worth using.

var switchTo5x = true;stLight.options({"publisher":"dr-8de6c3c4-3462-9715-caaf-ce2c161a50c"});
Categories:

Marek Sotak: Inline Manual 1.1 release - Rules support - onboard new users like a pro

Planet Drupal - Tue, 2014/06/10 - 8:15am

The fastest way to teach your users how to use your web application got even faster. We have integrated the great Rules module, so you can easily define logic within your Drupal installation when to launch specific tutorials.

Imagine you have built a website for your client and now you need to train the editors how to work with content. You can use Inline Manual for this already, instead of doing workshops or screencasts, however, what if there are new employees/editors coming in afterwards? How would you get them quickly learn the system?

Categories:

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

Planet Drupal - Mon, 2014/06/09 - 10:33pm

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
Categories:

OhTheHugeManatee: Authenticated User Caching Concepts in Drupal 7

Planet Drupal - Mon, 2014/06/09 - 10:21pm

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.

Categories:

larsolesen.dk: Bug triage on Commons

Planet Drupal - Mon, 2014/06/09 - 8:39pm
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
Categories:

LightSky: 5 Must Have Modules for SEO in Drupal

Planet Drupal - Mon, 2014/06/09 - 8:25pm

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?

Categories:

Write the Docs Unconference - Berlin

Documentation Team - Mon, 2014/06/09 - 7:21pm
Start:  2014-07-19 (All day) - 2014-07-20 (All day) Europe/Brussels Related event (ie. not Drupal specific) Organizers:  kvantomme Event url: 

http://conf.writethedocs.org/eu/2014/unconf-berlin.html

Write the Docs Unconferences are peer-to-peer events focused on documentation systems, tech writing theory, and information delivery.

Writing and maintaining documentation involves the talents of a multidisciplinary community of technical writers, designers, typesetters, developers, support teams, marketers, and many others. Our conferences create a time and a place for this community of documentarians to share information, discuss ideas, and work together to improve the art and science of documentation.

Join us on July 19-20 in Berlin, Germany (after the Open Knowledge Festival and just before EuroPython) for this two day unconference. Immerse yourself in knowledge and insight, shared by peers, about the art and science of documentation. You won’t find this unique intersection of people, talents and interests anywhere else.

We invite all those who write the docs to spread the word: Docs or it didn't happen!

Why should you attend
  • Be a part of the budding Write the Docs community of documentarians
  • Learn and share best practices, tools, and workflows
  • Get inspired to innovate and collaborate
Things we’ll definitely discuss
  • Modern (open source) tool chains for better collaboration
  • Strategies for engaging communities in the documentation process
  • Techniques and tips for better (technical) writing

Challenges and solutions when delivering docs in agile environments

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

Planet Drupal - Mon, 2014/06/09 - 3:55pm

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

Categories:

clemens-tolboom opened issue dreditor/dreditor#203

On github - Mon, 2014/06/09 - 3:47pm
June 09, 2014 clemens-tolboom opened issue dreditor/dreditor#203 Add option to add a selection of issue contributors

clemens-tolboom commented on pull request fabpot/sphinx-php#13

On github - Mon, 2014/06/09 - 3:31pm
June 09, 2014 clemens-tolboom commented on pull request fabpot/sphinx-php#13

:)

clemens-tolboom commented on issue clue/graph#107

On github - Mon, 2014/06/09 - 3:25pm
June 09, 2014 clemens-tolboom commented on issue clue/graph#107

I myself am interested in using all of http://phpqatools.org/ especially Mess Detector, PHP_CodeSniffer and Behat. Similar to https://scrutinizer-c…

clemens-tolboom commented on pull request symfony/symfony-docs#3918

On github - Mon, 2014/06/09 - 3:20pm
June 09, 2014 clemens-tolboom commented on pull request symfony/symfony-docs#3918

Awesome explanation. Thanks @stof

clemens-tolboom commented on pull request symfony/symfony-docs#3910

On github - Mon, 2014/06/09 - 3:14pm
June 09, 2014 clemens-tolboom commented on pull request symfony/symfony-docs#3910

Argh ... messed up :(

clemens-tolboom pushed to patch-2 at clemens-tolboom/symfony-docs

On github - Mon, 2014/06/09 - 3:13pm
June 09, 2014 clemens-tolboom pushed to patch-2 at clemens-tolboom/symfony-docs

Pages

Subscribe to build2be/com/e aggregator