Reality, in general, is too evident to be true.
"If you don't know how people work, you can't make stuff for people to interact with. The most talented and technical designer that lacks empathy will make something that only he/she can enjoy." ...
Sometimes we want to uninstall a module from our Drupal site but we can't do it because we get this dependency: "Required by: Drupal (Field type(s) in use - see Field list)". Even if you delete the fields provided by the module via the UI or programmatically by executing field_delete_field() function you will get a new dependency "Required by: Drupal (Fields pending deletion)".
These dependencies are created by Drupal core to avoid that a module is uninstalled until all the data related to its fields is removed from the database, in order to maintain consistency.
This has several drawbacks, the first one being that you can't uninstall your module when you want, and you have to wait until all the field data values are removed from the database (The rather strangely named field_deleted_data_XX and field_deleted_revision_XX tables) and the meta-information stored in field_config and field_config_instance tables is removed. And most importantly, nobody actually knows when this is going to happen! These database rows are removed in batches on each cron task execution. So depending on our cron regularity and the amount of data stored in our field tables, this tasks can last for minutes to weeks.
This is a problem because, naturally, we want to uninstall our module now and not be forced to check periodically our production database to see if we are allowed to uninstall the module once all that information has been removed from the database.
To avoid such situations and regain control, you can perform all these tasks in a hook_update_N() function, forcing the deletion of all the information and finally uninstalling the module. You can check the code in the gist below:
The job is divided in three parts: The data definition, field data purge and module list clean.
In the data definition task we provide all the required data we need to perform the task, the name of the field to delete, and given that information, we get the field_info array and the name of the module to be uninstalled. Finally, field_delete_field() is executed.
After that the field data is purged in the batch body, and since we don't know how much data we will have to purge, we remove just 100 database rows per batch execution. After each purge we check if all the data has been removed to decide if we have to remove more data from the database or continue to the final part.
Once all the data and metadata related to the module is removed from the database, the Drupal field types dependency is gone and we are granted the ability to disable and uninstall our module cleanly. Finally, we can drop the empty field_deleted_data_XX and field_deleted_revision_XX tables to keep clean our database.
Using this approach, we have two key benefits: a. we are sure that the module is disabled and our database is clean, and b. we are confident that we can remove the module from our repository, given that in the next deploy we won't get any dependency conflict with that module.Tags: Drupal Planet
"A couple months ago, I was talking to a friend in technology media. 'Sometimes I wonder why I'm in tech,' he started saying. He paused for a beat. 'Then I think, at least I'm not in games.'" ...
This module provides services on top of the Pushtape Music distribution.
At the moment it just provides custom handlers for JSON/Embed services, however there are plans to integrate more to allow for "Headless Drupal" architecture.
- Provides JSON (JSPF) output for releases (http://xspf.org/jspf/)
- Provices embeddable iFrame widget for releases
This is not a module, it's a Drush command that makes it possible to check for known indications of your site having been exploited with the vulnerability fixed in SA-CORE-2014-005.
This application makes possible to manage within Opigno courses in-house lessons, where students and teachers will meet for a classical training.
You will have the possibility to simply create an in house training with date, status, address (map), and then register the attendance of students.
In-house lessons will be added to each user's calendar, and can be used as a condition for the validation of the course, that wouldn't be considered as successful if the student did not attend the required in-house lesson(s).
A very simple module to provide a formatter for all field types. The output is simply a count of the number of items in that field. This is most useful on fields which have multiple values as it will show how many values are in this field.
A typical use could be on a Views page to show how many items have been entered into a multiple value field (eg, Node 123 has 5 node references on field XYZ).
A listener for Paypal Instant Payment Notification(IPN) messages.
This module can be used with PayPal Buy Now Buttons and other PayPal systems. This module does not create these buttons but can be used to respond to the notifications.
This module allows users to login with a custom identification number (or string). To configure this module, the site builder creates (or specifies a pre-existing) field on the user entity for use as the identification login credential.Use Case
An organization that wants users to be able to login using a custom identification number and password. This means each user account will have three unique identifiers:
This project deals with organizing and automatting a multisite setup, especially in variying environments with more than one (virtual) host, database, setting or configuration.
The difficulties in creating a semi or fully decoupled site isn't in the RESTful part. Spitting out JSON is now covered by several modules, including RESTful which aims for a "best practices" solution.
One of the real problems, though, is how to prevent us, the community, from re-inventing the wheel over and over again. Basically, how do we package our frontend code similarly to how we package our generic backend code - AKA "modules". I discussed these problems, and offered some solutions in my "BoF" persentation:
Felling lost? Confused?
Worry no more - Clippy is here to hold your hand.
Integrates clippy.js to Drupal! At the moment only Merlin is helping. Patches are more than welcome to integrate more awesomeness!
Drupal Camp Road Warrior
By the end of 2014, I will have hit 50 Drupal Camps! It took 72 months to hit 22 cities, in 16 states! In that time, I've seen Drupal Camps run in almost every conceivable way possible. From Madison WI to Orlando FL, from NewYork NY to San Diego CA, I've seen thousands of attendees flocking to these events, all with the hopes of growing in their knowledge and understanding of Drupal. In my experience, the system works -- mostly.
But, we can do better.
We all know the drill
You assemble a bunch of speakers. They will deliver a bunch of sessions. You try to group these sessions into tracks, if you can. You wrestle with how to add a few sessions about the Drupal Community or maybe about Business or a few odd sessions that don't fit into your tracks. Oh yah... You almost forgot about the beginners, so you have a session or two that demystifies one topic or another.
The N00B experience
You would be surprised at how many people show up to a Drupal Camp who don't know what a node is. Or if they do know what a node is, they don't know how to create their own content types. Or if they do know how to create content types, they don't know how to create Views. These people show up and attend sessions that they have little chance of comprehending. They sit down for up to an hour per session listening to senior developers from major Drupal shops talk about nodes and fields and blocks and views-displays and modules. The whole time they may be thinking, "Dang! I thought by showing up for a day or two I would start picking this stuff up!?" But they're not.
Meet the N00Bs
Who are these people who are "New To Drupal?" Well, for starters, they're probably not really that new to Drupal! Based on my experiences, here is an incomplete list of ppl who regularly attend my classes.
- Certainly anyone who just discovered Drupal very recently and has come to the camp to gain a better understanding of Drupal. [This is not always the biggest portion]
- Individuals who have been to a couple camps and have tried to read the books or watch the videos but still haven't had the needed "AHA!" moments to grasp it all.
- Individuals who work for a University or Government or Company who uses, or is considering, Drupal. [This is a BIG ONE]
- People, often with other web skills [sys admins, java, asp, php, etc] who are sent by their employers to scope out Drupal and/or to learn how to use it.
- People coming to gain skills in an effort to alleviate their, or their employer's, dependency on vendors. [This happens a lot!]
- New hires to Drupal shops or Design shops or shops offering web related services who are looking to better provide Drupal related services.
- People who know plenty, but want to make sure they are properly grounded.
- People who come in the hopes of asking lots of questions!
I've seen all that and more. Multitudes of people are coming to camps in hopes of really wrapping their minds around how Drupal solves the modern problem of publishing dynamic content on the web. Too often, without a day of training they leave the camp with the same [and more] questions than they arrived with.
What they really want/need
After attending camp after camp, it's a proven fact. People are coming to learn what Drupal is and how to use it. If the camp has no full day training opportunity then many are going to drown in the other sessions and simply not get what they really need.
I'll just be frank at this point. I believe that every camp needs to have a full day of beginner training. I believe that this training should be delivered not across differing tracks with differing speakers, but by the same individual, or group of individuals, working together to provide the full day of training. I have done this time and time again and I see the relief on people's faces as they gain a practical understanding of the power and flexibility of Drupal and how they can leverage it. This day of training starts them down the road of really learning Drupal. If there's a 2nd day of camp, I can PROMISE you that they will get far more out of it after a day of training.
How to provide a day of training at a Drupal Camp
There are many ways! Here's a list that is, by no means, exhaustive.
- Some camps have a dedicated day just for trainings on the day before the regular camp.
- This is effecive not only for beginner classes but for classes on SEO, Drupal 8, Module Development, etc.
- Most often training takes place in the same location as the camp, but occasionally it is not.
- Some camps simply reserve one track and dedicate it to a full day of training.
- I've done this quite a few times where I have a room all day while others hop from session to session.
- This is easier if you can't dedicate a whole day to training.
- The content in the full day Drupal beginner's training.
- In some camps someone leads the class through the Acquia curriculum of Drupal In A Day
- Some camps have a vendor come in and do the training
- Doug Vann! If you want me to join your camp and present a day of training call me at 765-5-DRUPAL or CONTACT ME
- I've seen posts from BLINK REACTION & OSTRAINING about their various full day offerings at Drupal Camps as well.
- If I missed anyone who has travelled to multiple camps and provided full day trainings in the past and would do so again, leave a comment and I'll add you here. :-)
- Some camps have used the BuildAModule.com Mentored Training method.
- I've done a number of these as well and they're pretty amazing!
- More info at http://buildamodule.com/train
- The finances of a full day of training. Here's how I've experienced this as a trainer.
- Some camps offer it for free or as part of the Camp fee that attendees have already paid.
- Some camps charge attendees enough to cover the cost of catering.
- Some camps charge a flat fee per attendee and share a percentage with the trainer.
- Some camps procure a "training sponsor" and hand that sum off to the trainer.
Every Drupal Camp can do this! I've been invited to one-day camps and they give me one of their rooms for the whole day. I show up and deliver the full day of Drupal Beginner Training. Sadly, I never get to see any of the other sessions. Oh well... After 50 Drupal Camps, I've seen plenty of Drupal Sessions! :-)
Providing a full day of training will definitely raise your attendance. Universities, Governments, and Companies will send people. People will ask their employers to send them. Sponsors will really appreciate the fact that you're providing extra value to a broader audience.
Seriously folks... What more can I say?
Full Day Trainings at Drupal Camps is a Big Win for everyone involved!