Feeds

Author

Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
May 15 2020
May 15

The editorial experience becomes more and more important for each CMS. Users want more control but easier interfaces. In Drupal, one of the biggest and most popular OpenSource CMSes on the market, the search for the best experience continues until today. Various approaches are tested by the community and with each edition, some new approaches are investigated and some are abandoned. From the perspective of a Drupal agency, it is quite interesting to watch this process unfold.

Let’s explore how Drupal editorial experience got to where it is today and where it is heading.

Drupal beginnings

Initially, Drupal pages were built on nodes. Think of a node as an article or page in a typical CMS. A node had a Title and a Body. You titled the node and inserted all the content in one big text field. Typically people would type in the body field the content of the page - this would be mostly text, but you could stick anything you like in there (HTML, images etc) Quite quickly people incorporated WYSIWYG editors into the body (CKEditor, TinyMCE and other ones were integrated as community-contributed modules). You could now author a quite complex page without knowledge of HTML.

The WYSIWYG’s were so popular, that in Drupal 7 CKEditor was added into Drupal core.

On the database side, everything  was still quite simple. A node table with title and an additional table for the body. That is how Wordpress stayed pretty much till today. In Drupal however, the evolution continued. 

Drupal 6 - the domination of CCK & templating

At the time of Drupal 5, an initially small module was created, which in Drupal 6 completely changed the rules of the game (the Content Construction Kit module, aka. CCK).

CCK was a contributed module which allowed to add additional fields to nodes. This does not sound too exciting, but it was. The absolutely brilliant CCK module allowed users to add various fields (number, text, bool, select etc) and it was creating a separate database table for each field. The table field was matching what you wanted to store in it (A decimal, a float, a varchar, a text etc). On top of that, it was adding the field to the default content form. 

This was magnificent because you could create a form with multiple fields and then display the data in a template pre-built by the developer (an image on the right, stats on the left, long tests at the bottom -- that sort of thing). This is how one was building pages in Drupal. The editor did not have to ‘design’ the layout in WYSIWYG anymore. You could just fill in a form with fields and the template took care of the rest. 

Moreover, you could now query in SQL for particular nodes by the field content. Eg. if you created a City node type and added a population decimal field to it, you could search for all cities with a population larger or smaller than a set amount. 

Very quickly after CCK, another module was created - the Views module. Views allowed users to build the queries in the admin interface. You could now create a list of cities ordered by population with a title and a teaser and some other data without the need to code anything. This was a massive breakthrough which allowed developers to create very compelling websites without writing a line of code. 

CCK was so popular that is was incorporated into Drupal in version 7 and Views followed in Drupal 8.

This is how Drupal websites were built for quite a while. Many are still built like this today.

Drupal 7 - First attempts at page layouts 

From Drupal 7 fields were considered a standard. Templating, however, was not sufficient for the community and clients. Drupal developers began searching for solutions to allow more control over the content display with just the UI.

The main reason for the search efforts is the way websites began to be built. The knowledge that an additional click reduces the chance the customer will get to the content was propagating. The approach of having a sidebar and dividing information into pages was no longer interesting. Long scrollable pages were born.

The advent of long landing pages with content in sections began somewhere in 2010. It was, however, the mobile that effectively killed the sidebar. You just could not fit a submenu in a sidebar on mobile. You now had to stick everything on one long scrollable page with multiple sections (scrolling on mobile is much easier than clicking links). And each section had to be interesting, compelling and different.

Drupal developers started to search for solutions on how to allow the editors to create sections on pages easier.

The initial solutions were:

  • Panelizer - a module based on another one (Panels) which was effectively taking over the node display. Instead of just fields, you could now design your page to include blocks, fields, static images, views and various other elements Drupal renders. Editors could override “the default’ predefined layout on a node by node basis. The solution was great and got a lot of traction in the Drupal world.
  • Paragraphs - a bit late to the party on Drupal 7, paragraphs nonetheless made a splash. It started to gain popularity very quickly. The main reason for that was that it was bridging the 2 worlds: drupal form building experience and freedom to add blocks while maintaining ease of use for the editors, which the above solutions did not have. 
  • Context - Context a more general module, which gave users a mechanism for well - acting on contexts (eg what page you are on, what user or role you are etc. ) Using these conditions, one could add reactions (eg. show this block, set this setting). Context was very widely used for a while to arrange blocks on pages. If I am on this page, I want to see these blocks. The downside was you managed the layouts from a central location, needed admin privileges to manage the layouts and the UI was not straightforward. Not suitable for large websites.
  • Blockreference - a simple yet powerful module which allows referencing blocks from a node and effectively stacks them one over the other. This solution did not get a lot of traction.


Current state in Drupal 8 and onwards

Drupal 8, being a very big re-write of Drupal has evened out the playing field a little, allowing the community to vote again on what it thinks should be the approach to building pages. 

Blockreference did not get a D8 version, mostly because entityreference module was now in Drupal 8 core and blocks became references. One could theoretically build pages like this using what Drupal gives out of the box, but that did not catch on.

Context did not manage to gather a lot of usages in D8 and until today does not have a stable release.

Paragraphs - initial winner

The paragraphs module came out as a clear winner. It was stable very quickly and became the de-facto standard in Drupal 8 for over a year. With over 140k installations it now runs one-third of all the drupal websites. It is also worth mentioning that popular Drupal distributions created on Drupal 8 chose paragraphs as the base of their content editing experience. These would be in particular Thunder - distro for publishing houses and Droopler - for building corporate websites. 

Here is an overview of how paragraphs work in Drupal 8. A lot of work is also being done to further improve the editorial experience in the Experimental widget.

Panelizer moved to the core (became Layout Builder)

Panelizer took a different road. It lingered on behind paragraphs in term of the number of installs but because of its popularity in D7 work was underway to migrate it into Drupal core (just as CCK in d7). It was however only in Drupal 8.5 that Layout Builder became available (as an experimental module). At Drupal 7.8 it became stable. 

Layout Builder offers great flexibility and great promise, but the UI even as of writing still has a long way to go to be self-explanatory (one needs a bit of training as many things are not obvious). Also, there is no clear “best practice” as to how to manage content now and what should be composing the pages. Integrations are also lagging, most importantly with search modules. 

Currently, there is no clear winner and best practice is not established yet. There is the paragraphs module with 100k installations, multiple integrations and a clear UI. On the other hand, there is the Layout Builder which is in Drupal core, what is an incredible strength. 

Still, though there are many modules which did not stand the test of time and were removed from the core.

Gutenberg (a WordPress editor)

Last but not least there is the Gutenberg project. It is the newest of the interesting editors in Drupal. It was ported from Wordpress where it is the main editor.

Gutenberg is a React-based editor which takes over the whole editing experience giving the user a WYSIWYG like an experience. It differs in approach to Paragraphs and Layout Builder in that it does not store the layout or entities in the database, but it stores the generated HTML. You create the content with a WYSIWYG editor and the resulting HTML is saved. This makes it a true WYSIWYG readability of the content for machines (automatic updates or migrations of such content may be troublesome). Nonetheless, it continues to be integrated into Drupal better and better. With 900 or so installs it is by no means comparable to the two above but the speed of adoption is impressive. Check out a quick overview of Gutenberg in Drupal.

As you can see, there is no clear winner. Drupal community is still testing various approaches to building websites and empowering the editors. On the one hand, this is fantastic because competition helps the best solution win. On the other, the efforts of developers are spread over multiple various approaches, making progress slower. What is best? I do not know.


 

How Much Does It Cost To Build a Website With Drupal

Apr 16 2020
Apr 16
Apr 03 2020
Apr 03

The value that the community brings to the development of Drupal

Drupal is known for the community that it has amassed as an open source software. But what is the value that the community brings to the development of Drupal?

First off, drupal is an open source CMS. What that means is that everybody can download and mingle with it. Because of this, Drupal has gathered a community of supportive members. Soon, the community has started to actively contribute with code and ways to further developed and improve Drupal. Drupal has more than 42,000 modules that were developed by the community. On top of that, regular security issues are discovered and fixed by the members in their own free time. Also, users are taking their time to answer questions posted on forums by new members to guide them in the Drupal world. This has led Drupal to be known as one of the most active, helpful, dedicated and loyal communities in the world.

DrupalCon Nashville 2018 Copyright Amazee Labs

Photo's DrupalCon Nashville 2018 copyright Amazee Labs

We all come together at DrupalCon

So where do the members of the community spend their time when not sitting in front a of a screen coding?

Well, the biggest event of the year is the DrupalCon. Every year it takes place in another location. With two conventions scheduled for 2019, one in sleepless Seattle and the other in incredible Amsterdam, DrupalCon is sure to gather a big crowd this year. Activities which are scheduled include keynotes with inspiring figures from inside and outside the community, trainings, summits, birds of a feather meetings and diverse social events.

DrupalCon is a great opportunity to meet and connect with new people, while acquiring more knowledge about Drupal and the direction it's heading in. On top of that, there is a chance of engaging into conversation with highly skilled people with expert knowledge in their domain, which can guide you and give you tips and tricks on what to do. So, if you’re a Drupal enthusiast, be sure to grab a ticket, pack your luggage and join the biggest Drupal social event of the year.

DrupalCon Nashville 2018 Copyright Amazee Labs

Photo's Drupal Camp Vienna 2015 copyright Amazee Labs

Cosy get-togethers in Drupal Camps

Now that we talked about the biggest social event of the year, Drupalcon, we can take a look at what the Drupal community is doing for the rest of the year. The community also organises smaller events, throughout the year, for regional groups of people. These meetings are more frequent than the DrupalCons. The activities which are undertaken in those camps are usually talks held by speakers on different subjects of interest to the community. The camps also offer training talks for beginners. The main focus of these type of events is to find out more about Drupal, share your Drupal experience and also to meet the local Drupal community.

List upcoming Drupal camps:

Name of the Camp Date Location Nerd Summit 2019 16-17.03.2019 United States, Amherst MidCamp 2019 20-23.03.2019 United States, Chicago Frone End Accesibility Summit 08.04.2019 United States, Seattle DrupalCamp Spain 6-12.05.2019 Spain, Conil de la Frontera Drupaldelphia 10.05.2019 United States, Philadelphia Secure Open Source Day - Haarlem Edition 11.05.2019 Netherlands, Haarlem Stanford DrupalCamp 17-18.05.2019 United States, Stanford Frontend United 17-18.05.2019 Netherlands, Utrecht DrupalCamp Belarus 17-18.05.2019 Belarus, Minsk DrupalCamp Kyiv 25-26.05.2019 Ukraine, Kyiv Flyover Camp 31-02.06.2019 United States, Kansas City DrupalCamp Poland 31-02.06.2019 Poland, Wrocław Drupal Developer Days 10-14.06.2019 Romania, Cluj-Napoca Save the Date - Design 4 Drupal Boston 26-28.06.2019 United States, Cambridge DrupalCamp Asheville 2019 12-14.07.2019 United States, Asheville DrupalCamp Colorado 02-04.08.2019 United States, Denver Cornell DrupalCamp 26-27.09.2019 United States, Ithaca DrupalSouth Hobart 27-29.11.2019 Australia, Hobart

How are new Drupal users integrated?

Now that we know how the Drupal community likes to spend its time, we can have a look at how the newcomers are being integrated in the community. First, the newbies can attend training sessions which are held on multiple occasions over the course of the year, with different locations. So, if you’re getting an interest in Drupal but don’t know where to start, you can search for the nearest Drupal beginner onboarding camp to find more about Drupal and the Drupal community. On top of that, you can also rely on the Drupal community forums by posting questions there and letting a more experienced user answer your question.

DrupalCon Nashville 2018 Copyright Amazee Labs

Community spotlight photo collection, indidual images' rights belong to their respectful owners. Collage created by Sooperthemes and licensed under a Creative Commons Attribution 4.0 International license.

Drupal community spotlight

Drupals open source means that everybody can get involved, making the community vibrant and full of inspirational stories. The community has the spotlight section where there are numerous articles about different members of the community and their journey from being a beginner to a well respected member and contributor.

Ildephonse Bikino

Another inspiring story is that of Ildephonse Bikino. He discovered Drupal through his job. He had the opportunity to attend the DrupalCon from 2016 held in New Orleans via a scholarship provided by the Drupal Association. There, he saw the opportunities that the open source software can bring. This led him to host his first Drupal Global Training Day in Rwanda, where he was expecting a number of 50 atendees. However, to his surprise, this number quickly grew and he had a list of 388 participants. Not wanting to turn his back on the Drupal enthusiasts he rose to the challenge and transformed a one day training into eight sessions spread across multiple weekends. This way, he made sure that every Drupal enthusiast received a proprer training. His dedication to the cause is what makes him a trully inspiring person and gives us a reason to tell his story.

Kevin Thull

Another great spotlight is the one about Kevin Thull. He got involved into Drupal through freelancing and started really getting involved with the community by the time the book Using Drupal 6 came out. He is known for being the mastermind behind the recording of the different Drupal events. He started recording drupal camps back in 2013. At first, everybody questioned his decision, however, he stayed true to his belief, that it is important to record those events. To date, he is personally responsible for recording over 800 sessions and giving up countless of hours of his time to achieve this feat. He was awarded with the Aaron Winborn Award in 2018 for his contribution to the Drupal community.

Rachel Olivero

For example, we have the case of Rachel Olivero which has recently passed away. She first started getting involved with the community at the DrupalCon 2017 in her hometown of Baltimore, where she participated for the first time in a code sprint and also reported her first bug. She was engaging constantly with the community on social platforms. As a blind person, she led an accesibility breakthrough at DrupalCon Nashville. She was always sharing her knowledge and expertise regarding this topic. Her aim was to make life easier for the users with disabilities. She understood the importance of diversity and so she was also engaged with the Drupal Diversity and Inclusion Team. Although she was part of the community for a short period of time, she left her mark through her actions and her contributions.

Aaron Winborn and the award named after him

The Aaron Winborn Award, also known as the “Academy Award” of the Drupal Association is an honor given to the members of the Drupal community that show personal integrity, kindness and an above-and-beyond commitment to the community. It was named in the honor of Aaron Winborn, a big community contributor which passed away after losing a battle with Amyotrophic Lateral Sclerosis. A specific disease which causes the death of the neurons that are controlling voluntary muscles. In order to remember the contribution which Aaron Winbord has brought to the Drupal community, the award was named after him after his death in 2015. To date, the award was given to 4 people which had a big contribution to the community and namely Cathy Theys, Gábor Hojtsy, Nikki Stevens and Kevin Thull. Right now, the nominations for the next awarding are open, so be sure to nominate your favourite member of the Drupal community.

Conclusion

In conclusion, the community is of utmost importance to the development of Drupal. The community is what keeps the CMS alive, while also in a costant state of evolution. Drupal has made it possible for people of different cultural backgrounds to cooperate and stand united for the same cause.  This reflects well on the unofficial motto ,"Come for the code, stay for the community".

How to find and hire the best Drupal agency

Mar 30 2020
Mar 30
Jan 21 2020
Jan 21

We had a Drupal project, implementing a commerce site for a local store. We use Drupal Commerce, as always, for this type of websites. You may see that we have alot of Drupal Commerce themes on our portfolio.

During the project, there was a minor request from our customer: add the Continue Shopping button to the cart. This feature is available on Ubercart, especially for Drupal 6 Ubercart users. Most of ecommerce sites have this feature as well. But it is not built-in with Drupal Commerce.

As I searched on the Drupal.org issues, I found a very helpful thread: Continue shopping in cart. Zorroposada presented a custom code to achieve it:


<?php
/**
* Implements hook_form_FORM_ID_alter(&$form, &$form_state, $form_id)
*/
function MYMODULE_form_views_form_commerce_cart_form_default_alter(&$form, &$form_state, $form_id) {
$form['actions']['continue_shopping'] = array(
'#type' => 'button',
'#value' => t('Continue Shopping'),
'#weight' => -999,
);
if (isset($_SERVER['HTTP_REFERER']) && strlen($_SERVER['HTTP_REFERER'])) {
// if user comes from product detail page, redirect user to previous page
$form['actions']['continue_shopping']['#attributes'] = array('ONCLICK' => "history.go(-1); return false;");
} else {
// redirect user to product list page 'store' by default
$form['actions']['continue_shopping']['#attributes'] = array('ONCLICK' => "window.location.href='" . url('store') . "'; return false;");
}
}
?>

I do nothing better here. I just wrap this code on a custom module, so any lazy users can just download and install it.

The module is called "Commerce Continue Shopping", and you will find it in the Other section of the Drupal module page when unzip it to /sites/all/modules. Enable it and you will see the Continue Shopping button on your cart.

Pls download the module here: commerce_continue_shopping_7.x-1.0.zip

Jul 10 2018
Jul 10

I had previously created a simple Drush based script to recursively scan a Drupal project and create a Sublime Text 2 autocompletions file from all functions the scan found. Unfortunately this file was not unique to each project and needed to be generated each time anything changed. So I wanted to get around the problem by creating a plugin which leverages the ST2 API.

The plugin uses the on_query_completions method of the ST2 API to inject a project specific JSON array of completions. This array is generated each time a file is saved by scanning up the project tree until a Sublime Text project file is found where it then recursively scans each .module, .inc and .php file for functions and assembles a JSON formatted completions file. This completions file is stored alongside your ST2 project file.

For this plugin to work you must save your ST2 project file in the root of your Drupal project (at the same level as index.php, CHANGELOG.txt etc). You will also want to exclude the completions file from any VCS you use. In git you could add the following to your gitignore file:
*.sublime-projectcompletions

As I have an SSD based computer the completions file is generated very quickly and using threading there is no noticeable loss of speed in ST2 while it generates. I haven’t tested on non SSD enabled machines so some feedback would be very useful. If anyone with better Python skills than me can optimise the code or offer solutions I’d be very grateful.

The plugin has been submitted to ST2’s excellent package control repository. From there it should be easy to install but until it appears you can also manually install it from github: https://github.com/tanc/st2-drupal-autocomplete.

Jul 10 2018
Jul 10

After trying Sublime Text 2 for a day I’ve already fallen in love with its simple but elegant interface.

Screenshot showing main screen of Sublime Text 2

I’m generally a fairly happy user of Komodo IDE but don’t really like its klunky interface, occasional crashes and its often slow response. What I do like about Komodo is its ability to scan through your project and provide autocomplete suggestions, something that Sublime Text 2 doesn’t do.

So I decided to write a script to fill some of this gap in Sublime Text 2. The script simply scans through a specified directory and creates a json formatted sublime-completions file from all the functions it finds.

For Drupal coding I now have a custom Drupal6.sublime-completions file in my ~/Library/Application Support/Sublime Text 2/Packages/User directory which gives me autocomplete suggestions for all the drupal core and the top 100 drupal module’s functions and parameters.

So I can start typing “drupal_get_pa”, hit control + space and Sublime Text will offer me a choice of functions to complete.Screenshot showing autocomplete functionality.

Choosing one and hitting return completes the function declaration, opens the brackets and fills in the parameters the function is expecting (and their default values if they exist).
Screenshot showing parameters in autocomplete.

This is just a start after a couple hours of coding. What I’d really love to see in Sublime Text 2 is the docblock shown for a suggested autocompletion. This is a powerful learning tool in Komodo where you can start typing a function name and see the associated docblock explaining what that function does and which parameters it is expecting.

File: Drupal6.sublime-completions.zip

Decompress the download above and put the Drupal6.sublime-completions in your user directory. Sublime Text will automatically pick it up and start using it in PHP files. You may need to turn autocomplete on in your preferences.

Update: I’ve created a drush based command to generate this file. Get it here.

Jul 10 2018
Jul 10

React.js is a very popular JavaScript framework created by Facebook. It allows you to build beautiful, interactive and fast interfaces, with which users will fall in love. Drupal, on the other hand, is a fantastic CMS with you can build small, medium and huge websites.
 
Sometimes you want to pair the two frameworks together - offer sophisticated Drupal backend, and a slick, quick frontend based on React. That is when Drupal and React can come together.

In this post, I will explore various methods of combining the technologies.

Headless Drupal vs. embedded React

The primary choice you have to make when using React with Drupal is whether you want to use a "headless Drupal" approach where Drupal is only in the backend and React is the only interface user ever sees or whether you just want to add a React app to the Drupal website rendered by the Drupal templating engine. Let me elaborate.

Headless Drupal with React frontend

In a headless scenario, Drupal serves as a backend for a frontend application built in React. The systems are entirely separate and communicate via HTTP - eg. REST of GraphQL.

This option is best if you want to:

  • Create a Progressive Web App (PWA) for users on mobile devices.
  • Create a single page app that stores data in Drupal
  • Create an easy to use the access point to a subset of a big system built on Drupal. Say you have local agents who visit local stores and send screenshots of the merchandise display. They might need only an one easy to use interface without the complexity of your complete CRM of managing stores, which the office uses
  • Create a smaller website that just pulls some data off of a big website, e.g. only displays news from one section of a huge news magazine.

How to create a Headless Drupal app

If you chose headless Drupal, you then build a separate React application which communicates with the backend via HTTP requests, just as you would with any backend system. React then does not really care what is in the backed. It only needs to be able to use the exposed API. 

Facebook prepared a fantastic boilerplate React project to help you start.

When the React app is running, you then create endpoints in Drupal, which serve as data sources for your React app. Drupal 8 is a fantastic piece of software and comes packaged with a full REST API. You can find documentation on Drupal Rest API documentation page. Specifically, have a look at the REST UI module which enables you to create clean configurable endpoints for entities. 
We wrote a great post about setting up REST endpoints for a JavaScript application.

If you prefer to use GraphQL, there is a GraphQL module which is under active development and allows you to build GraphQL endpoints.

If headless Drupal is what you are after, it is also worth checking out an example headless project: the ContentaCMS, which is an entirely headless implementation of Drupal with popular frontend frameworks. The React implementation can be inspected here.

React app embedded in Drupal

Quite often you don't need a full headless implementation, but just want one or two highly interactive elements on a few pages of your website. It might be a very complicated form with many steps which works nicer without a page reload or a different UI element which is highly interactive and will work much nicer done in JavaScript. 

In that case, it makes much more sense to use React.js to create a component and embedded in a page that is served by Drupal. This way you can use all the Drupal greatness everywhere else, in example registration, rendering of fields, views etc.

How to embed  a React app in Drupal

For starters, you will add React library to your website, just like you would add any other js library (e.g. a jQuery or some other library for a slider or gallery). Depending on whether the script is required on every page, or is it part of a theme or a module, there are various ways in which you can add a js library to the website. I will not go to details, because there is a lot of good documentation here:
1. https://www.drupal.org/docs/8/api/javascript-api/add-javascript-to-your-...
and 
2. https://www.drupal.org/docs/8/theming-drupal-8/adding-stylesheets-css-an...
 

A quick method, that is not recommended, but will work for testing purposes, is to just add the script tags to html.html.twig in your template:

<script crossorigin src="https://unpkg.com/[email protected]/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/[email protected]/umd/react-dom.production.min.js"></script>

and your own script with the app.

<script src="http://www.droptica.com/paht/to/my/scripts/myreactapp.js"></script>

One caveat of an embedded app is that the only language you can use is Javascript. You can use neither JSX, nor TypeScript, which you might use when you create a headless app. This is because in a complete react app, Webpack or Babel transpile JSX or TypeScript into JavaScript. Here in our example, for the sake of simplicity, we are not using these tools. 

Tip: To be able to use JSX you would have to use Webpack first to compile your JavaScript file and then add it to Drupal. A good approach then would be to use the create-react-app repo to start and then just copy over the resulting js file created after transpilation and embed that. You would then not need to embed react.js separately because it is already bundled in transpilation. Setting this up, however, so that auto refresh would work and the file would be copied to Drupal, is a bit more complicated and therefore we are skipping it.

Coming back to our example, the first thing to you have to create is an HTML tag in your markup in which the React app will live. It can be a div rendered in a block or by a custom controller on a separate route.

<div id="myreactapp" />

In myractapp.js create your app.

ReactDOM.render(
React.createElement(MyApp, {title: 'Hello World!'}),
  document.getElementById('myreactapp');
);

Done! You have a react app embedded in a Drupal page. You can get data for it from a REST API like you would in the Headless example, or you can use the drupalSettings global for your initial data set.

function Welcome(props) {
 if(props.isfront == true) {
return <h2> Welcome on front page<h2>
}
else{
return <h2> Welcome on another page </h2>
}

ReactDOM.render(
React.createElement(Welcome, {isfront: drupalSetting.path.isFront}),
    document.getElementById('myreactapp');
);

Just remember that if you ever want to save changes to any data in Drupal, you still need to create an endpoint and push the changes there. 

That is it! Combining React and Drupal is as easy as pie.
Enjoy!

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web