Today was a tribute to the Druplicon, our community's iconic Drupal drop: Lashing rain and a river of 3300 Drupalistas (biggest Drupalcon ever) flowing into a sea of attractions: Sessions and BOFs, the exhibit hall, a hilarious game-show moderated by Rob and JAM, Holly Ross' and Dries' keynote, the group picture, you name them. It's just amazing to see how the Drupal community is growing from year to year; Kudos to the Drupal Association for doing a great job. Before I let you enjoy Michel's pictures further down, Dries' key messages from the keynote: The future of Drupal is not about managing content, but web experience management / Drupal 8 timeline: Code freeze scheduled for 1 July 2013. Expect Drupal 8 to go into production in 2014.
The module automatically generates thumbnail for teasers and RSS feeds. From images included in node body (or imagefield which attached to node).Features
- Using Image Styles for thumbnail.
- Ability settings separately for each type of nodes. Or by default for any.
- Integration with Views.
I'm getting ready to head in to DrupalCon, where over the next few days I'll be talking education and open learning with anyone who is interested.
And as I'm heading in, I have MOOCs on the brain - not because I'm particularly a fan of MOOCs, but because of the tendency to take a great thing (in this case, information and interpersonal exchanges distributed broadly over the web) and reduce it into something that feels more manageable, but is ultimately something lesser (in this case, MOOC platforms). More on this later.The Web Is Your MOOC
Part of the reason that I'm thinking these thoughts prior to heading into DrupalCon is that I've long held the notion that open source communities have been engaging in effective peer-supported learning, even while many for-profit companies and academic communities have been struggling to distill the process of peer-supported learning into something resembling a replicable product. From having participated in and built many types of learning communities over the years, simpler is often better - many open source communities have done amazing work with listservs and issue queues, and many more feature-rich platforms have withered because, over time, a site owners "must-have" feature is the post launch usability nightmare. There's a moral in there about user-centered design and user testing, but that's a subject for another post.
But getting back to MOOCs, the early MOOCs - the ones run by Stephen Downes, Alec Couros, Dave Cormier, George Siemens, (and yes, I know I'm forgetting people - please fill in the gaps in the comments) etc - encouraged participation from anywhere. If you had a blog with an RSS feed, you were in. Participants remained in control of their work (depending, of course, on the publishing tool they were using. Open source platforms generally offer more options for data ownership and portability than their closed brethren). The MOOC was like a marauding mob of information, with the potential to sprout anywhere.It's All About The Portfolio
In the post-lifestream, post-MOOC era, it's been rare to see much excitement about portfolios. This doesn't surprise me, because like all good ideas, portfolios have been around for a while, and thus lack the shiny newness that generates great marketing copy. However, the need for the concept hasn't diminished - any time you see a site that promises to collect the sources of your learning into a single location, so you can show your employers what you know! - you should think, "portfolio." All of the sites that promise to simplify collecting and curating your digital footprint? Portfolios. A lot of the conversations around documenting and receiving credit for informal learning have their roots (and possibly solutions) in portfolios.
In the conversations we have had about portfolios over the years, we have seen three main barriers, or areas of misunderstanding:
- Distinguishing between a working and a presentation portfolio: simply put, the working portfolio is a running collection of just about everything you do. The presentation portfolio is a selection of elements from the working portfolio selected for a specific purpose. Portfolios can serve different purposes for different reasons, and the relationship between the working portfolio and the presentation portfolio is key.
- Portfolios need care and feeding over time: as mentioned before, the working portfolio is messy. Periodically, the working portfolio needs to be pruned and cleaned up. But, messy is great, and if it's not messy, that could be a sign that things aren't working as they should.
- Ownership and control of the portfolio: because most portfolio implementations are paid for by an organization, the organization usually controls access to the portfolio and any information in it. Organizational control is also seen as an essential element to assessment. However, this flies in the face of learner control and ownership of the means by which they learn. Ultimately, this is a data portability issue with implications for the learning experience. More on this later.
One of the things that has been particularly underwhelming about the corporate MOOCs that have cropped up is their uncanny resemblance to an LMS with an open enrollment policy. While there are many differences between the platform-stylehttps://chronicle.com/article/Providers-of-Free-MOOCs-Now/136117/ MOOCs and the original versions, the lack of learner control is a key element. Like Vegas, work in a MOOC stays in a MOOC (unless, of course, a company pays money to study student data).
In the platform-style MOOCs, the open web is missing. From a learner perspective, the portfolio is MIA. For a learner, throwing the evidence of your learning into a space that someone else controls isn't a viable long term strategy.
So, if you're at DrupalCon and want to talk open learning, let's make some time and sit down together. Open source, and the methodologies that support sustainable open source development, have a lot in common with open learning. I'd love to hear what other people are doing in this space.
Development sponsored by Propeople.
This is a Drupal module that utilizes the sidr.js jQuery plugin developed by Alberto Varela. http://www.berriart.com/sidr
Last Friday the annual one-day DrupalJam conference was held in the Rotterdam Feyenoord soccer stadium. The conference, which saw its eighth edition - if I recall correctly - is shifting to be more business focused with its new motto Drupal beyond the code, and was a great success with over a 100 participants. This blog post serves as a high-level summary of a couple of the talks that I attended.
Rootwork.org: We need to talk about your stylesheets: An interview with Jonathan Snook at Drupalcon Portland
This is an intervention.
CSS is pretty simple. Classes, IDs, elements and pseudo-elements, with style definitions attached to each. Calling it a "language" is a bit of a stretch (though preprocessors like Sass fit the bill).
But let's be honest, for years our stylesheets cascaded right on out to infinity.
Huge files with table-of-contents comments to try to make some sense of it — until a quick fix got pasted down at the bottom. Brittle style definitions relying on tight coupling with HTML structure. Pieces of styles being replicated here and there for different components with similar features, without any way to tell they were related in the CSS.
My stylesheets were like that too, because strategies for writing CSS had barely altered since the days when it was used to change the colors of the scroll bars in Internet Explorer. Luckily, in the past couple of years both CSS architecture and CSS preprocessors came into their own.
SMACSS, or Scalable and Modular Architecture for CSS, was developed by Jonathan Snook, a featured speaker at Drupalcon Portland. I'm really excited to get the opportunity to have Jonathan speak, not only because of my personally well-dog-eared copy of SMACSS, but because Drupal itself is adopting a SMACSS approach to its CSS.
I spoke with Jonathan about sustainable stylesheets and the future of SMACSS. For an even more detailed look, please join me at Jonathan Snook's featured Drupalcon Portland this afternon, Tuesday, May 21 at 4:30 PM.
IB: What's the biggest mistake you see people making when writing CSS?
JS: I think the biggest mistake is thinking of everything in the context of a single page. We're no longer just building sites with a design for a home page and an inside page. We're developing complex systems that need to work in a variety of contexts and we need a development approach that complements that.
JS: The biggest win is maintainability. The SMACSS methodology makes it easier to build larger projects by breaking things down into smaller components. Like the move from spaghetti code to MVC frameworks on the server side, this separation of concerns on the CSS side improves the process of putting a site or web app together.
IB: In the last part of your book, you talk about how the SMACSS approach fits in to work using a preprocessor like Sass. There have been a lot of developments in Sass in the past year — have they had any positive effects on your use of the SMACSS approach?
JS: With Sass, the introduction of placeholders was a positive step forward. Overall, Sass (and other preprocessors) are a great way to augment — but not replace — the way people write CSS.
IB: What are your thoughts on BEM? Do you see it as compatible with SMACSS?
JS: I see BEM as very compatible. BEM really enforces naming convention, which is a very important concept in SMACSS. They both take a modular approach to site development.
IB: What are you tacking next when it comes to CSS and frontend development? Will there be a "SMACSS Part Two"? Or something else entirely?
JS: I'd love to augment SMACSS with case studies and expand on some of the ideas in the book based on things that come up in the workshops I do. I'd also like to work on a prototyping/site development tool that uses the SMACSS concepts. We had built something like this when I was at Yahoo! that I think many people in the industry would find really useful. Hopefully I can find the time to work on it!
Image credit Flickr user stevensnodgrass. It's spaghetti! (As in code.)
This module provides a feature and a migrate script to set up and sync the Flemish e-gov product catalog into Drupal.
The feature beipdc_products will create a content type which has all the fields you might expect from the product catalog. It was created for regular mortal users (non-developers).
The migrate script beipdc is the real intent of this module and provides a migration script to import and sync data from the product catalog into your Drupal installation. It is now built with the field names provided in the feature it's bundled with, but it can easily be modified to fit your existing content type or other data structure.
The first time I hosted code, I did it on Github. Naturally, I got really used to the slick interface for browsing through my remote files, viewing my commits, and generally visualizing what I had hosted on their site. So when I started contributing code to drupal.org, I felt like I was working in the dark. I'd send up my commits and branches, and trust that they were up there, even if I couldn't "see" them.
Little did I know, that you actually CAN browse through your code on Drupal.org.
Every project page has a little link at the bottom left called "Repository Viewer"
This link takes you to http:// drupalcode.org/project/<your-project>.git, where you'll find…
But those are just your commits. To see your files, click the link that says "tree"...
Your files were there all along… hidden in plain view.
If your curious about how it works, the display is generated using Gitweb, an open source project for viewing remote git repositories in a web browser. This functionality used to be available at cvs.drupal.org, before the community migrated to Git for version control, and the code browser apparently moved to drupalcode.org.
In this article I am going to show you how to embed a View in a template file (.tpl). Using a cool Views API function, you can render the display of any View and even pass it arguments.
A couple of months ago, after a particularly furious week of trying to contribute something useful to Drupal core, I woke up one morning to a see a lot of activity on my twitter account (Pretty much unheard of for me). I had received this tweet from webchick (Angie Byron).
@alasdaircf Hey, thanks for all the CMI conversion patches! Keep 'em comin'! :D
This was an amazing feeling as Angie is one of the core maintainers for Drupal and a really big name in Drupal . But in a deeper way I think that it symbolises some of the things that I really appreciate about the Drupal community.
Drupal, probably like many other open source technologies, is very meritocratic. There is very definitely some level of hierarchy, not everyone is a co-maintainer of core. Talent and ability are important and are a huge part of what drives the technology forward. But the fact that I got thanks from one of the major core maintainers demonstrates something else. That isn’t to say that I don’t have any talent or ability, but I am relatively new to this whole world and at the moment I don’t have the ability and comprehension of others.
What I have is an urge to put a little bit of an effort in taking what I do know and taking a little bit of time to help and contribute back. And a big part of why I have that urge is that the people involved in Drupal seem to at least have a real appreciation for any time that I put in. I have to say that this is unusual and special part of this community.
Having been involved in music (mostly classical) for the majority of my life, I can say that this is not the case at all. Behind a lot of good amateur ensembles there are people that put in a lot of effort in organising. But when it comes to the performing, people aren’t really there to pat you on the back for trying hard if they don’t think you are performing to a standard they would like to listen to. I’m not an idiot (well not all the time), I know that there are lots of very rational reasons for why the two are very far apart and if I were to make a comparison with sporting activities, not having any ability is a real problem.
However that doesn’t stop the fact that alongside all the other things that are great about the Drupal community it really is a community that appreciates effort.DevelopmentTeaser: Alasdair writes about how great it is to be working in the Drupal communityCategories: CommentDevelopmentDrupal NewsDrupal PlanetPrimary Category: Comment
WARNING, this module is not yet stable! Do not use it!
Honeywords is a module that will generate fake passwords ("honeywords") for
every user on the site. The main use of this module is to make it harder for
an attacker to penetrate your site without being detected (and notifying you
of data leaks that may otherwise have gone unnoticed). It has the side benefit
of making the password database generally less useful for hackers targetting
Honeywords is an attempt at implementing the Juels-Rivest MIT paper:
To be clear, of the many attack scenarios listed in the paper, this module
(and this concept) only addresses a "Stolen [list] of password hashes" scenario.
There are other modules to help you implement security policies addressing the
others. Preventing data leaks in the first place is of course more important,
but damage control should be a part of any responsible security policy.
A lot of things can diminish or nullify the usefulness of this module. See the README
file for details.
- Content (view modes, fields)
via Ajax, using
Midwestern Mac, LLC: Moving Server Check.in functionality to Node.js increased per-server capacity by 100x
Just posted a new blog post to the Server Check.in blog: Moving functionality to Node.js increased per-server capacity by 100x. Here's a snippet from the post:
One feature that we just finished deploying is a small Node.js application that runs in tandem with Drupal to allow for an incredibly large number of servers and websites to be checked in a fraction of the time that we were checking them using only PHP, cron, and Drupal's Queue API.
If you need to do some potentially slow tasks very often, and they're either network or IO-bound, consider moving those tasks away from Drupal/PHP to a Node.js app. Your server and your overloaded queue will thank you!
This module provides a field group for use on entity displays, which "implodes" all of its contained fields into one. Most common use is to display two fields on the same line, such as in the case of first name / last name. You can control the "glue" which is used to connect the fields (eg, a space, a semi-colon, the word "and", etc.). It can also be used to do the same to all members of a multi-value field. And yes, you can have nested implosions. :)
This module depends on the Field Group module.
ArenaNet is currently developing an API to expose game data from their Guild Wars 2 game. This module will provide integration for displaying game data on a Drupal website.
More information about the API is available at https://forum-en.guildwars2.com/forum/community/api/API-Documentation/fi...
The UCSF Drupal Web Starter Kit project has been our most successful university project to date. It has empowered UCSF to roll out sites for small departments, offices, and researchers in a matter of minutes.
Just 3 months after launch, 70 sites have gone live.
"This fills a tremendous need at UCSF. We're very happy with it."
– Lisa Magargal, UCSF
Here are a few examples of sites leveraging the Drupal Web Starter Kit:
UCSF has hundreds of small web properties for offices, researchers and small departments who don’t have the budgets and resources to create custom websites. Historically these groups have been left to their own devices to cobble together sites by whatever means necessary. These sites grow quickly out of date, are hard to maintain and rarely adhere to UCSF brand guidelines.
UCSF created an initiative to build a Drupal install profile that they could offer to these groups at minimal cost and effort. UCSF turned to Chapter Three to design and build this solution.The solution
A flexible information architecture
Because this web solution had to work for small departments, offices, and researchers, we needed to find some common ground in how the sites were structured, while still providing enough flexibility for end users to modify the site’s structure to fit their needs.
We began by creating menu structure consisting of “Home, About, News, Events, Publications, Services and People”. We arrived at this list after careful research of the commonalities across sites for the three key audiences. This meant that when a new website was created, the new client would have a primary navigation menu which was already created. They could then add items to the menu as needed, customizing it to fit their specific needs.
We also created specific content types for News & Events. Events were structured so that they could show upcoming and past. Over time it is our goal to extend the project to create structure around more content including Publications and People.
Three different palettes
We collaborated with UCSF’s brand specialist to ensure that our designs were approved at the highest level to properly represent the look and feel of the University. We delivered three different color palettes of the template so that end users could pick the color scheme they liked most for their site.
Robust content display options
To empower the admins to have more control of the key content regions, we designed a WISYWIG editor with the power to do far more than add text, links and images. All project administrators can add:
- vertical tabs
- tool tips
Additionally, special care was taken to ensure that the back end system could be easily controlled by individuals who self identified as “non-technical” people.
Responsive design framework
The future is device agnostic. As screen sizes multiply by the day, we knew that delivering a fully responsive site was paramount for the long term success of this project. We accounted for this with a fully responsive solution which provides legible content on any device interface. Since this solution was meant for hundreds of groups at UCSF, accounting for the long term viability of the website was fundamental to it’s success.
We appreciate the opportunity to work with an amazing client like UCSF. The project has been a resounding success for all involved. We look forward to building on this framework long into the future to better equip UCSF's groups with the tools they need to do their jobs.
Allows you to upload files using HTML5, Gears, Silverlight, Flash, BrowserPlus or normal forms, providing some unique features such as upload progress, bulk upload, drag-drop upload option and chunked uploads.
It can be assigned to file field as a widget and supports any file extension which can be set from file field settings.