Newsfeeds

This sandbox is used for porting Video Recorder to Drupal 7. It will be removed after a patch has been submitted and hopefully committed to Video Recorder.

Check out #1570078: Port the module to Drupal 7.

Quick tip: Use bash aliases to easily run multiple versions of drush at onceSunday, 12th May 2013

There are times where it can be desirable to run two or more different versions of drush on one computer, or even multiple versions for one user.

For example, if you're using a server running the 1.x (stable) branch of Aegir and you attempt to upgrade from drush 4 to 5 globally all of your provision tasks will start failing, rendering Aegir completely useless.

The "real" solution is to upgrade Aegir to the 2.x branch but if you're looking for a quick fix it's easier to just install drush 5 in parallel with drush 4 for your user.

Steps to install drush 5 in parallel with drush 4:

This assumes you already have drush 4 installed, so that running $ drush status will report version 4.x

1. Download the latest version of drush 5 from the project page.
2. Extract the contents of the drush tarball into your home directory in a folder called drush5, so that the drush files can be found at ~/drush5.
3. Edit or create either ~/.bashrc or ~/.bash_profile and add the following line: alias drush5='~/drush5/drush'.
4. Reload your terminal/console or run $ source ~/.bashrc or $ source ~/.bash_profile as appropriate (whichever file you edited).

That's it! if you run $ drush5 status you should see a drush report a version number 5.x

You can now swap between drush 4 and 5 easily whenever you need to.

These steps can be adapted to do the same thing in reverse and have drush 5 run with the drush command and drush 4 with drush4, or you could even have each version explicitly mapped to drush4 and drush5 - it's up to you :)

Syndicate: planet drupal

Adds ecommerce interaction tracking for Piwik to Drupal Commerce.

Piwik is an php based open source analytics tool that aims to be an open source alternative to Google Analytics.
Piwik has several tracking functions for tracking ecommerce activities on your site. These are:

• Ecommerce Orders (and products)
• Ecommerce Cart update (and products)
• Product (and/or category) page views

See also:
http://piwik.org/docs/ecommerce-analytics/

This modules sends the order, cart and product page details from Drupla Commerce to piwik so it can generate the a bunch of reports which should help you to improve the shopping experience of your customers.

Requirements

• Piwik installation
• Drupal Commerce
• Piwik Web Analytics Module for Drupal

Installation / Configuration

1. Install like any other Drupal module.
2. Enable ecommerce tracking for your ecommerce site in your piwik installation. (Settings > Websites > 'Edit' and select 'Ecommerce enabled')
3. For now there is no configuration necessary. But this might change in the future.

Features

Working:
For now only order tracking is working. (Without category lookup per purchased product)

Missing:
Cart tracking and product page view tracking will follow.

Roadmap

• #1992932: Add order tracking.
• #1992920: Add tracking for add / update the shopping cart.
• #1992922: Add tracking for Product Page Views & Category Page Views

Similar Modules

This module is based on ideas from the Google Analytics Version of this module.

This module allows customization of displayed field labels, including its HTML element and CSS classes.

Dependencies

Field formatter settings

Droptica DevServer is virtualbox image with configured Ubuntu Server 12.04, GIT, Jenkins and sample Drupal project with PHPunit tests. 

DOWNLOAD

Informations about operating system:

• OS: Ubunutu 12.04
• Linux user name: droptica
• Linux user password: drop
• Network configuration: auto dhcp
• Mysql root password: drop

 

Apache 

Virtual hosts file: /etc/apache2/sites-enabled/jenkins

PHPMyAdmin: http://SERVERIP/phpmyadmin 

Jenkins:

http://SERVERIP:8080

Jenkins jobs directory: /var/lib/jenkins/jobs/drupalproject_dev/workspace

Informations about Drupal sample project:

GIT repository location (bare): /var/git/drupalproject.git

Repository structure:

• app - Drupal core and modules
• conf - configuration files (Drupal settings, PHPunit settings)
• database - Drupal database dump (after fresh installation)
• docs - information how to run build script on local machine
• scripts - build.sh script

Drupal administrator

login: admin

password: 123

PHPUnit tests examples

app/sites/all/modules/custom/application/tests/application.test

http://www.droptica.com/en/droptica-devserver

Knowledge Language English My Mentor/D8MI Drupalcon Portland ScheduleCathy Theys05/12/2013 - 08:28

This is a wishful schedule. Some things I'm committed to be at. Some I'm wishing I will to have time to go to.

Note, the google core mentoring calendar will make it easy to add some of these to your calendar. Core mentoring calendar: 7ss54o2foktlc8b75d1gest4do@group.calendar.google.com

It's a mix of what I'm into: my sessions, mentoring and multilingual.

Tuesday

• 9:00am Programming Diversity by Ashe Dryden
• 10:15am Making core development sustainable by Greg Dunlap
• 11:30am The Current State of Drupal 8 Keynote by Dries (is what I would go to if I were not staffing the Community booth at that time.)
• 2:30pm I'm going to be trying to be calm right before my session. But if not, I'd pick: Dependency Injection in Drupal 8 by Katherine Bailey
• 3:15pm I'll be at my session! Running coaches wanted! Contribution sprints and trainings by Jess, Andrea, Addi and me
• 4:30pm I'll be in a BoF with mentors doing task selection for the Friday sprint, but if I were not, I'd be in UX Case: Love and Hate in The Issue Queue Garden by Michael Keara, Thomas Svenson
• 5:30pm Exhibit Hall for Drupalcon Kick Off Reception
• 6:00pm or so Women in Drupal Meet and Greet

Then on Weds...

Description:

The Link Widget module provides an elegant way for wrapping an link around a "image" or "text" field type output. This module is dependent upon the Field Widget Storage API, which provides a solution for saving extra widget configurations alongside a field.

What are the differences between Link Widget and related link modules?

The biggest difference is based on the modules architect; instead of creating another field type, I just created a field widget that extends the field configurations. You can make either an image or text field type linkable. This concept can be extended and can accommodate for other field types in future releases.

What are the advantages of the Link Widget module?

There are a couple advantages of the Link Widget module. First and foremost, there is less code to maintain. As I'm only defining a field widget, and don't have to worry about recreating the field component. Second, the Link Widget is flexible and making a text or image field linkable, is super easy and can be done by just selecting a field widget type "Link".

What link attributes does Link Widget module support?

• Class - Specifies one or more class names for an element.
• Rel - Specifies the relationship between the current document and the linked document.
• Target - Specifies where to open the linked document.
• Media - Specifies what media/device the linked document is optimized for.
• Type - Specifies the MIME type of the linked document.

Note: I exposed a drupal hook so other modules can add their own attributes.

Supported Modules:

• Flex Slider
• Token

Related Modules:

• Link
• Link Image Field

Dependencies:

• Field Widget Storage API

This module provides a simple Teamspeak 3 server web viewer rendered into a block
The module it's compatible only with Drupal 7.x core: No Drupal 6 version will be implemented since there are already other modules that offer the same functionality and which are compatible with Drupal 6.x core. A version of this module compatible with Drupal 8 will be released as soon as Drupal 8 will become the new stable version of Drupal.

This project is helper module for other modules. It fetches the current bitcoin price from bitcoincharts.com and uses Mt Gox as a fallback it Bitcoin Charts is down.

Description:

The Field Widget Storage API module is a storage engine that can be used by any field widget that needs to save extra configurations alongside a field. Developers are able to leverage the modules API so they don't have to worry about implementing CRUD functionality for their field widget.

Use Case:

Hypothetically, say you need to collect a class attribute from a user when an image is uploaded on a given entity. Currently the Image field type doesn't expose a way to define class attributes. We're going to have to accomplish this by defining a new field using the Field API, and rebuild the image uploading capabilities inside that module. Then implement the code for collecting the class attribute. That seems like a lot of development time just to allow a user to input a class attribute for an image.

Just squatting for the moment.
The plan is to move the plugins from Feeds Tamper here. Then Feeds Tamper will just contain the feeds integration, and we can create other integrations as well. Rules tamper? Tamper plugins as filter formats or field formatters? Other things...

This project seeks to provide a true compound field solution for Drupal 7. As much as I love Field collection, it still has to save actual entities, and can cause performance problems due to having to load all the referenced field collection entities on node, or parent entity load.

Related links

• http://drupal.org/project/combofield and https://github.com/yched/combo
• #939836: combofield / fieldentity / field-collection / embeddables
• http://drupal.org/project/flexifield
• Comparison of multifield modules
• #494100: State of the multigroup module
• http://drupal.org/project/subform
• http://drupal.org/project/composed_field
• http://drupal.org/project/double_field
• http://drupal.org/project/field_group_multiple
• http://drupal.org/project/form_builder

While ago i was looking for an slider module (implementation of JQuery UI slider module), surprisingly i couldn't find any solution except jSlider Form API which wasn't exactly what i was looking for. So i did what every good Drupal developer does, I wrote a generic slider module and shared it on Drupal.org (jQuery UI Slider Field). I even implemented "jSlider Form API" features.

Several months later and after i published several new minor versions, one of the users mentioned that there is in fact another slider module similar to mine!! SliderField and it was quite old too. He suggested joining forces to prevent duplicate modules. and that's what i did and even more.

read more

We're not talking about Darwin, but about the fact that a website project - even after delivery - will often stay in a state of evolution before becoming ‘stable’. The evolution itself isn’t the problem. Responding to that evolution is often what causes operational headaches. This article will not deal with the technical complexities of the Drupal development lifecycle, the CMI in Drupal 8 should solve that. Here we delve into the operational issues of website evolution.

Some definitionsAbout a decade ago, websites were constructed by ordinary people promoted from among their peers to the role of webmaster. Because websites weren’t used as the powerful marketing tools they are today, many websites remained under construction for a long time. Sometimes forever. Nowadays, websites can be under construction for a long time as well, but the construction phase is more accurately name; used by website engineers as they actually construct the website. Once the website is completed and delivered, it enters the maintenance phase. The actual go-live might happen overnight, but there’s often a fairly long time before development stops. The time between construction and maintenance is what’s called the evolution phase.  for ITIL lovers Within Application Maintenance Services our focus in this article is on Application (Drupal) Support.   Within Application Maintenance we can identify 4 types of Support. Corrective Support (eg. download link does not work), Adaptive Support (eg. make whole website work for new version of Internet Explorer),  Preventive Support (eg. perform security updates) and Perfective Support (eg. Add a carrousel to the new campaign page).     We rather use the term “Evolution” to denote the combination of Perfective and Preventive Support since it better fits the notion that we are talking about, more than ‘support’. ConstructionThe construction phase for websites is that period between having a neat idea, and bringing the resulting idea into production. The most important part of that phase is the concepting phase, while the largest part of that phase is the actual development project. The business model for development projects is fairly straightforward: sell as many development projects as there is capacity while keeping planning and efficiency (i.e. working billable hours at least 80% of the time). To fill the gaps between projects, you can take on smaller projects. The less downtime you have in your work schedule, the better. The resulting website will consist of everything that the client wants to start from. MaintenanceConstruction processes can be standardized to some extent, but it’s impossible to predict fallouts and failures, once software is running stably. The main problem of these fallouts is not the failure itself, it’s making sure you have resources available to fix the problem. So suppliers of modern-day equipment and services need to make sure they have enough permanent resources to address issues as they arise, in order to comply with their Service Level Agreements (SLA). Typically there are peaks moments and there are moments when everything is running smoothly. Only proactive maintenance tasks (e.g. upgrades, increasing memory) become plannable. But for this to be worthwhile, you need enough clients and enough resources to come up with usable heuristics. Once you have proper statistics, the maintenance business model becomes scalable, because it’s not people but statistics that are sold. In fact, resources can be sold multiple times when you’re dealing with small, unpredictable chunks of work. The resulting website will become  stronger and more stable by performing these maintenance tasks. EvolutionThe business model of maintenance is clear (enough resources + enough clients = scalable workflow), but starts to degrade as soon as these chunks of work become too big. This is what happens when the website is in evolution. During that evolution phase, the client will make feature requests that the development team needs to handle. But due to the nature of the request, the client will be unsatisfied if that request is handled as a project (ie. planned to happen in 5 weeks).  The resulting website will consist of improvements to adapt to changing business requirements, staying up to date with the newest technologies (e.g responsive design) or being ready for new marketing campaigns. What is the problem?If the evolution were handled as construction, clients would have to wait too long for small changes.If, on the other hand, it were handled as maintenance, the support team would lack experience  to complete all the engineering going on. Even if they did have the skills to handle those medium-sized chunks of work, accepting these requests would break the statistics of the business model. This could jeopardize the correct reaction time on more critical requests. What we are hearing from prospects and clients working with Drupal websites at the moment does indeed comply with our findings. We hear remarks like, “Yes, we have a support contract, our supplier reacts quickly and communicates well, but the quality of the fix is low or feature A gets implemented, while another existing feature B breaks down.” Or we hear, “Yes, we have a support contract, and the supplier delivers correct solution. They even bundled multiple requests into one release, but it takes weeks, sometimes months to get a small thing changed.”  Possible solutionsThere’s a list of possible ways to be able to deal with these situations, and the Wunderkraut support model currently handles all of them.  Fixed SupportReserve a few people from the development team for a number of days a week/month for a certain period of time, e.g. every Friday for six months, two developers will be available to react to client requests in the issue queue. The following problems arise with this solution:

• It’s very hard to predict how many resources will be needed and for how long, which will result in either too many or too few blocked resources.
• If these developers are unable to get a feature totally released on that Friday, they need to continue working on it, the next week - i.e. it is still slow.
• If the client does NOT have any requests, they will still be paying (maybe partially) for that unused time, and some clients don’t like that.

 Lower the billabiltyAnother option would be to decrease the billabilty of one or more dev-teams, e.g. only the dev-team is directly billable on projects for 60% of the time, so has extra room to handle these small chunks of works. But the problem here is pretty clear: the risk  is completely moved to the supplier. If in one month, none of the clients requests smaller work, the supplier has no income. This is in general not a good business model. On the other hand, this solution does not scale. If the supplier freed up some resources for each of his clients, the dev-team would just be ‘waiting’ for new features to come in, instead of working on new projects. Wunderkraut Evolution model (beta)We’ve finally managed to devise a model that combines the agility of the two weekly sprints of Scrum, with some warranties on reaction time for certain requests. We won't go into the details of the model, but the general idea is that we use a mix of fixed support and lower billability to spread the risk evenly between client and supplier, and at the same time allow small chunks of (evolutiove) development work to be added to the sprint backlog of a selected development team.  We are currently test-driving this solution for some clients, and will report back at a later time to talk about the results. Let’s discuss and learnIt may not come as a surprise that both clients and service agencies are dealing with complex issues as a result of this dilemma. In fact both parties are actually losing time and money in their search for the best solution. Therefore we would like to invite CTOs, CMOs and other company decision-makers and influencers to our round table discussion group in Belgium to exchange views on how to best solve this.  In an informal setting, a panel composed of a  Marketing Director (Kinepolis), a Technical Director (Cultuurnet) and a Supplier (Wunderkraut) will touch upon the different  aspects  of  the website evolutionary support.  The discussion will be moderated by Bart Gysens (project medewerker V-ICT-OR). If you are interested in joining this event please send an email to be.info@wunderkraut.com to register. 

Extends Webform & Drupal Commerce to provide enquiry cart functionality.

This module adds an extra field component to Webform allowing the storage of commerce orders. Order details can be emailed upon form submission, rendered in a table.

The intended use cases include pre launch shops, ambiguous goods & or services, new & or pre released goods.

Please provide feedback.

Read more

Automated installation of apachesolr multicore localy will save you valueable time.

How to automatically install apache solr multicore localy for drupalapachesolrsearchautomationSaturday, May 11, 2013 - 14:49

Attempt to provide an alternative IEF widget that renders the entities using a specific view mode. This has the added benefit of being able to re-use core's default multiple value widget handling.

Screenshot of the goals of this project:

Related Links:

• #1521274: Investigate a UI for configuring table columns (which fields and in what order)
• http://drupal.org/sandbox/rogical/1880826

• drupal 7.x
• views
• menu
• planet drupal

This article describes how to place a custom local task menu tab alongside the 'View' and 'Edit' tabs on a content type.

The Drupal.org infrastructure is a great resource for developers: A hub for development, with a combination of version control access, issue tracking, and automated testing.

Of course, it can be improved, and I don’t want to open a can of worms by saying it is perfect (it isn’t).

But I think the community does benefit from an environment that is designed especially for it.

Within this environment, we also have useful tools that help maintain quality in Drupal code.

1. The issue queues and workflow are set up to foster peer review, which (in line with the open source way) gives unlimited human eyes on a problem, rather than being siloed within a commercial organization.
    
2. Contributed projects such as dreditor allow fast, tangible reviews from reading through code, giving a clear comment for others to work from.
    
3. Automated tests mean that once you’ve set up code, you will automatically get the green or red light as to whether a change has unintentionally broken anything.
    
4. The coder module allows automatic reporting of code style, which helps bring the community towards common coding standards and accelerates the speed at which a contributor can become familiar with a new section of code. 

But these checks do add to the hassle of contributing a patch. Not good.

Formalising the process of review

On one of my projects, the Project Management Module, I was weighing up whether I should formalise the review process.

Previously, whilst a lot of the factors mentioned were taken into account (although not coder), it was a little haphazard, and I felt it wasn’t clear enough.

I wanted a contributor to know what the hurdles they were in advance, so that they could write a patch at the outset that solved the issues.

There are typically several patches undergoing review at the same time in the issues queue, so I also wanted to be able to speed up the review process to minimise the need for patch rerolls.

My biggest concern here was that I would alienate contributors to the project. This would not be an acceptable sacrifice, even if it meant that we were upholding the coding standards more precisely, etc.

Contributors come first

You’ll have got the message by now that one of the biggest risks to an Open Source project is (in my opinion) alienating your contributors.

So, whilst I’ve gone ahead and put a bit more structure in how I review patches, my focus has been on keeping the process easy and worthwhile – with a focus on the new element, coder reviews. 

Those regulars in the Project Management Module issue queue will keep me honest in the comments, I’m sure!

Is there a point to code style?

There are massive advantages to uniform code style among a community, but it is an investment made in a patch, with a longer term reward.

I’ve done two things to make coder patch reviews less painful:

1. Show the results: I’ve set up a developers website for the Project Management Module.
   
   You can see it at http://api.project-management-module.org.
   
   The aim here is for developers now to reap the benefits of the documentation that we’re adding to the code.
    
2. Lower the hurdle: I understand that not everyone has a test site running the coder module, and it adds a lot of time if you need to set that up each time.
   
   So I’ve opened up coder on the Project Management Module demo site.
   
   You can see it at http://drupal-7.project-management-module.org/admin/config/development/c....
   
   A check of a patch now takes a few seconds, and can be done before submitting on Drupal.org (in fact, you could use it for your patches too - it isn't module specific).

So far, I’m pleased with the results.

Nobody has complained about additional hurdle of coder reviews, and there have been some very positive comments about having an API site for all to see.

Conclusion

Alienating contributors is a real risk when formalising a process in an Open Source project, but it doesn’t mean that you shouldn’t try it.

Before implementing any change, think about how you will make the change worthwhile from the point of view of other contributors – whether by showing the point of it, reducing the pain, or both.

When have you tried to formalise a process in Open Source?

Has it worked?

What steps did you take to ensure contributors were not alienated? 

As always, I’d welcome your thoughts in the comments.

Category: WebsitesTags: DrupalDrupal PlanetMaintaining an Open Source ModuleOpen SourceCoderPatches

What is a million dollar house worth if it has bad wiring? Bad wiring means ripping out the drywall, getting it inspected by the city, and starting from scratch. If you have a builder that would allow something like that, as an owner you have to go from the bottom up and review what else they left lurking in your dream home.

Web application development is no different from a house. Sites require real estate, maintenance, and are living, functioning pieces. They require the occasional remodel to add more features as users needs change.

So why do so many web consultants often act like the McMansion builder of the web? Build it fast, cheap, charge as much as we can and walk out the door? Who do they think they're fooling? Maybe the clients, but will they be repeat clients?

Read more