Planet Drupal

It seems relatively easy (ie. zero configuration) to get PHPstorm and Xdebug up and running together, so I will presume you have that going. It often happens that you want a breakpoint in a frequently called function. Just putting one will make the system stop there every time. After a right click, Edit you can add conditions to it which help. Even better, you can add a breakpoint to somewhere else, remove the suspend checkbox from it and make the first breakpoint disabled until the second is hit. This allowed me for example to break in drupal_flush_all_caches only when fired from WebTestBase::resetAll.

This is the second part of our series on how to create a question and answer website in Drupal. In this screencast we would be looking at how we can allow users to insert code snippets in the answers they are providing. Say for example it is a question and answer website for a programming language, we would like codes provided in the answers to be well formatted. In other to achieve this, we will be making use of three modules 

• WYSIWYG
• Syntax Highlighter
• Syntax Highlighter Insert

We would be using the ckeditor alongside WYSIWYG for client side editing. The syntax highlighter module allows for source code syntax highlighting while the syntax highlighter insert allows syntaxhighlighter tags to be used within textareas.

NOTE:

When you have downloaded the syntax highlighter insert module into your sites/all/modules folder and you try installing it, you will notice the modules list page does not load or it gives an error. All you need to do is open the syntaxhighlighter_insert.INFO file and remove the quotes around name, description, etc.

The syntax highlighter might not work with filtered HTML, so use the FULL HTML text format.

I recently began working on some PHP code for resolving HTML5 entities into their Unicode codepoints. According to the code, it had been optimized for performance. The code was moderately complex, and the authors appeared to have gone through great pains to build a specialized lookup algorithm. But when I took a closer look, I doubted. I decided to compare the "optimized" version with what I would call a naive version -- the simplest solution to the problem.

Here I show the two solutions, and then benchmark them for both memory and speed.

read more

Up front, I want to state that I am not poking fun at or deriding the original authors. Their solution has merits, and in a compiled language it might actually be a faster implementation. But to optimize for PHP requires both an understanding of the language and an appreciation for opcode-based interpretation.

The Code: HTML5 Character Reference Resolving

read more

Application programming interfaces (API’s) are proliferating across the Internet, becoming the standard format by which information is traded.

ProgrammableWeb.com keeps count of new and existing API’s, currently cataloging around 8,900 and growing. 

For those that don’t know really know what an API is, it’s simply an interface (not a graphical user interface) that allows a websites to send to data to-and-from other third party systems or websites. When you’re viewing a news feed or writing a Facebook comment on a site other than Facebook, an API is moving that data across the Internet behind the scenes.

Drupal Language English Gem from the PhilippinesJohn Heaven04/25/2013 - 17:02

Hamburg isn't alone in putting on a Drupal user group once per month. Across the world, there are 456 user groups registered on Drupal.org. I did a quick interview with Gem, organiser of the Philippine Drupal User Group and here's what she said ...

15 paid orders per minute = 150 orders in the first 10 minutes.

On Saturday, March 9, 2013, we opened up online registration. In the lead-up to the event, there was a lot of online excitement and build up leading up to registration. The past events (in 2011 and 2012) had all gone extremely well but there been some difficulties with the online registration process.

When we activated registration at noon, the fans were ready, and within the first 10 minutes, we took in over 150 paid orders. In rapid succession, we managed to book all 100 of our author slots and another 50 of the general registrations slots. The rest of the weekend would see another 100 or so registrations.

Most importantly there were no major distasters and the money reached our transaction account (Stripe). The site was built with Drupal Commerce and Entity Registration) on top of the Panopoly distribution).

Use Case: A yearly reader/writer conference

GayRomLit Retreat is a yearly reader/writer conference between fans of the LGBT romance fiction. In their tagline, they describe it as a "gathering that you simply cannot miss." And clearly with the fervor and rapidity in which registration took place, people were more than willing to pay to get their ticket to the event.

In December 2012, the event organizers decided to relaunch their web presence on Drupal.

In this case study, I'll talk about the specific use case and how this site was built using Panopoly, Drupal Commerce and Entity Registration to fulfill all the main needs of any basic paid event site (online registration, payment integration, paid sponsorship, etc.). I'll detail some of the customizations used to solve the specific needs of GRL Retreat. There were also several performance and payment integration choices that allowed us to take in over a hundred paid transactions in such a short span of time.

Finally, I'll also reference various pieces of code that have been shared on drupal.org and github.com and talk briefly about the upcoming "Panopoly for Events" distribution.

(NOTE: This is a bit of a long post, so if you are a Drupal person looking to get to the techical, how-it-was-built details, skip to the section on "Starting Positions: Panopoly Distro and Drupal Commerce")

The Backstory on GRL Retreat

GayRomLit (GRL) is an annual con with an enthusiastic, devoted fanbase focused on LGBT romance fiction. Each year, the event moves to a new city, and because registrants fly in from all over the world, an online presence is pivotal. After two extremely successful events, GRL 2013 needed to overhaul its web presence and take control of both its informational presentations and its online registration and paid transactions.

In its inaugural year, GRL handled registration and attendee information manually using PayPal transactions and spreadsheets of data to process hundreds of registrants. For year two, GRL opted for the RegOnline service which turned out to be expensive, buggy, and fraught with problems. In the first two years, the organizers and attendees struggled to track transactions, customization, and scheduling data.

In an industry in which multiple pen-names can complicate questions of payment and identity, there was a recognition of the need for a solution that gathered all the data and commerce under a single purpose-built umbrella.

In December of 2012, knowing that they had a customer base that would support real infrastructure, GRL prepared a detailed Request for proposal (RFP) and submitted it to 12 different web developers asking for proposals and bids.

We at Int3c.com were one of them. Our proposal focused on flexing Drupal’s opensource functionality in a unified site that would act as the public face and private backend storage system--processing registrations, taking payments, and featuring the authors and publishers who are the lifeblood of the event. In January 2013, initial development started in developing a conference registration site with Drupal Commerce.

Tecnology Choices: Why not COD?

There are multiple distributions in Drupal that signicantly decrease development time on many common, use-case websites. One of the most famous is COD (Conference Organizing Distribution). It's used several times a year to put on Drupal Conferences and non-Drupal events.

In Drupal 6, I have used COD on multiple events/conference sites. It's a great starting position for setting up event registration and getting paid sponsors. While it's not perfect, it provides the key configurations to get you close to most of the main needs of a conference site.

Drupal 7 also has version of COD. Unfortunately, at the time of initial development (January 2013), I didn't feel like COD provided such a great starting position. Sure, it provided all the basic modules but it was still pretty rough from an initial content and site builder perspective. Also while an architecture around groups using Organic Groups (OG) modules is useful in some situations, I didn't feel like the overhead, extra training for admins, and potential integration bugs made using OG module a good choice for us.

Instead, I took all of the underlying modules (especially Registration and Drupal Commerce, and Drupal Commerce Registraiton) and general structuring and added it to Panopoly, which I consider to be one of the best "site builder" and "content creator" distributions in Drupal 7.

While Panopoly also requires a certain amount of training and orientation, once editors understand it, they have been able to make many of the pages customizations themselves.

Starting Positions: Panopoly Distro and Drupal Commerce

One of the key advantages of Drupal over other CMSs (open source or even enterprise) is its starting position. Drupal is an extremely modular (think: building blocks) system, where you are able to pull in a ton of functionality via different modules. Since Drupal aims at the general need, the basic process of building most Drupal sites involves assembling your main modules, then building and customizing the specifics for the project.

Drupal's starting position has also improved with the creation of better and better distributions. While they are technically termed "install profiles," meaning during intial installation you get a kind of site, Drupal distributions go beyond just initial installation. They create and configure a ton of things that might take days or weeks to set up manually. Distributions also refine the "vanilla" Drupal experience into a set up to improve the user experience for a particular need.

Some of the most useful Drupal Distributions include OpenAtrium (intranet), Drupal Commons (social community site), Commerce Kickstart (ecommerce sales site), OpenPublic (newspaper, publication-in-a-box) and OpenChurch among many others.

Panopoly is a distribution that is a bit different than those listed above. Specifically, Panopoly doesn't really intend to provide a solution for a particular use case but as they put on their project page, "the distribution is designed to be both a general foundation for site building and a base framework upon which to build other Drupal distributions."

Some of the improvements Panopoly brings to the table are mobile/responsive look, UI/UX improvements for content creation, and a system for allowing site builders to add flexible layouts and customized page elements anywhere they need.

One of the disadvantages of Panopoly is that it is structured around panels/page and doesn't use Drupal's "blocks" system. This means many contrib and other modules need to be adapted to work well with Panopoly.

In my opinion, COD in Drupal 7 had all of the general modules I needed, but not much else. So instead of building out content creation stuff from COD, I'd add the ecommerce and events management elements onto Panopoly. In this way, I'd get the content creation and general styles from Panopoly and still have the core needs of a paid events system.

Panopoly for Events: Building an Events Registration Site with Drupal

With GayRomLit.com I aimed to not only solve many of their conference site needs but also hopefully create code that could be shared back, so others could solve their conference site needs.

Anyways, for lack of a more exciting title, I've been calling it: "Panopoly for Events". As you can imagine, it aims at using Panopoly as the base system and combining various features for an events/conference system.

(Side note: I am in the slow processs of building a distro called Panopoly for Events, which will take the various improvements we added to GayRomLit.com's site and generalize them for everyone. It will be magical and hopefully save you lots of time. If you want this happen sooner, harrass me in the issue queue or contact me in github demanding the latest code. Or even better yet, contact me directly with a specific project (or funding!) to help it happen sooner.)

Panopoly for Events: Paid Events Registration

Like most conference sites, the list of features needed were not surprising:

• a paid registration system for different pricing and ticketing
• various presentation pages about the hotel, venue and other things
• FAQ pages to answer the most common questions
• a schedule of the event

Beyond this we needed to consider how site admins were going to manage various site functions and present the key areas in the most easily understandable manner. If you are not careful, a complicated site might be not be easily managed by the clients you are intending to help.

Let's look at some of the features created and used on this site as well as reference the on-going work on drupal.org.

Panopoly for Events: Paid Events Registration

As I said before, while COD had the many of the relevant underlying modules, the actual implementation (via OG) didn't allow for simple plug-and-play with those modules. So, instead I took the basic structure and reproduced it for Panopoly.

The first was a simple registration content type called Event. This allows for the creation of non-paid registration. This feature has been shared on drupal.org as Panopoly Event. We don't use "free event" registration on our site but it provided the initial structuring via Registration module.

For us, we needed paid event registration and this was handled via Panopoly Paid Event. This feature adds a significant number of supporting modules from Drupal Commerce and most importantly provides a paid product integration during the creation of an event. We provided a checkbox to indicate if it was a "paid event," which using conditional fields, then provided a way to reference or create a paid event product. In this way, users could click "add to cart" and after paying and completing their checkout, a registration entity would be added to the event.

Due to the nature of the event, we created several separate registrations (for authors and for general registrations). This way we could limit the number of types of registrations and provide a way to contact the relevant groups afterwards for certain followup actions.

Since we knew we'd likely fill up the slots very quickly, we knew that we'd need to provide a waiting list for post-registration. Essentially once a product is sold out, we reveal a "flag" for "add me to the waitlist." Certain additional customizations using flag fields were added for promoting users off of the waitlist and providing a custom url for registration. The code for this is currently under development as DC Registration Waitlist

Due to the flexibility of Panopoly layouts via Panelizer, we were able to create a basic look for registration events and then customize it with additional panels of information. In this way, we created both a clear display of relevant actions and links to additional information as needed for users.

Beyond this, we were able to use Rules integration to assign relevant user roles upon checkout of specific products. This allows us to show relevant information and FAQ in the user's dashboard.

Panopoly for Events: Paid Sponsorship and Sponsorship Management

For almost any conference, the sponsors are one of the most important parts of it. They provide additional funding in exchange for getting promoted and some marketing.

Since the site was using Drupal Commerce, it was relatively easy to create additional products and product display pages for sponsorship and various promotional products.

For the sponsors, we created a custom checkout step that allowed users to create and submit their sponsor page like a normal node creation. They could select a title, write a description and upload their logo, which upon checkout would get submitted as an unpublished node page. These nodes also contained a private field for the sponsorship level, which would be set according to the type of product bought or editing by admin separately. We also created a management page using VBO views module so that these unpublished nodes could be controlled accordingly and published in bulk.

Most importantly we were able to create a promotional page for each sponsor as well as promote are key sponsors on the homepage. Remember: Don't forget to give as much credit to your sponsors as you can.

One additional unique situation we had was post-registration promotional products. These were products that only certain roles could buy. Basically, this meant that a user needed to have previously registered as an author to be able to buy certain other products afterwards.

While the Drupal Commerce provides a nice API for managing the display of the add-to-cart, it wasn't easily controlled from the front-end by the editors. So instead we used content access control to handle this on a node by node level. An additional field was added to the product display which control the page access.

Author Profiles and Listings via Profile2 module

Since GayRomLit is largely an author and publisher driven event, it was important to give these users a way to promote themselves and their work. Using Profile2 we created a custom user profiles for authors so they had separate fields to provide their headshot, description, links to their social profiles and their latest publications and references to their publishers.

Because many authors in this field write under a pseudonym or pen name, it was important provide a few clear designators during checkout to collect their private billing info and name and indicate their badge name. Using an additional profile space allowed us to keep information more organized too.

User Dashboard via Panels and Page Modules

Due to the various follow up tasks for some roles and need to provide role-specific announcements, it was decided to provide a dashboard for users. Since the site used Panels extensively already, it made sense to use Panel and Page modules.

Since by default users' profiles were private (for various reasons), we decided to override the default user profile and to create a specific dashboard. We used Panel's "visibility settings" to provide the relevant info for different users.

Follow Up Tasks and TODOs

While this feature is not currently being used yet, we created a special announcements system and calendar for users. According to field settings on a special content types, admin could designate which roles and/or which specific users would see these announcements, TODO items or news in their calendar and dashboard.

We used the Node access user reference and Taxonomy Access Control modules on this content type to create the relevant access controls.

In this way, it was flexible enough to get the right info for the right users without crowding all of the info to all users.

Event Scheduling

Finally, at the heart of any conference is the event scheduling. Currently for promotional purposes we are using a single page to create this manually. We are currently at work on creating a dynamic schedule control feature, including the ability to submit and manage session proposals and subsequently use drag-and-drop to organize the places and times of individuals. We hope to have more on this feature soon.

Conclusion: Future Dev on Panopoly for Events

Drupal is an incredibly powerful system for building almost any type of web applications. The basic core architecture is stable yet flexible and subsequent modules allow you to build additional functionality. Furthermore, Drupal Commerce is one of the most incredible E-commerce platforms in the last several years. It works smoothly for standard buying and selling sites and can be highly customized for all kinds of unique situations.

Hopefully from this case study, you can see the importance of pulling the most important features you need from relevant modules and combining them on top of the best starting position for your project via a distribution. In our case, Panopoly proved to be the best choice.

In addition, we were fortunate to have a client that understood the importance of open source software and has allowed us to share back numerous fixes and several new modules. Some of the contributions include the following:

• Free Event Registration for Panopoly
• Paid Event Registration for Panopoly
• Panopoly Sponsors
• Paid Sponsorship
• Panopoly FAQ
• DC Registration Waitlist

We're also working on an Event Session Scheduler and a Proposal-to-Session Publication Workflow.

All of these features we hope to combine soon into a new, open source Panopoly distribution Panopoly for Events.

Along with this free distribution, we are working towards creating a paid hosting and service platform called MyEventSite.co.

Coming Soon: MyEventSite, a Drupal Open Source Platform for your next event

MyEventSite will combine all of the features you need to launch an event, like paid registration and paid sponsorship. We'll handle the biggest headaches of security and payment integration. It'll have all the features you'll need, and since it's built on Drupal, you can customize it to meet your specific needs.

There are number of great event platforms out there, like EventBrite or even using Google or Facebook, but all of these lack the flexibility and ownership that many conferences need.

We want to be a full service, open source platform for launching events, while at the same time, giving you the freedom of mind that you can take your data and your code elsewhere if need be.

Interested? Sign up at MyEventSite.co to get the latest announcements or contact us directly at Int3c.com/Contact to know more.

Tags: drupalRegistrationCommerceDrupal CommerceCase StudyMyEventSiteDrupal PlanetPlanet Drupal

• var switchTo5x=true;stLight.options({publisher:'dr-8d62520e-c444-86e2-d911-ab27da97627b'});

Sometimes when we use third party libraries (for example Symfony components) we need to take care about class auto-loading. When the files number is small we can add them to our module's .info file. But what if the files number is big?

Lately, I was working with the Guzzle Module and discovered a very nice way to provide information to Composer Autoload about folder with your classes files.

After installing the Guzzle module we have a new autoloader (ClassLoader). In order to use it in our custom module (in my case http://drupal.org/project/services_guzzle) we need to place the autoload.php file to the folder that's going to have files with classes. The code of this file is similar to <?php $loader = new \Composer\Autoload\ClassLoader(); // Register classes with namespaces. $loader->add('DrupalServices', __DIR__); // Activate the autoloader. $loader->register(); ?>

This code registers the prefix 'DrupalServices' and maps it to the folder where autoload.php file is located. So the next time we will see in code the usage of $client = \DrupalServices\DrupalServicesClient::factory($config); or something similar to ClassLoader, we will know where to look for files with classes.

Technically what happens is composer_autoload module scans for autoload.php files and includes them on hook_init(). As it caches where the files are. Please remember to clear caches after you add the new autoload.php file anywhere.

Language English Tags: DrupalDevelopmentTutorialsCheck this option to include this post in Planet Drupal aggregator: planet

We are very proud today to be launching our alpha product release of Open Atrium on Drupal 7. This project has been in development for more than six months, and has certainly been anticipated, planned, and requested long before that!

How Was it Built?

Over the course of the project, the Open Atrium team mantra has been: “proudly invented elsewhere.” Most Drupal community members know that Open Atrium was originally conceived of and built by the talented team at Development Seed to achieve an “intranet in a box,” combining discussions, notifications, issue tracking, and calendars in a first-of-its-kind open source solution.

So when it was time for an upgrade to Drupal 7, the goal was for Open Atrium 2.0 (OA2) to represent the “best of Drupal,” combining the top thinking in the community about how to handle flexible layouts, best-in-class security and permissions, and beautiful, responsive, usable design. Open Atrium Alpha is proud to be built on the Panopoly base distribution, utilizing the Organic Groups and Messaging API modules, and using Radix, a Bootstrap-based theme. Basing Atrium’s functionality on work that is “proudly invented elsewhere” meant that our team could focus on combining this functionality into a truly powerful platform, creating a flexible framework for plugins, and making it easy to use.

What’s In It?

Open Atrium consists of several core features that are key to creating a social collaboration software solution for organizations needing to share knowledge and connect their teams. The core features included are:

Discussions, Notifications, & Messaging

Discussions in Open Atrium can be restricted to as few as two people or opened up to the whole organization, and can be restricted based on a user’s projects, teams, or organization membership. Users can subscribe to specific discussions and communicate through the email notifications feature, allowing teams to stay better in touch with the information that matters most.

Knowledge Management

For organizations building intranets, wikis, and knowledge management sites, Open Atrium allows for the simple storage and sharing of documents and media within groups or to the global organization. Open Atrium comes standard with full Media support and the ability to attach and store files, images, and video with documents assigned to specific discussions and groups.

Security & Access Control

Open Atrium features robust access control that outperforms any other open source solution by providing administrators full control over access for individuals, project teams, and organizations. Content created within a project can be restricted to sub-sets of the project team; Information can be shared globally or to restricted groups; and communications can take place among larger communities or highly classified teams.  Attached media and file documents can be made private to specific groups and teams.

Mobile Ready

Open Atrium’s theme is built using Bootstrap, a front-end framework using responsive CSS that allows content to be ready for multiple screen sizes out of the box. Over two dozen cross-browser, responsive layouts and several responsive image styles are included to aid in site building and allow your site to work seamlessly on mobile devices.

Customizable Layout

Open Atrium is built on Panopoly, a Drupal Panels-based distribution that offers drag-and-drop customization of pages and content. Easily switch layouts, change styles, and add generic widgets to display text, images, links, maps, submenus, video and spotlights across your Atrium site.

Pluggable Functionality:

Open Atrium is built with extension in mind. Custom functionality is added via plugins, keeping the core platform lean and light, while allowing users to add the specific functionality they need and not be burdened by unnecessary features.  Open Atrium 2 comes with the Discussion and Wiki plugins, but they can be easily removed and other community-developed plugins can be easily added.  Developing custom plugins well-documented and is no harder than building a normal Drupal module.

What Is “Alpha”? 

At Phase2, we consider an Alpha release to be “developers’ code.” The architecture for the product is well-defined, and the supporting functionality for the product is all built. But it is not a fully developed product. It is not free of bugs, and it isn’t ready for someone who is not a Drupal developer to start building with and using. For Drupal developers interested in evaluating it for projects, building plugins or additional functionality, OA2 Alpha is a great place to start. We hope you’ll help us identify bugs and report them to the issue queue and help build plugins and functionality that allow the community to extend Open Atrium’s capabilities.

For organizations who are eager to start using Open Atrium “out  of the box” but do not have an experienced Drupal team on-hand, we would recommend that you consider working with a Drupal developer to do so, or wait until a Beta product is released before evaluating it on your own. We are working hard to make it easy for organizations to get started quickly with Open Atrium, and we’ll keep you updated as soon as we have more opportunities for evaluating, demoing, and using Atrium. To join our mailing list for Open Atrium (no spam, ever!), please drop us a line and we’ll keep you updated.

Can I Update My OPEN Atrium 1.X Site to THE 2.0 Alpha?

Like any Drupal 6 site, there is no simple upgrade path from Open Atrium 1.x to Open Atrium 2.x. This is due to the different architectures of Drupal 7 versus Drupal 6.

So, what’s next? 

In the coming weeks and months we’ll be building some additional plugins and functionality into Open Atrium 2, evaluating the patches and contributions from the community, and helping community members build new plugin features. There are teams in the community working on document management and case tracking functionality as we speak, and we are excited to see what other plugins emerge.

Can I Help?

Absolutely!  First off, the issue queue is open. Download Open Atrium, evaluate it, and let us know what you find. We’ll be pleased to review patches from willing community members. We are also in the IRC #open_atrium room, so please join us there for more conversations on Open Atrium as well.

Second, we have a group of community members who meet and talk regularly about contributing to Open Atrium and making it better. If you’re interested in joining our contributors group, please join the groups.drupal.org group, or email us at openatrium@phase2technology.com to be added to our contributors list. I also give a “Developers Demo of Atrium” webinar every Friday at 11:00 am ET. To sign up for this week’s demo, please click here.

Third, we’ll be hosting an all-day hackathon at DrupalCon Portland on Friday, May 24th at the DoubleTree hotel. If you’re interested in developing plugins or discussing Open Atrium, we hope you’ll join us there.

Finally, we want to give thanks and appreciation to the contributors group, including awesome community members like Matt Cheney and the team behind Panopoly; Antonio De Marco and Andrea Pescetti from Nuvole; Amitai Burstein from Gizra; and David Snopek and Pancho; who have contributed their code, their testing time, and their patches to help make Open Atrium a great product.

When I told Mark Carver that I was compiling a list of responsive themes for D7, he rolled his eyes and shook his head at me. While Product Owners (and some clients) may be seduced by the perceived ease of a pre-built theme, experienced themers know better.

Mark eagerly pointed out to me, “just because it looks good, doesn’t mean it works. Pre-built themes are difficult to implement if you have any building standards at all,” I laughed to myself, having learned this lesson in my early 20’s. ... Read more

Most companies are on an eternal search for ideal employees. There are plenty of good Drupal developers out there, but what sets the really great ones apart from the rest?

When hiring an employee for any ICT job the most important consideration is pretty much always the same set of basics: good communication skills, cultural fit, ability to take initiative, being smart, and so on, are always important fundamentals. However there are also some rather specific skills for Drupal developers.

Drupal by it's very nature is a highly productive platform for building web sites. This limits the amount of development work required and also increases the amount of non-development tasks in any project. This may be largely Drupal specific today, but most development platforms are heading to the same direction of increased productivity. The traditional method of designing everything first and then implementing simply does not work for Drupal. It is possible and does provide results, but it means you don't get any real benefit out of using Drupal. Actually Drupal may end up just being in the way and result into lower productivity than just manually coding on a framework.

The nature of Drupal means we can use much smaller, highly productive, teams of 2-4 people in projects. Each team member has a larger role than a traditional developer. This means a great Drupal developer should be multi-talented. Developers should have skills in backend development, frontend development, user experience design, graphical design, service design and so on. Extensive experience in best practices of the vertical business is also always a great thing. Naturally nobody will be great at all of these areas, but a good developer should be proficient in 3-4 different ones; a great one at more than 4.

Because implementing features with Drupal is so fast, a great developer should also understand the end user of the site being built. If you can understand the end user, you can also easily consider different solutions for a business problem using your knowledge of the massive amount of Drupal modules. Offering alternative solutions to the product owner can lead to vastly improved efficiency when existing functionality is used instead of creating custom functionality.

Ideally the developer would also physically meet with the product owner at least fortnightly. Higher quality communication means much better understanding of customer needs. Online communication is an okay daily tool, but there really is no substitute for face-to-face meetings. Spending time physically at the customer organization will also typically reveal tacit knowledge from more informal coffee room discussions which you would never have in an online conference. Spending time with the customer and end users of the site will also improve your understanding of what is really required and make it even easier for a developer to propose great solutions for business requirements.

Everything that makes a Drupal developer really great also makes the same developer a great member of an agile team. Efficient agile with Drupal actually assumes you have great Drupal developers in your team. If the team is full of developers just doing what they are told by architects or project managers, you can't do agile, or efficient Drupal for that matter.

Disclaimer: My definition of Drupal developer in this case is someone who builds sites for a customer or a member of an inhouse team. The skillset for developing, for example, Drupal core could be slightly different - it's more traditional software development.

In the 7 Drupal video tutorial in this 10 part series, I show you how to configure the LESS CSS Dynamic Stylesheet Language for Drupal sites. We again build off our existing subtheme and doing so requires the Drupal LESS module. After we have the module configured and running (which includes editing our .info file), I walk you through LESS mixins, variables, functions and nesting. LESS is an amazing tool and something I definitely recommend you use for your projects! You can now purchase the entire series on advanced e-commerce sites with Drupal 7 and Ubercart before all tutorials are released. How to Use LESS CSS Dynamic Stylesheet Language with Drupal 7 - Advanced Ubercart Sites #7Drupal Planet: Drupal PlanetVideo: UbercartDrupal 7LESS

In the 7 Drupal video tutorial in this 10 part series, I show you how to configure the LESS CSS Dynamic Stylesheet Language for Drupal sites. We again build off our existing subtheme and doing so requires the Drupal LESS module. After we have the module configured and running (which includes editing our .info file), I walk you through LESS mixins, variables, functions and nesting. LESS is an amazing tool and something I definitely recommend you use for your projects! You can now purchase the entire series on advanced e-commerce sites with Drupal 7 and Ubercart before all tutorials are released.

Twitter cards are a great way to give tweets a media experience, enabling you to add images, summaries, videos or even detailed product information to a tweet. You can add Twitter cards to your Drupal site easily with the Meta Tags module.

Slideshow is one of the most essential part of a website. It is basically the first thing that attracts your eyes when you visit a website. It is large enough and it has many cool transition effects that you can't help take a look at it. Having a long time working with Drupal, I collect and present in this article some of the best Drupal slideshow modules.

There are alot of Drupal slideshow modules, however, I only pick the modules which are in high usage, under active development and support Drupal 7. I downloaded and tested them all to see what are pros and cons of each module.

Now these are 12 best Drupal slideshow modules in my opinion: 

read more

The Client-side adaptive image module allows you to display responsive images from a field formatter. The module resizes images via JavaScript on the client-side, hence the name.

This module is relatively easy to setup, there are no dependencies and you don't have to modify the .htaccess file. To setup just select the "Adaptive image" formatter from the manage fields page, define your breakpoints and you're done.

DrupalEasy is considering offering half- and/or full-day workshops at future Drupal Camps and we'd like your opinion on what types of workshops you'd be most interested in attending.

Please complete this short survey to help us determine what types of workshops you'd be most interested in attending.

Thank you!

We will be starting a new series on how we can build a question and answer website similar to any of the stack exchange website using the drupal CMS. The question and answer website will have features such as users being able to vote on questions and answers. User who created a particular question deciding which answer is the best answer, users will also be able to add code snippets in there answer which are properly formatted. Users get points for there answers been voted up or down.

In the first part of this series, we will be using the answers module as the foundation for starting our site. Upon installing the answers module, two content types are created. The question content type used for posting questions and the answer content type used in answering questions. This module also comes with default views pages already created for us such as all questions view page, unaswered questions, search for questions.The view also show how many answers have been provided per question.

In this tutorial we simulated the question and answer website using two users. One user asks a question and the other answers the question. Users are also able to view profiles of users on the website to view how many questions they have asked, answered, and how many points they have. 

We also looked at setting the right permission levels for different users of our question and answer website.

 

The Phone Rings,

Client: We have a website and database we need to migrate to Drupal.

Me: How big is the database?

Client: Huge!

Moving to a new platform means moving the database. Where does the platform "live?" Do you own the space, or are you a renter? What's the cost of moving? It ain't cheap. The Managerial Evaluation

Your website has been a commercial success ever since you upgraded some years ago. Revenues are strong. Traffic is up. The bottom line is solid. The database has expanded in proportion.

The staff that keeps the site working have wrung out everything they can. They are grumbling, at least a little, about how the site does not do what they want it to do. They've created some work arounds to address that, but it is not ideal.

Your visitors are happy, but they are telling you that they want performance: more data, more pictures, more speed, more raw power, and it seems your competitors have heard about these desires because they have re-launched their sites, and you are concerned that though your key performance indicators (KPIs) look solid, you don't know how much the competitors are siphoning from you.

To stay fresh, you are considering a move up-market as the competition ups the ante.

This means moving from old platforms to new platforms. It means being able to jack into the old database and then to migrate it.

It means direct costs and hidden costs have to be addressed before taking on the challenge.

Moving a database to a new platform is not as simple as moving old wine to new bottles.

No matter how much we would want it to be, it is not merely pouring old wine into new bottles. Like Y2K, once you penetrate the top layer, you enter a labyrinth of long forgotten workflows – geological layers of code if you will — consisting of workarounds, kludges, on-the-fly "fixes" (or worse yet, fix-attempts) that were suppose to postpone the inevitable – a wholesale site upgrade.

To be sure with backups and redundancies, the content of a firm's codebase and database is stored somewhere. It can be restored.

Restoring the codebase is one thing, but moving it from one software platform to operate on another is not trivial. It is not just old wine into new bottles.

No Data Migration Project Is Simple.

Yes, there are tools. Yes, we've come a long way. Yes, everyone is onboard to make it work.

And yet retrieving the database repositories demands something both scientific discipline and the artistic insight — the stuff of jet fighter pilots.

"When done right, it looks like the easiest things in the world," says one of the Blue Angels aviators. He goes on to say: what is required is "total and utter concentration to the exclusion of all else."

Some people may say, database migration isn't rocket science. But to trivialize the process risks being blindsided.

If moving from software platform A to software platform B could be done without disturbing the database, the job of moving to a better platform would be relatively easy and it could be done in short order by a canned program ("wizard") or by rote.

When an organization needs to modernize its website, it inevitably requires migrating the existing database and making it comprehensible to the new website's software.

Database Folklore.

The database encapsulates everything that has gone before — good and bad and in-between. Clients are tempted to say, and service companies are ready to believe that migration will be quick, simple, and painless. But all too often, these prove to be myths.

Japanese Tea Ceremony -- to a client, the new workflow might be seen as something that takes away a vital element. This is not always immediately apparent except to those who have responsibility for the day-to-day operation Myth One — New Websites Won't Be Reverse-Engineered.

In other words, there is little or no retraining cost — direct or indirect. Phrases like, "everyone's on board," or "they can't wait to get away from the old way" are reported by the IT or Website Department, yet these statements are not always completely accurate.

The people (web staff) currently doing the day-to-day work understand the workflows. The workflows are inextricably linked to the database and how the data is stored and retrieved. The interface that the web staff employs is a direct outgrowth of how the database is called up and how it is formatted for consumption.

New Workflow - using the tea bag might be faster and more efficient, but if not everyone is on board with a new workflow, there will be surprises at launch

The workflow has a logic, but it is not always logical.

A good deal of institutional knowledge, cost, and investment in web staff training is in place. Sometimes it is hard to get the staff to address what they like about the existing site and interface. Flush with the idea that a new site will "solve everything," not enough time is spent in setting down the existing workflow and addressing what would happen if that workflow changed.

Our firm's approach is to place an "embedded" information architect or user experience person at the client site to interface with the staff to understand what their jobs entail and what these individuals are tasked to do with the existing site.

Clients often want to skip this, hoping the new site will sweep away everything that came before, but this can leave parts of the client's firm feeling that the baby has been thrown out with the bath water.

Why is no-reverse-engineering such an elusive goal?

Too many stakeholders — customers, staff, managers, you name it — see the existing workflow as having been handed down on stone tablets.

Like the Japanese tea ceremony, each step is seen as beautiful, necessary, and prized, or at least familiar, known, and comfortable.

At the beginning of a project involving an existing database, we are told that the task will be: straightforward, not complicated, requires only minor tweaks, and needs no "major" work.

There is a cost that often is not appreciated until the alpha phase.

Myth Two — Out-Of-The-Box Drupal Is All That's Required.
Home Depot has an out-of-the-box solution for painting a ceiling, and if that's what's wanted, it is probably the right way to go.

Out-of-the-box Drupal provides out-of-the-box solutions. Simple websites with no legacy content can often be solved with out-of-the-box Drupal.

But if plain white with a roller won't do, an off-the-shelf solution won't provide what's needed and desired.

More complicated workflows and specialty functionality might have to be created on a sophisticated project with specialized needs.

Drupal is a great content manager, but out of the box, the platform is not a digital asset manager. That requires some finesse, especially if pre-existing digital assets are being folded into the new CMS.

There are over 21,000 contributed Drupal modules. Knowing which ones to use is not just a matter of selecting the most popular ones. An arcane workflow might need an arcane module, or one that is still in development; or custom code to create the right work flow.

Pay me now or pay me later. While the development budget can be reduced by going with out-of-the-box modules with out-of-the-box workflows, the cost in time, money, and employee morale should be taken into consideration. There is a trade-off to be weighed.

• What is the savings with an out-of-the-box solution?
• What costs are we putting off when workflows are altered?

Questions Managers Might Ask As Part Of Website Upgrades.

Managers view software and websites mostly as tangible, logical, and mathematical products. This view applies mostly to code, but not so much to legacy databases, which are another animal. While servers are believed to be fungible, the data stored on the servers is a unique asset - a repository of most everything that came before.

Has Your Firm Lost Any Institutional Knowledge Of Your Code Base And/Or Database?

Sometimes it is only when an organization looks to upgrade a codebase or database, do managers in the organization address tradeoff decisions that have gone unaddressed.

Like the Y2K problem, the developers who structured the original data could not foresee the demands on the modern web. Too often documentation is incomplete. Too often the structure is arcane, tracing back to Web 1.0 origins, usually predating just about everyone associated with the new project.

Does Your Existing Database Require An Archaeological Dig? Characteristics

• Some foundations support nothing - previous structure removed.
• No foundations, but a later structure overlaid.
• Foundation revamped to hold more, but now crumbling.
• A foundation that should never have been laid down.
• A foundation whose purpose is a mystery.

Like archaeologists, the web development team examines the structure of the preexisting database(s) and often their work will uncover hidden and long forgotten foundations upon which everything rests.

Digging into a preexisting database has the challenges of an archaeological dig. You never know what you'll turn up next. The picture may be incomplete. A complex foundation may exist, but what it supported has been swept away, while exactly the opposite can also be true - a large part of the structure may be supported on practically nothing.

Is Your Database Structure Laid Down Like Geological Layers? Characteristics

• The oldest layer supports everything else.
• Different layer types fold in around each other.
• Structure is random.
• The latest structure hides most of the old structure.
• It risks being metastable.

The longer a database is around, chances are, more will have been laid on top of it, while other things have been sandwiched in, not to mention 3rd party integrations that often are a moving target.

If it was just an old foundation that we discovered, things might make sense. However, bigger sites usually mean bigger databases and more functionality. So instead of an archaeological dig, we start to see a whole lot of parts. Layers of data, some that clearly show they are part of long abandoned work-arounds, but which remain in place.

The longer a database is around, chances are, more will have been laid on top of it, while other things have been sandwiched in, not to mention 3rd party integrations that often are a moving target.

What are all these pieces? How did they get there? Do they still serve a function, and if they do, is it efficiently done?

Is Your Existing Database Biological? Characteristics

• Each branch is a unique niche.
• Branches tend to evolve independently.
• Some branches are "hot," others are not.
• Some parts are modern; some are atavisms.
• Entire branches could be replaced by better ones, combined, or forgotten altogether.

Understanding an existing web structure begs a phylogenetics approach.

Why do people have an appendix? Why do all mammals have mammary glands -- even the males? Somewhere along the way these aspects came about and so far nature has not taken them out of future updates.

Data maps are helpful in showing the "how," but not always the "why," and in the absence of that, there is a tendency to replicate what went before.

Key Questions The Organization Should Ask Itself Before Migrating Data.

1. Has the organization identified those who will be impacted by a change in CMS? What are the direct and indirect costs?
2. Is the organization prepared for unintended consequences of a new CMS?
3. Has the organization fully documented its current website workflow?
4. Has the organization sensibly identified aspects of the existing CMS that must be preserved? Are there workflows that must be carried over? At what cost?
5. What documentation does the organization have regarding the original database, its structure, and its functionality?
6. What modifications to workflow have been implemented on the fly between the time of the original project and the new one?
7. Will the in-house users of the current system be the same users of the new system?
8. Will the organization need to change to work with a more advanced CMS? At what cost?
9. Will the organization need to bring on (additional) technical people to handle a more sophisticated site?
10. Does the development shop need to have this information to create the new site?
11. Will/Has the new CMS uncovered other areas, such as server size and capacity, that has gone unaddressed? At what cost?

tags:  Drupal database information architecture user experience migration business

Today I launched a new service called Random.pw (taking advantage of the new .pw domains). It's a random password generator, with lots of customization options to help you find a memorable but secure password, and it even has a password strength checker.

I would love to see something like this integrated into the Drupal registration and "change password" forms. It would solve lots of security problems, just by having folks use strong passwords.

The kicker is, it doesn't take much to make a strong password. Computationally, it's very difficult to hack a password that's long (say, 12 characters), contains letters and numbers (and at least one uppercase letter), and contains a special character or two. Reading How I became a password cracker was alarming at how easy it is to hack a common password. But it was assuring that a healthy diversity of characters is much, much more difficult to hack.

However, remembering a purely random password is very difficult, so much so that you might find yourself saving it somewhere so you can copy and paste it. That begs the question... how secure is it, if it's stored somewhere?

I attempted to solve this by integrating with Wordnik, a third-party API I'm using to get random nouns and adjectives on the fly. These are further obfuscated by randomly capitalizing the first letter, and by replacing one letter per word with a special character equivalent (e.g., "a" becomes "@"). These are easier to remember, and when stuffed with a few numbers, are computationally very secure.

The built-in, client-side password strength checker is powered by the good folks at How Secure Is My Password, and provides a nice interface with helpful explanations to nudge you toward creating stronger passwords.

So, head on over to Random.pw and spin yourself up a new password. It's all client-side, so you don't have to worry about your password being sent over the wire. There are plenty of options (and even a theme song) to help you find the right password.

Submitted by Joel Stein on April 24, 2013.Tags: Drupal Planet, PHP