Newsfeeds

As of Monday, February 18, Drupal 8 feature completion phase has officially ended. Since December 1, the original code freeze date, we've managed to add numerous awesome features that were previously in-progress, such as:

• WYSIWYG with CKEditor
• In-Place Editing
• Entity Reference Field
• Date and Time Field
• Revised content creation form
• Tour module to offer step-by-step help
• API support for Multilingual configuration
• Revamped and far more usable UI for configuring translatable entities and fields
• A RESTful API for entity CRUD in Drupal core
• Support for Views to be output in JSON, XML, or other formats made available by contributed modules
• Important under-the-hood improvements to allow for native ESI/CSI/SSI caching support in Drupal.

There are also a handful of features that were RTBC by Feb 18, but not quite ready for commit. They are still undergoing consideration. All things considered, I'm glad we extended the code freeze.

What happens now?

We now enter the "clean-up" phase of Drupal 8, where focus turns to refactoring of existing subsystems, better integrating features, and improving the consistency and coherence of the existing functionality. While APIs can and will still change as this coherence shapes up, contributed module authors are nevertheless encouraged to start porting their modules now, as there is still time to influence and fix APIs and the overall developer experience in Drupal 8. This will become much harder as we get closer to code freeze.

So ... REALLY, what happens now?

In the course of adding all of the great features we've added so far to Drupal 8, we've accumulated some technical debt and are currently well over the issue queue thresholds for Drupal core. We roll a release candidate of Drupal 8 when there are 0 critical bugs and tasks remaining. Our over-arching goal should therefore be to reduce the number of threshold issues over time.

At the same time, there are a lot of small, non-destabilizing features that would make Drupal 8 better. Especially for the kinds of iterative improvements that we would allow into 8.1 or 8.2, it doesn't make sense to hold those up until then, if we're able to get them into 8.0 without it delaying the 8.0 release date.

To help with this goal, catch and I have discussed a plan for allowing some features to continue to be committed to core up until RC1, providing we are under thresholds. To help guide us towards release, we plan to reduce the critical task/bug thresholds by one per week, starting the week of code freeze:

• July 1: 14
• July 8: 13
• July 15: 12
• …
• September 2: 5
• September 9: 4
• September 16: 3
• September 23: 2

September 23 is the week of DrupalCon Prague, and our goal would be to come out of the conference with a first Drupal 8 RC by fixing the last two critical bugs and two critical tasks (or however many there actually are) at the sprint. :-)

However, there are some caveats:

• Features can't require any new major/critical follow-ups, as that would impact the timing of release. In general, this means no new "big" features, as those tend not to be possible to accomplish without some fairly large follow-ups needed (e.g. Responsive Layout Builder, Project Browser, a new core theme, Symfony Form API). These kinds of issues will likely be moved to Drupal 9.
• Primarily, this means small, self-contained, iterative improvements that we'd be willing to backport to Drupal 8 (see http://groups.drupal.org/node/210973).
• Committer attention will generally be prioritized on tasks/bugs first, rather than features.

For now, we've decided to leave the major bugs/tasks threshold at 100 throughout release, and not tie them to the release date trigger for Drupal 8. I will re-evaluate this as we get closer to release.

What isn't bound by thresholds?

We obviously want Drupal 8 to ship as a coherent product, so a major focus will be around better integration of existing features. For example, work required to get the Symfony pieces of Drupal working well with blocks and enabling ESI/CSI/SSI caching. Turning administrative pages into Views so that they can be better tuned for the task at hand. Completing conversions of major APIs such as Twig, new Entity API, CMI, and so on, to fix rough edges such as the inability to translate/in-place-edit node titles.

General guidance on what constitutes a task or a feature is available at http://drupal.org/node/1181250. As we work through the list of these integration items, some features may be recategorized into tasks. At the same time, some issues currently categorized as tasks go beyond strictly integration and polish and will be descoped or recategorized as features.

Kudos!

While we still have a lot of work to do, I want to pause and give a sincere thanks to each and every one of the 1,077+ contributors to Drupal 8 so far. You've all done absolutely amazing work and helped establish Drupal 8 as a far more usable, flexible, designer-friendly, future-proof framework for all of us to use for the years to come. Now let's band together and get our baby polished up and out in the world for everyone to enjoy! :-)

In part one of this series, I talked about the importance of properly transferring the value you have built in your existing website. The first step of this process is to conduct a content and SEO audit of your existing site. In this post, I will talk about what to do with that data.... Read more

I’ve been looking around lately for some nice looking premium responsive Drupal themes and I have to say there are some beautiful ones out there. So I decided to share 15 I found look particularly nice.

If you’re new to Drupal you maybe haven’t noticed yet. Things more fast in Drupal. One of the mottos is: “The Drop is always moving”. It can be hard to find out what new tools and methods are becoming popular and where the action is. Good thing is, there’s lots of great sources with a high signal-to-noise ratio.

In this first blog post, I’m going to show you the main sources for fresh news and information about Drupal. In the next post, I’ll round up the best blogs and sources for tutorials in the Drupal community.

We can be a little cheeky at flink. Last year we wrote on these pages an article titled "27 reasons not to use Google Maps". Drawing from a variety of tile providers, it show-cased 27 alternatives to the by now rather stale look & feel of the Google-anno-2006 map.

The article and the maps are still there. Still generated using the lightweight, mobile-optimised map rendering library Leaflet JS and its Drupal companion modules Leaflet and Leaflet More Maps.

But we've added something: Google Maps.

Yep, you read that correctly. We now call the article "27 reasons not to use Google Maps… and 2 to do so".

What are these 2 ? First, we realised that it was very easy to extend Leaflet More Maps, so that the lightness of the Leaflet API can now be applied to Google map tiles, without having to use or download anything from the slightly heavier Google Map API. All these maps are rendered via the smaller Leaflet JS API.
Second, while we were at it, for those lucky enough to read this on a high resolution screen, we implemented Google's high-dpi tile set.

Want to know how it works? Let us explain that another time. For now, if you have a Retina® or similar display, just compare and contrast for a second the standard and high-dpi versions of the Google roadmaps shown side-by-side on this demo page. See how much tighter and easier the fonts are to read? And how at certain zoom levels the almost furry-looking webs of streets appear sharp and fine like highly strung hairs?
Brilliant!

Thanks Google Maps. You're back in the good books ;-)

If you know of any providers serving up high-dpi versions of their map tiles, let us know and we'll add them to Leaflet More Maps for all of us to enjoy.

File under:  Planet Drupal

A treelike race with genetic memory,

In the Drupal community, we always recommend using the Drupal API, and best practices for development, management and deployment. This is for many reasons, including modularity, security and maintainability. But it is also for performance that you need to stick to these guidelines, refined for many years by so many in the community.

read more

When developing Drupal applications on my Mac, I like having access to the same tools I use on servers. This allows me to test for possible conflicts and issues, while evaluating performance impact. I recently decided to look at getting Memcached going on my Mac since we use it on servers at Classic Graphics. Memcached is a memory-based caching system for speeding up web applications by storing chunks of data. Drupal and PHP can leverage Memcached to assist with performance.

Below is a bit about what I learned through the process of getting this going in my local development environment.

I am using homebrew and homebrew-php as the base for my local development setup. If you want to checkout the details of my setup, see my brewStack docs.

Setup the memcached service

• Installation
  $ brew install memcached

  • The following command will show all memcached options.
    $ memcached -h

• There are several options to run memcached after the initial installation.

  1. Run memcached from a terminal session.
     $ memcached
  2. Run memcached as a daemon.
     $ memcached -d
  3. Use launchctl to start memcached at login and keep it running.
     
     • Copy the provided launchctl plist file to ~/Library/LaunchAgents. I like keeping all of my launchctl plist files together.
       $ cp /usr/local/Cellar/memcached/1.4.15/homebrew.mxcl.memcached.plist ~/Library/LaunchAgents/
     • Load the memcached plist file.
       $ launchctl load -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist
     • You can stop the memcached service with the following command.
       $ launchctl unload -w ~/Library/LaunchAgents/homebrew.mxcl.memcached.plist
     • If you drop the “-w” from the previous two commands, memcache will not load automatically when you restart your Mac. This may be the way you want to run memcached so it doesn’t take up system resources when you don’t need it.
     • The following command will show you if the memcached service is loaded in the launchd system. If you get a line returned, it is running.
       $ launchctl list | grep memcached

Setup the php-memcache extension

• Install php-memcache so PHP can communicate with your memcached service.
  
  • The installation command below requires homebrew-php.
    $ brew install php53-memcache
    Note: If you are running PHP 5.4, you can change “php53-memcache” to “php54-memcache” in the command line above.

Setup Drupal to use memcached for caching

• Install the Memcache API and Integration module. Your Drupal instances will need this module to save its cache data to memcached.
  • Install and enable the module.
  • Details on usage and installation can be found here and here.
  • I have been using the following settings in my setings.php file with success.
    $conf['cache_backends'][] = ’sites/all/modules/memcache/memcache.inc';
    $conf['cache_default_class'] = 'MemCacheDrupal';
    $conf['memcache_key_prefix'] = 'something_unique';
  • You can optionally enable the memcache_admin module to view memcache statistics at /admin/reports/memcache.

Note: If you have any issues with the memcached cache clearing, you can restart the memcached service.

Additional Resources

• Memcached website.
• Drupal Memcache API and Integration documentation.
• If MAMP is your thing, checkout this lullabot article on setting up memcache with MAMP.
• Quick way to get memcached status at the command line.

Blog Category: DrupalMac var switchTo5x=false;stLight.options({publisher:'dr-4334ed90-d702-124d-3358-aea68cdffdd9'});

“The snow flies against the glass, but refuses to stick. Medard stands tall, with an eagle’s outstretched
wings above him.”

[More...] Read the rest

Time for another pseudo-quick update.

I know it’s been a long road so far with this game, a lot longer than I planned. It’s amazing how much the computer gaming world has changed since I started this thing — back then, there were no iPhones or iPads, and most gaming was either on desktops or consoles. Now, the game industry has shifted dramatically toward mobile devices, just like a lot of other industries. I sometimes wonder how many people still use their desktops for gaming. Nevertheless, this game needs to be done and put out there, and it’s about time I did something about that.

So as I mentioned in my last post, I managed to get over a pretty large hump at the end [More...] Read the rest