Skip to Content

Drupal

FileField Sources Resumable

New Drupal Modules - 20 October 2014 - 3:26pm
Categories: Drupal

DrupalGap Mobile Notifications

New Drupal Modules - 20 October 2014 - 2:32pm

This module provide a "Mobile Notifications" node type and a view called "Mobile Notifications". When you add a new Mobile Notification post, the module send a push notification to registered devices. You can choose the roles that receive this notification. You can, also, send a link to a site node.

You can use this module with Mobile Notifications in your DrupalGap app.

In depth documentation are comming

Categories: Drupal

Drupal @ Penn State: Drupal speed tuning: analyzing and further optimizing Pressflow

Planet Drupal - 20 October 2014 - 1:46pm

TL;DR: I've created a fork of Pressflow for the purposes of conversation and analysis -- https://github.com/btopro/Presser-Flow-FORK

History lesson

Categories: Drupal

Acquia: DrupalCon Amsterdam Top Ten – Part 1 of 2 with Kris Vanderwater

Planet Drupal - 20 October 2014 - 10:34am

Part 1 of 2 – Kris Vanderwater (EclipseGc), Acquia’s Developer Evangelist, and I got together in a Google Hangout to catch up on our impressions of DrupalCon Amsterdam. We prepared a list of our top ten sessions from the Con for you to catch up with at home (technically nine sessions and one “other cool thing”). In our list, there’s a little something for most everyone, from coders, to themers, to site builders, to those of us who pitch sell Drupal to clients – but we would recommend all of these sessions to anyone involved in Drupal. See how the other side lives!

Categories: Drupal

SitePoint PHP Drupal: Drupal 8 Hooks and the Symfony Event Dispatcher

Planet Drupal - 20 October 2014 - 9:00am

With the incorporation of many Symfony components into Drupal in its 8th version, we are seeing a shift away from many Drupalisms towards more modern PHP architectural decisions. For example, the both loved and hated hook system is getting slowly replaced. Plugins and annotations are taking away much of the need for info hooks and the Symfony Event Dispatcher component is replacing some of the invoked hooks. Although they remain strong in Drupal 8, it’s very possible that with Drupal 9 (or maybe 10) hooks will be completely removed.

In this article we are going to primarily look at how the Symfony Event Dispatcher component works in Drupal. Additionally, we will see also how to invoke and then implement a hook in Drupal 8 to achieve similar goals as with the former.

To follow along or to get quickly started, you can find all the code we work with here in this repository. You can just install the module and you are good to go. The version of Drupal 8 used is the first BETA release so it’s preferable to use that one to ensure compatibility. Alpha 15 should also work just fine. Let’s dive in.

What is the Event Dispatcher component?

A very good definition of the Event Dispatcher component can be found on the Symfony website:

The EventDispatcher component provides tools that allow your application components to communicate with each other by dispatching events and listening to them.

I recommend reading up on that documentation to better understand the principles behind the event dispatcher. You will get a good introduction to how it works in Symfony so we will not cover that here. Rather, we will see an example of how you can use it in Drupal 8.

Continue reading %Drupal 8 Hooks and the Symfony Event Dispatcher%

Categories: Drupal

Drupal core announcements: Let's fix critical Drupal 8 issues together!

Planet Drupal - 20 October 2014 - 8:57am

Every Friday at noon Pacific (3pm New York, 9pm Berlin, 6am Saturday in Sydney) I will be in #drupal-contribute helping people fix critical issues. I will prepare 2-3 issues with up to date, actionable issue summaries, familiarize myself with the problems and the suggested solution in the issue so that I can answer questions.

If you're someone who has already worked some in the Drupal.org issue queue (so are familiar with patches, coding standards, etc.), even if your experience is not in the core queue, please come by! It's helpful if you know something of Drupal 8 as well, but not necessary.

If you're new to contributing to Drupal in general, you can go to https://www.drupal.org/core-mentoring for a session or two to learn the skills you need to fix critical issues. If you're new to Drupal 8, https://api.drupal.org/api/drupal/8 is a great starting point.

Hope to see you there!

Categories: Drupal

Phase2: Simplify Your Logstash Configuration

Planet Drupal - 20 October 2014 - 7:16am

As I mentioned in my recent post, I got a chance to upgrade the drupal.org ELK stack last week. In doing so, I got to take a look at a Logstash configuration that I created over a year ago, and in the course of doing so, clean up some less-than-optimal configurations based on a year worth of experience and simplify the configuration file a great deal.

The Drupal.org Logging Setup

Drupal.org is served by a large (and growing) number of servers. They all ship their logs to a central logging server for archival, and around a month’s worth are kept in the ELK stack for analysis.

Logs for Varnish, Apache, and syslog are forwarded to a centralized log server for analysis by Logstash. Drupal messages are output to syslog using Drupal core’s syslog module so that logging does not add writes to Drupal.org’s busy database servers. (@TODO: Check if these paths can be published.) Apache logs end up in/var/log/apache_logs/$MACHINE/$VHOST/transfer/$DATE.log, Varnish logs end up in/var/log/varnish_logs/$MACHINE/varnishncsa-$DATE.log and syslog logs end up in /var/log/HOSTS/$MACHINE/$DATE.log. All types of logs get gzipped 1 day after they are closed to save disk space.

Pulling Contextual Smarts From Logs

The Varnish and Apache logs do not contain any content in the logfiles to identify which machine they are from, but the file input sets a path field that can be matched with grok to pull out the machine name from the path and put it into the logsource field, which Grok’s SYSLOGLINE pattern will set when analyzing syslog logs.

Filtering on the logsource field can be quite helpful in the Kibana web UI if a single machine is suspected of behaving weirdly.

Using Grok Overwrite

Consider this snippet from the original version of the Varnish configuration. As I mentioned in my presentation, Varnish logs are nice in that they inclue the HTTP Host header so that you can see exactly which hostname or IP was requested. This makes sense for a daemon like Varnish which does not necessarily have a native concept of virtual hosts (vhosts,) whereas nginx and Apache default to logging by vhost.

Each Logstash configuration snippet shown below assumes that Apache and Varnish logs have already been processed using theCOMBINEDAPACHELOG grok pattern, like so.

filter { if [type] == "varnish" or [type] == "apache" { grok { match => [ "message", "%{COMBINEDAPACHELOG}" ] } } }

The following snippet was used to normalize Varnish’s request headers to not include https?:// and the Host header so that therequest field in Apache and Varnish logs will be exactly the same and any filtering of web logs can be performed with the vhost andlogsource fields.

filter { if [type] == "varnish" { grok { # Overwrite host for Varnish messages so that it's not always "loghost". match => [ "path", "/var/log/varnish_logs/%{HOST:logsource}" ] } # Grab the vhost and a "request" that matches Apache from the "request" variable for now. mutate { add_field => [ "full_request", "%{request}" ] } mutate { remove_field => "request" } grok { match => [ "full_request", "https?://%{IPORHOST:vhost}%{GREEDYDATA:request}" ] } mutate { remove_field => "full_request" } } }

As written, this snippet copies the request field into a new field called full_request and then unsets the original request field and then uses a grok filter to parse both the vhost and request fields out of that synthesized full_request field. Finally, it deletesfull_request.

The original approach works, but it takes a number of step and mutations to work. The grok filter has a parameter calledoverwrite that allows this configuration stanza to be considerably simlified. The overwrite paramter accepts an array of values thatgrok should overwrite if it finds matches. By using overwrite, I was able to remove all of the mutate filters from my configuration, and the enture thing now looks like the following.

filter { if [type] == "varnish" { grok { # Overwrite host for Varnish messages so that it's not always "loghost". # Grab the vhost and a "request" that matches Apache from the "request" variable for now. match => { "path" => "/var/log/varnish_logs/%{HOST:logsource}" "request" => "https?://%{IPORHOST:vhost}%{GREEDYDATA:request}" } overwrite => [ "request" ] } } }

Much simpler, isn’t it? 2 grok filters and 3 mutate filters have been combined into a single grok filter with two matching patterns and a single field that it can overwrite. Also note that this version of the configuration passes a hash into the grok filter. Every example I’ve seen just passes an array to grok, but the documentation for the grok filter states that it takes a hash, and this works fine.

Ensuring Field Types

Recent versions of Kibana have also gotten the useful ability to do statistics calculations on the current working dataset. So for example, you can have Kibana display the mean number of bytes sent or the standard deviation of backend response times (if you are capturing them – see my DrupalCon Amsterdam slides for more information on how to do this and how to normalize it between Apache, nginx, and Varnish.) Then, if you filter down to all requests for a single vhost or a set of paths, the statistics will update.

Kibana will only show this option for numerical fields, however, and by default any data that has been parsed with a grok filter will be a string. Converting string fields to other types is a much better use of the mutate filter. Here is an example of converting the bytes and the response code to integers using a mutate filer.

@TODO: Test that hash syntax works here!

filter { if [type] == "varnish" or [type] == "apache" { mutate { convert => { [ "bytes", "response" ] => "integer", } } } }

Lessons Learned

Logstash is a very powerful tool, and small things like the grokoverwrite parameter and the mutate convert parameter can help make your log processing configuration simpler and result in more usefulness out of your ELK cluster. Check out Chris Johnson’s post about adding MySQL Slow Query Logs to Logstash!

If you have any other useful Logstash tips and tricks, leave them in the comments!

 

Categories: Drupal

Bluespark Labs: Uninstalling and purging field modules all at once

Planet Drupal - 20 October 2014 - 4:14am

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
Categories: Drupal

Visitors Voice: That is why we sponsor the Search API Solr module

Planet Drupal - 20 October 2014 - 3:03am
Since june 2014 we sponsor the Search API Solr module. There are no strings attached, and we sponsor the maintainer Thomas Seidl a.k.a Drunken Monkey with a couple of hours every month that he can spend as he likes. It could be bug fixing, features asked for or working on the Drupal 8 version. We […]
Categories: Drupal

Pushtape Services

New Drupal Modules - 20 October 2014 - 1:34am

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

Categories: Drupal

Drupalgeddon

New Drupal Modules - 20 October 2014 - 1:12am

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.

SA-CORE-2014-005 FAQ

Highly recommend checking out the Site Audit command also.

Categories: Drupal

Opigno in house training app

New Drupal Modules - 20 October 2014 - 12:34am

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).

Categories: Drupal

Field Count Formatter

New Drupal Modules - 19 October 2014 - 2:52pm

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).

Categories: Drupal

PayPal IPN

New Drupal Modules - 19 October 2014 - 12:58pm

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.

Categories: Drupal

Bootstrap Date & Time picker

New Drupal Modules - 19 October 2014 - 6:49am
Categories: Drupal

Identification

New Drupal Modules - 18 October 2014 - 9:12pm

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:

Categories: Drupal

Multi Site Matcher

New Drupal Modules - 18 October 2014 - 2:43pm

This project deals with organizing and automatting a multisite setup, especially in variying environments with more than one (virtual) host, database, setting or configuration.

Categories: Drupal

Gizra.com: Gizra - We've Got Your Headless Covered

Planet Drupal - 18 October 2014 - 2:00pm
What's the name of the Angular component for login?

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:

Continue reading…

Categories: Drupal

Moment.js

New Drupal Modules - 18 October 2014 - 8:30am

Integrate the Moment.js library into Drupal.

Categories: Drupal

Clippy

New Drupal Modules - 18 October 2014 - 7:31am

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!

Categories: Drupal
Syndicate content


Google+
about seo