Elsewhere

VM(doh): Ensuring Consistent Configuration Across Drupal 7 Environments

Planet Drupal - jeu, 17/07/2014 - 14:51

A common issue that many Drupal developers have is maintaining consistent configuration across environments. Quite often, a developer may run into an issue where something that was tested and confirmed working in development fails in production, or vice versa. Typically, the issue stems from an undocumented change that was made in one environment but not the other. This is an adverse side effect of storing configuration within the database.

Ideally, all configuration should be under version control. In Drupal 8, this issue has been solved by the Configuration Management Initiative. However, to achieve the same goals in Drupal 7, one must implement workarounds.

For variables, it's rather trivial to enforce certain parts of your configuration. When it comes to the variable system, the $conf global has the final say on the value of a variable. The variable_get() function simply retrieves a variable from the global $conf array, and that array is built from the variables table with values in settings.php overriding the retrieved values. Basically, there are two ways to find out what variables on your site you can force via settings.php: the most thorough is to print out the $conf array (preferably through dpm()), but you can also search for instances of variable_set() and variable_get(). Looking for variable_get() might also expose undocumented but useful variables.

But what about more complex pieces of configuration, such as fields, Views, entity types, etc? In many cases, you can export those with the Features module. However, in order to be successful in using Features to manage the configuration of different parts of your site, you need to implement a policy that overridden Features modules in production should be considered broken.

But what about things that aren't exportable to Features? What about special steps that need to be taken to implement a bug fix or new feature? We like to leverage hook_update_N() within a custom deployment module. With this approach, we're able to define (and therefore easily document) changes in code (and therefore under version control) and simply use "drush updb" to implement them. (If you're not using Drush, and you really should be using Drush, this is the same as running update.php.) We put all of our configuration changes in one of these hooks in our deployment module, including variable_set(), module_enable(), module_disable(), features_revert() for any Features that we have changed, database queries to fix data issues caused by previous bugs, etc.

This has several advantages. For one, deployments become a lot simpler. Ideally, you want your deployments to be hands-off. What this method allows us to do is write a simple deployment script that pulls the new code from Git, put the site into maintenance mode, runs a registry rebuild via drush just in case we moved a module (some moves can cause white screens of death if you don't do this), runs updates via Drush, clears cache (just in case), runs cron (just in case), and takes the site back out of maintenance mode. In cases where we manage the ops side or the client's ops team allows, we'll also send a notification to the monitoring system to make sure that the new deployment is noted (very useful for determining when a problem was introduced).

Another key advantage is documentation. With configuration changes made via update hooks, we can tell exactly when configuration changes were introduced and by whom. It also all but eliminates the risk of a costly missed step on deployment to production as the deployment steps themselves are tested when a developer updates their development environment.

For some configuration settings, such as enabling a debug mode for a particular module, we may want to allow those changes to be made temporarily through the UI. However, accidentally leaving those debugging settings enabled can cause performance issues. In these cases, we combat this by defining critical settings in an implementation of hook_requirements(). (This only works for settings that have not been defined via the global $conf variable.) Using hook_requirements(), we're able to check that settings are appropriate for the environment (typically limited to production) and display a message to users with proper access if they are not in order to warn them that they need to adjust that setting back to the appropriate value.

But what should we do with hook_install()? There are two schools of thought here. One is to define all of your final configuration here, and the other is to loop over your implementations of hook_update_N(). I prefer the latter. While looping over hook_update_N() can be a more expensive process if your site has gone through some serious evolution, it's less duplication of code and less of a chance for you to miss something important. The goal of our use of hook_install() is to eliminate database cloning by only requiring the developer to install the deployment module to initialize a fully functional development version of the site.

Eliminate database cloning? For the most part, yes. Database cloning is a bad practice, even cloning upstream from production. Databases can be huge, and cloning a huge database can impact the performance of the site for your users. Databases can contain sensitive information (most standards dealing with the handling of sensitive information dictate that sensitive information only be accessible to those who absolutely need to access it), and most developers don't need access to sensitive information. Databases in production while a bug existed in production don't usually fit the requirement of presenting a known good starting point for development. Believe it or not, your content and customer information are not necessary for development.

So what can we do about content and other information? The answer is to generate it. Generate dummy content. Generate dummy orders. Generate dummy products. And so forth and so on. If you're doing automated testing, you will be having to do that anyway.

There are exceptions to not cloning the production database. Sometimes you will run into bugs that seem to only occur in production. In this case, it is acceptable to clone the database because the bug is likely caused by something that was unanticipated. However, when fixing these bugs you should take steps to ensure that whatever content or other information change that surfaced the bug is tested for before deploying to production thereafter.

Another exception is if you are using a staging and/or QA environment. In this case, you will want to clone the production database upstream to staging/QA just before deploying your fresh code to staging/QA. You need to do this to absolutely ensure that the changes in your deployment module cover all of the changes that will need to be made to production.

Finally, it's important to test. Writing the actual tests are outside the scope of this post, but it is important that you have automated tests in place that ensure that your site is configured exactly how you need it. Even if you have tests for your site's custom modules in those modules, you need to test your deployment module. The goal here is to fail fast. By having a separate test group for your configuration, you can have Jenkins (or whatever other continuous integration software you use) proceed to other tests only after your configuration tests have passed.

Catégories: Elsewhere

Craig Small: No more dspam, now what?

Planet Debian - jeu, 17/07/2014 - 14:33

I was surprised at first to see that a long-standing bug in dspam had been fixed. Until that is, I realised it was from the Debian ftp masters and the reason the bug was closing was that dspam was being removed from the Debian archive.

 

Damn!

 

So, now what? What is a good replacement for dspam that is actually maintained? I don’t need anti-virus because mutt just ignores those sorts of things and besides youbankdetails.zip.exe doesn’t run too well on Debian. dspam basically used tokens to find common patterns of spam and ham, with you bouncing misses so it learnt from its mistakes. Already got postgrey running for greylisting so its really something that does the bayesan filtering.

 

Some intial comments:

  • bogfilter looks interesting and seems the closest thing so far
  • cluebringer aka policyd seems like a policy and bld type of spam filter, not bayesan
  • I’ve heard crm114 is good but hard to use
  • spamassasin – I used to use this, not sure why I stopped

There really is only me on the mailserver with a pretty light load so no need to worry about efficiencies.  Not sure if it matters but my MTA is postfix and I already use procmail for delivery.

 

 

Catégories: Elsewhere

ThinkShout: Safeguard Your Nonprofit's Website with NodeSquirrel

Planet Drupal - jeu, 17/07/2014 - 13:00

In our web hosts we trust, right? Right. They safeguard your nonprofit’s website, ensure it can handle your incoming traffic, and, perhaps most importantly, they backup your site so that if for some reason, your website ever imploded, it wouldn’t be lost for good.

But just how accessible are those backups? How surefire is your contingency plan? Have you tested it out? A lot of website administrators will find that actually initiating this plan isn’t as easy as it may seem. Those backups might take hours or days of ticketing and waiting to get a hold of, particularly if your website host is already inundated with other customer support issues. What then are you to do when something breaks and the site comes tumbling down?

Enter NodeSquirrel. NodeSquirrel is a Drupal backup service developed and maintained by Gorton Studios. It gives site admins control over their site backups. I sat down with Gorton Studios’ Drew Gorton and Keri Poeppe to learn why nonprofits should consider making NodeSquirrel a part of their workflow.

Stephanie: So what exactly is NodeSquirrel?

Keri: It’s a system for creating, managing, and securely storing website backups. Drupal developers out there will know the Backup and Migrate module. NodeSquirrel extends Backup and Migrate, allowing you to make backups of your website and store those backups in the cloud.

Drew: Backup and Migrate is one of the most popular modules in Drupal. One of the reasons it’s so popular is because it’s easy to create a backup. But by default, that backup stays on your server. What we’re trying to do with NodeSquirrel is make it easy to get that backup off of your server and move it somewhere safer - in this case, Amazon’s cloud. What makes NodeSquirrel such an integral addition to your regular hosting is that it’s something you can use whenever you need to access those backups. Getting to your web host’s backups and testing them can be difficult - and just because they’re backed up doesn’t mean they actually work. With NodeSquirrel, there are no surprises. You can get into your backups, make sure nothing is corrupted, and restore it yourself rather than wait on your host.

Stephanie: How does NodeSquirrel accomplish this?

Keri: NodeSquirrel is an off-site destination, but the process of getting the copy of your site uses the Backup and Migrate Module.

Drew: Here’s an example: there was a NodeSquirrel user whose site was being backed up daily by their web host. Unfortunately, that organization had a major failure and needed to restore the whole site, but the backups they received from their host were unusable. The host had to go back two months to find a backup that actually worked. And, this was from a hosting service costing at least $100 a month.

NodeSquirrel, luckily, was running on their site and they were able to use one of the backups stored on the cloud. It saved them. The problem is that no one ever tests hosting company backups. It’s stored by your host, but no one ever goes back and to check the integrity of the backup and figure out if it can be used when something goes wrong.

NodeSquirrel is different because it’s part of Drupal and the Drupal workflow. We’ve made it easy for you or your developer to retrieve and test your backups.

Stephanie: What sets NodeSquirrel apart for the competition? What sort of functionality can I expect from it?

Keri: It’s unique in that it makes a very specific kind of backup. It copies the database, code, and the files rather than making a backup of the whole server and all of the extra infrastructure. It’s not a lightweight backup, but it’s one that can be very targeted, and you can be more nimble with it. For example, if someone accidentally deletes a blog post or wipes out blocks on the homepage, you can quickly restore the website from a NodeSquirrel backup. You don’t need to spend lots of money or staff time recreating the blog post or home page! And you don’t need to call your hosting company to solve the problem. I think what distinguishes it from standard backup systems is how much control users have over the management of their backups. NodeSquirrel’s settings are managed in your site’s backend, so your website administrator has full control of your backup schedule and functions. Want to backup your site every hour? Go for it. Make the system as robust or as hands-off as you like. You can have that level of control and granularity.

Stephanie: How can I tell if my organization needs a service like NodeSquirrel? Is there such a thing as being "too small?"

Drew: It’s very affordable for anyone who’s invested time and money into their website and wants to safeguard that investment. The site is probably too valuable not to backup. We wanted to make this service accessible and affordable, so for about $100 a year, you’ll have this extra protection. Versus the time you spend trying to fix a bad backup, this is a better alternative. With that price point, it’s more of a question of "why not?"

Stephanie: It sounds like NodeSquirrel offers users a lot of options. Is there anything it won’t protect against? What doesn’t it do?

Drew: Most people ask how it compares to their standard hosting, since we have no direct competition. It’s not a full-server backup or a backup for a complex server. It doesn’t backup your DNS settings or load balance configuration. Typically though, if you have a complex setup, you’ll have a system admin or a disaster response team in your organization. Even if you do, NodeSquirrel might still be supplemental and helpful as an extra layer of protection.

Keri: If you can’t call your hosting company and see a backup, you might want to think about NodeSquirrel.

Drew: That’s actually a great way to test your site host. Call them and ask to access your backups. How long will it take? Will they charge you extra to set up a test environment?

Keri: Download and restore a backup. There’s your test to see if you can sleep easy at night. With NodeSquirrel, you can.

Stephanie: Is there anything else we should know about NodeSquirrel? Any tips for getting the most out of the service?

Keri: I’d stress the low threshold to use it. It requires no additional software. It’s integrated seamlessly, especially if Backup and Migrate is already installed. Ask your developers to install version 3 of Backup and Migrate. It’ll give you the most flexibility. NodeSquirrel is free to try, too. We have a trial offer that allows you to make 20 free backups. No credit card required.

Drew: We wanted to make it easy to do the right thing, and having onsite backup is the right thing. If it works, keep on going.

Our conclusion:

NodeSquirrel is a highly-affordable extra layer of protection that could save you and your stakeholders a major headache and a great deal of money in the event of a site meltdown. Even if your hosting provider has a backup solution, in the event of data loss, NodeSquirrel is a great alternative to sitting in support queues, waiting on your web host to resolve the issue.

With NodeSquirrel, you can take complete ownership of your backups and spare yourself the worry of whether or not you’ll be able to get your site up and running. It’s poised to integrate beautifully with your Drupal website administrative workflow, allowing you to safeguard your investment without having to spend time building new safety net systems. With plans starting at $9/month, it’s a question of "can you afford not to use NodeSquirrel?"

Want to see it in action for yourself? Sign up for the free trial. If you do take it for a spin, let us know what you think in the comments section.

Catégories: Elsewhere

Drupalfund.us: #D8Rules As a Proof that Drupal Community Is a Living Cell

Planet Drupal - jeu, 17/07/2014 - 11:28

When D8Rules project waiting in a Funding phase had just seven days left to be successfully funded, success didn’t seem likely. The project had raised just over 40% of its funding goal so far. The days shortened; the pressure rose. Happiness exploded exactly two days before the finish line thanks to the rescuing amount which came just in time.

The Biggest Nest of Funders So Far

We know that the Drupal Community is generous in donating money. They confirmed it again in the case of the ‘D8Rules - Support the Rules module for Drupal 8’ project. Together, 138 backers funded 106% of its funding goal. It equated to 15.973 dollars. With this number, D8Rules is, for the moment, the biggest project successfully funded onDrupalfund.us.

Public crowdfunding for D8Rules on Drupalfund started on May 13th. In one day, funders covered 8% of the funding goal already—quite good for a start. During the first two weeks the donating line grew and then it became static. The days were flowing away and more than a half of the final amount was still missing. What happened next?!

Catégories: Elsewhere

Juliana Louback: Contribute a JSCommunicator Translation

Planet Debian - jeu, 17/07/2014 - 10:06

To those who don’t know, JSCommunicator is a SIP communication tool developed in HTML and JavaScript, currently supporting audio/video calls and SIP SIMPLE instant messaging. We’ve recently added i18n internationalization support for English, Portuguese, Spanish, French and now Hebrew. We would like to have support for other languages and it’s a pretty straightforward process to add a translation, so even if you do not have a tech background you can contribute!

Setup

First, create and account in Github. Github is a hosting service for git repositories and open source projects get to use Github for FREE! As a result, many open source project repositories are hosted on Github, including but not limited to JSCommunicator.

Once you have created your git account, follow steps 1-4 in the section Setting up git listed in Github’s setup tutorial. This will help you install git and configure anything you need.

Fork

Now fork the JSCommunicator repo. I really like the word ‘fork’. Great term. If this is your first fork, know that this will make a copy of the JSCommunicator repo and all its respective code to your Github account. Here’s how we go about it:

  1. Sign in to Github

  2. Browse to https://github.com/JLouback/jscommunicator

  3. Somewhere around the upper left corner, you will see a button labeled ‘Fork’. Click that.

You should now have your own JSCommunicator repository on your Github account. On your main page select the tab ‘Repositories’. It should be the first on the list. The url will be https://github.com/YOUR-USERNAME/jscommunicator. My Github username is JLouback, so my jscommunicator repo can be found at https://github.com/JLouback/jscommunicator.

Clone

Now you should download all that code to your local machine so you can edit it. On your JSCommunicator page somewhere around the lower right corner you’ll see a field entitled HTTPS clone URL:

I don’t know if this is correct, but you can just copy the URL on your browser too. I do that.

Now on your terminal, navigate to the directory you’d like to place your repository and enter

git clone https://github.com/YOUR-USERNAME/jscommunicator

The current directory should now have a folder named ‘jscommunicator’ and in it is all the JSCommunicator code.

Switch branches

The JSCommunicator repo has a branch for the i18n support. A branch is basically a copy of the code that you can modify without changing the original code. It’s great for adding new features, once everything is done and tested you can add the new feature to the original code. A more detailed explanation of branches can be found here.

On the terminal, enter

cd jscommunicator git branch -a

This will list all the branches in the repository, both local and remote. There should be a branch named ‘remotes/origin/i18n-support’. Switch to this branch by entering

git checkout --track origin/i18n-support

This will create a local branch named i18n-support with all the contents of the remote i18n-branch in https://github.com/opentelecoms-org/jscommunicator.

Create a .properties file

Now your jscommunicator directory will have some new files for the internationalization functionality. Among them you should find an INTERNATIONALIZATION_README file with instructions for adding a JSCommunicator translation. It’s a less detailed version of this post, but it’s worth a read in case I’ve missed something here.

Go to the directory ‘internationalization’. You’ll see a few .properties files with different language codes. Choose the language of your preference for the translation base and make a copy of it in the internationalization directory. Your copy should be named ‘Messages_LANGUAGECODE.properties’. For example, the language code for german is ‘de’, so the german file should be named ‘Messages_de.properties’. If you’re not sure about the code for your language, please check out this list of ISO 639-1 language codes so you’re using the same code as (most) browsers.

The .properties file is list of key-value pairs, a word or a few words joined by ‘_’ which is the key, the equals sign ‘=’ then a word or phrase which is the value. Do not change anything to the left of the equals sign. Translate what is on the right of the equals sign.

Modify available_languages.xml

Go back to the root directory (jscommunicator) and open the file named ‘available_languages.ruby’. This .ruby has a series of language elements. At the end of the last ‘</language>’ add a new language element with your language display name and code, copying the previous languge elements. You actually can put your language element anwhere, as long as it’s after the ‘' and before the , as well as not cutting into any of the other language elements. Your display name should be the name of the language in its native language, for example for a french translation we’ll put ‘Français’ (I think). And the code is the code we used for the .properties file. Here’s how it should look:

<language> <display>Deutsch</display> <code>de</code> </language>

Save your changes and voila!

Test your work

Once you’ve made a .properties file, JSCommunicator will automatically load your translation if you’ve set your browser preference to that language. If your browser preference is french, it will load the Messages_fr.properties. If your browser preference is a language we don’t have a translation for (let’s say german), JScommunicator will load the default Messages.properties file which is in english.

The available_languages.ruby is used to build a language selection menu. If you add a language element without a corresponding .properties file, JSCommunicator will throw a JS error and load the default (english) translation. The same happens if you use different language codes in the .properties file name and the available_languages.ruby. The error won’t disturb your use of JSCommunicator, it just won’t load the language you selected. No harm, no foul. But if you want others to use your translation, do take care to do this correctly.

If you read the INTERNATIONALIZATION_README, you will have seen that we need the jquery.i18n.properties.js file that’s included in the .html pages. You can download that code here. Be sure to place it in the jscommunicator directory. This is only necessary if you want to see your addition at work, you don’t need this file to contribute your translation. There are other 3rd party code dependencies to run JSCommunicator too as you may have noticed. Just creating the .properties file and adding a language element to available_languages.ruby, if done correctly, is enough to make a pull request.

Commit

Here’s the part where we load all your local changes to your remote repository. In the terminal, navigate to the root directory (jscommunicator) and enter

git add internationalization/Messages_de.properties git add available_languages.ruby

Of course, please replace ‘Messages_de.properties’ with the name of your new .properties file. And mind you, we don’t have a german translation yet!

Then enter

git commit -m "German translation"

You can enter whatever you’d like in the “ “ part, it’s a good idea to explain what language you are adding. Now we can push the changes:

git push -u origin i18n-support

You should now see the changes you made in your Github account page at github.com/YOUR_USER/jscommunicator. The message you put in double quotations (“ “) in the commit will be beside each modified file. This push also creates a new branch in your jscommunicator repository, now you will have a ‘master’ and a ‘i18n-support’ branch.

Pull

Now it’s time to share your translation with everyone else if you feel so inclined. Your version of JSCommunicator has a new translation but not the official version. First navigate to you jscommunicator repo at github.com/YOUR_USER/jscommunicator and make sure you are on the i18n-branch as that will contain your changes.

Click the green button directly to the left of the branch drop down menu shown above. This will create a pull request to add your new code to the official jscommunicator code. Once you click that button, you should see this:

Make sure that the base repo (the first on the line above the green Create pull request button) is opentelecoms-org:i18n-support and not opentelecoms-org:master or another branch name. If it is, just click ‘Edit’ on the right and you’ll be able to select the branch from a dropdown like so:

If first repo is opentelecoms-org:i18n-support and the second is YOUR_USER:i18n-support and you’ve verified (scroll down) that there are 2 files changed which are your new .properties file and the added element to the available_languages.xml, go ahead and press create pull request. It’ll open a window with a text box you can add an explanation to with one final ‘Create pull request’ button. Click that and you’re done! You’ve kindly contributed with a translation for JSCommunicator!

Catégories: Elsewhere

Deeson Online: Deeson Online create Drupal 8 personas

Planet Drupal - jeu, 17/07/2014 - 06:30
Deeson Online create Drupal 8 personasBy Lizzie Hodgson | 17th July 2014

The momentum behind Drupal 8 is growing, and Deeson Online have been playing their part...

We in the Drupal community probably know something about Drupal 8 – even if it's just that we're aware it's coming!

But how do you clearly and simply highlight the benefits of Drupal 8 to a non-developer audience, or those beyond our community?

How can you then potentially create a non-dev community of Drupal 8 advocates and share good practice?

Introducing Drupal 8 personas What is a persona?

A persona is a ‘person' that represents a specific group of users.

Organisations and companies can use intel from personas to create, for example, 
a piece or pieces of content that will:

  • Highlight expectations and use of your site for your 
end user
  • Help drive the benefits in 
a way that will be immediately understood 
by the audience

Deeson Online have been working of a series of personas to help clearly articulate the benefits of Drupal 8.


How did we create Drupal 8 personas?

Using interviews with a range of Drupal and non-Drupal users, we got to grips with all the pain points for a range of potential Drupal 8 users. Using Dries Buytaert’s personas from his DrupalCon Prague Keynote speech as a starting point, we then focused on:

We then carried out a series of interviews via Skype and Google Hangouts asking people from across the globe from each of these user groups over 30 questions.

These questions ranged from "How many people work in the company?" to "From the time you wake up to the time you go to bed, what does a day in your working life look like?"

What did we do with the answers?

We then analysed all the responses, reducing them down to one 'persona' per user group, ensuring that we captured the persona needs and pain, then matching them against how Drupal 8 will help.

The result

A range of easy to consume dowloadable infographic persona fact sheets, that established and potential users can read and share.

The results so far have been really positive. The infographic personas are proving especially useful for those within our community to have something to refer to when talking not just about the power and benefits Drupal 8, but Drupal itself.

So learn more about Drupal 8, download the persona infographics and share the Drupal love!  
Catégories: Elsewhere

PreviousNext: Drupal continuous integration with Docker

Planet Drupal - jeu, 17/07/2014 - 03:03

Continuous integration platforms are a vital component of any development shop. We rely on it heavily to keep projects at the quality they deserve. Being early adopters of Docker (0.7.6) for our QA and Staging platform we thought it was time to take our CI environment to the next level!

Catégories: Elsewhere

Russ Allbery: wallet 1.1

Planet Debian - jeu, 17/07/2014 - 02:16

Wallet is the secure credential management infrastructure that we use at Stanford, primarily for keytabs but increasingly for any sort of security keys that have to be stored somewhere and retrieved by specific systems or people.

The primary goal of this release is to add Duo support. This is currently somewhat preliminary, with only a single Duo integration object type that creates a UNIX integration. (Well, technically it can create any type of integration, but the integration information is returned in the format expected by the UNIX integration.) I expect a later release to rename all existing "duo" object types to "duo-unix" and add additional object types for the various other types of integrations that one wants to support, but that work will have to wait for another day.

Since it's been over a year since the previous release, there are also other accumulated bug fixes and improvements. I also tried to merge or address as many issues or patches that had been sent to me over the past year as I could, although many larger patches or improvements had to be deferred. Highlights:

  • The owner and getacl commands now return the name of the ACL instead of its numeric ID, as they probably should have from the beginning.

  • The date passed to expires can now be in any format Date::Parse supports. (On a related note, Date::Parse is now required.)

  • wallet-rekey now works properly on keytabs containing multiple principals. I had for some reason assumed that one could form a keytab containing multiple principals by just concatenating several together, but that definitely does not work. wallet-rekey now appends new keys to the end of the existing keytab. Unfortunately, I didn't get a chance to implement purging of old keys, for the folks stuck with MIT Kerberos ktutil instead of Heimdal's.

There are also multiple other bug fixes and general improvements, such as using DateTime objects uniformly for all database access that involves date fields, and recording ACL renames in the ACL history table. Both the API and the database layer are still kind of a mess, and I'd love to rewrite them with the benefit of experience and more knowledge, but that's a project for another day.

You can get the latest release from the wallet distribution page.

Catégories: Elsewhere

Metal Toad: The Best Way to Learn Programming for Beginners

Planet Drupal - jeu, 17/07/2014 - 00:32

What is the best way to learn programming for beginners? I've spent a lot of time over the past 12 months thinking about this question, and as our firm has grown steadily from 19 to 39 people, I've reflected on what makes the difference between the people who walk in the door and knock things out of the park and those who struggle. Since my blog post on How to Become a Web Developer I have a number of people who regularly ask me this very question, I'd like to share my thoughts and observations.

Catégories: Elsewhere

Drupal core announcements: Core contact module roadmap

Planet Drupal - jeu, 17/07/2014 - 00:27
Background

Now that we have a new release cycle, we have the possibility of new features in minor releases, i.e. although we are in feature freeze for 8.0, that doesn't mean we can't add new features until 9.0. Provided they are backwards-compatible, we can add new features in 8.1 and 8.2.
After recently taking over maintainer-ship of the core contact module, @tim-e and I, in consultation with @andypost and @berdir have formulated a draft roadmap for the features we'd like to see in contact module in the future.
We're publishing it here for wider community-input.

High-level goal

To provide the 80% use-case of webform. i.e. allowing creation and submission of feedback forms from site-users; and providing editing, listing and administration of submitted form values.
Webform contains lots of features, we're only after expanding contact module slightly to add storage and administration and in the process meet the basic use-case of webform in core.
Note that some of these items are features and can be developed in contrib during 8.0 if required with the view to include in point releases eg 8.1, 8.2.

  1. Open issues
    1. Move subject/message fields to use widgets https://www.drupal.org/node/1856562
    2. Make contact message behave like normal entity https://www.drupal.org/node/2289063
    3. Rename contact category to form https://www.drupal.org/node/2285083
    4. Provide redirect option https://www.drupal.org/node/306662
  2. Key features/issues on roadmap
    1. Add (pluggable) storage of messages https://www.drupal.org/node/1856560 - we already have a test implementation of this (in a test module) in core, so it is already technically possible.
    2. Add views integration https://www.drupal.org/node/1856560
    3. Add admin listing of submissions w/ bulk actions to delete https://www.drupal.org/node/1856560
    4. Add ability to edit submissions
    5. Support for file-fields attached to emails - requires formatter for file-field.
    6. Ability to edit format of messages bodies including tokens
    7. Move email logic out of form submit handler to allow submission of messages via REST api that also send email
    8. Move email logic into own service and add events for other modules to interact
      1. Make email sending optional at category (form) level
    9. Path integration to allow simple alias management of contact categories
    10. Per contact-category permissions to allow granular access
    11. Provide a menu-link per category in a custom menu - auto builds menu of contact category links leveraging the menu link API to solve the category selector regression.
    12. Provide a configurable and themable block of selected contact forms. Probably needs views to query contact categories. https://www.drupal.org/node/1997692 and https://www.drupal.org/node/599770
Approach
Catégories: Elsewhere

Steve Kemp: So what can I do for Debian?

Planet Debian - mer, 16/07/2014 - 22:49

So I recently announced my intention to rejoin the Debian project, having been a member between 2002 & 2011 (inclusive).

In the past I resigned mostly due to lack of time, and what has changed is that these days I have more free time - primarily because my wife works in accident & emergency and has "funny shifts". This means we spend many days and evenings together, then she might work 8pm-8am for three nights in a row, which then becomes Steve-time, and can involve lots of time browsing reddit, coding obsessively, and watching bad TV (currently watching "Lost Girl". Shades of Buffy/Blood Ties/similar. Not bad, but not great.)

My NM-progress can be tracked here, and once accepted I have a plan for my activities:

  • I will minimally audit every single package running upon any of my personal systems.
  • I will audit as many of the ITP-packages I can manage.
  • I may, or may not, actually package software.

I believe this will be useful, even though there will be limits - I've no patience for PHP and will just ignore it, along with its ecosystem, for example.

As progress today I reported #754899 / CVE-2014-4978 against Rawstudio, and discussed some issues with ITP: tiptop (the program seems semi-expected to be installed setuid(0), but if it is then it will allow arbitrary files to be truncated/overwritten via "tiptop -W /path/to/file"

(ObRandom still waiting for a CVE identifier for #749846/TS-2867..)

And now sleep.

Catégories: Elsewhere

Drupal.org frontpage posts for the Drupal planet: Drupal 7.29 and 6.32 released

Planet Drupal - mer, 16/07/2014 - 22:37

Drupal 7.29 and Drupal 6.32, maintenance releases which contain fixes for security vulnerabilities, are now available for download. See the Drupal 7.29 and Drupal 6.32 release notes for further information.

Download Drupal 7.29
Download Drupal 6.32

Upgrading your existing Drupal 7 and 6 sites is strongly recommended. There are no new features or non-security-related bug fixes in these releases. For more information about the Drupal 7.x release series, consult the Drupal 7.0 release announcement. More information on the Drupal 6.x release series can be found in the Drupal 6.0 release announcement.

Security information

We have a security announcement mailing list and a history of all security advisories, as well as an RSS feed with the most recent security advisories. We strongly advise Drupal administrators to sign up for the list.

Drupal 7 and 6 include the built-in Update Status module (renamed to Update Manager in Drupal 7), which informs you about important updates to your modules and themes.

Bug reports

Both Drupal 7.x and 6.x are being maintained, so given enough bug fixes (not just bug reports) more maintenance releases will be made available, according to our monthly release cycle.

Changelog

Drupal 7.29 is a security release only. For more details, see the 7.29 release notes. A complete list of all bug fixes in the stable 7.x branch can be found in the git commit log.

Drupal 6.32 is a security release only. For more details, see the 6.32 release notes. A complete list of all bug fixes in the stable 6.x branch can be found in the git commit log.

Security vulnerabilities

Drupal 7.29 and 6.32 were released in response to the discovery of security vulnerabilities. Details can be found in the official security advisory:

To fix the security problem, please upgrade to either Drupal 7.29 or Drupal 6.32.

Known issues

None.

Front page news: Planet DrupalDrupal version: Drupal 6.xDrupal 7.x
Catégories: Elsewhere

Acquia: I Dream it and I Drupal it – My Acquia Story

Planet Drupal - mer, 16/07/2014 - 22:24

I have always been delighted at the prospect of a new beginning which weaves more threads on to it like spider as it goes on. Acquia internship came as this new beginning to me that I always thought of and dreamt of. I admired startups with challenging ideas and read more and more about the entrepreneurs, about their success stories and the way they reached to where they are now and still envisioning in future. I loved to read and analyze what challenges these young entrepreneurs faced and how they overcome it.

Catégories: Elsewhere

CivicActions: CivicActions is Hiring!

Planet Drupal - mer, 16/07/2014 - 21:06

10 years ago we set out to create a company like no other.

Our vision was that team members could work from anywhere, collaborate with brilliant people, build cutting edge technology for the greatest civic institutions on the planet, and have a strong sense of purpose. We have exceeded all our expectations and our success is enabling us to scale even more!

We truly believe that the way we do business is as important as the product we create. We're looking to add new team members who also value quality, diversity, flexibility, healthy work/life balance, humor and supporting one another. Working for CivicActions is more than just a job - it's working with a team of people who are committed to transforming the world. 

We believe that the best team is made from those that love what they do. 

If this sounds like a dream work environment, we encourage you to reach out and share your vision with us, and explore how we can make it a reality together.

Currently we are looking candidates to fill the following roles:

Senior Engineer / Tech Lead / Drupal Architect

Drupal Site Builder / Developer / Themer 

If you're full of positive energy, desire a strong sense of community, looking for meaning and significance in your work, and crave opportunities to do what you do best, we'd love to talk!

Topics
Catégories: Elsewhere

Mediacurrent: Upcoming Webinar: Improve the ROI of Your Drupal Site

Planet Drupal - mer, 16/07/2014 - 20:01

Companies are seeing lower success rates on social media and diminishing conversion rates on the web - a trend that has put us all, especially content marketers, in the position to prove the ROI or face severe fiscal cuts. Unfortunately, reporting metrics like “increased impressions” and “better brand awareness” won’t be enough because companies are looking for hard before/after numbers.

Catégories: Elsewhere

Freelock : Performance problem: N! database calls

Planet Drupal - mer, 16/07/2014 - 18:34

Kicking off some posts about various performance challenges we've fixed.

N Factorial

During a code review for a site we were taking over, I found this little gem:

<?php

function charity_view_views_pre_render($view) {
  // this code takes the rows returned from a view query after the query has been run, and formats it for display...
  // snip to the code of interest:
  usort($view->result, 'charity_view_sort_popular');
}

PerformanceTechnicalDrupalDrupal Planet
Catégories: Elsewhere

Drupal Association News: How Your Membership Gives Back to the Community

Planet Drupal - mer, 16/07/2014 - 17:05

When people ask me, “What’s Drupal?” I find it a complex answer. Of course, in a technical sense, Drupal is a CMS— but to me, and to many others, it’s far more than that. It’s a community full of amazing people with inspiring leaders and huge hearts.

At DrupalCon Austin, I was able to share several stories about community members who really pushed the project further, all with the help of community cultivation grants selected and financed by the men and women who love Drupal. I want to thank Gabor, Sheng, and Tatiana for letting me share their stories and I'd like to share these stories with all of you.

Drupal Dev Days: A Week of Sprints in Szeged

Earlier this year, Gábor Hojtsy organized a dev days event that was a huge success. From March 24 to March 30 this year, three hundred people gathered in Szeged to sprint together on Drupal 8 core, Drupal 8 Search and Entity Field API, Documentation, Migration, MongoDB, REST and authentication, Rules for Drupal 8 and, of course, Drupal.org.

There was so much happening, they almost brought D.O to a halt— but fortunately, everything came out OK, and we had huge improvements to Drupal.org as a result.

There were big benefits to Drupal 8 at Szeged, too. Some of the things that our great sprinters accomplished were:

  •  115 core commits with 706 files changed, 10967 insertions(+), 6849 deletions(-)
  •  19 beta blocker and beta target issues fixed

It was the community that made Dev Days Szeged so great. By turning out and sprinting, they made big improvements to the project, while a community development grant funded part of the Internet fees. It's an important element of any sprint, but the real significance is that Drupal Association members who could not attend the sprints or are not in a role to contribute code were still able to help achieve this success by funding it through their membership.

DrupalCamp Shanghai

Sheng is the community leader of the Shanghai community, and as an ex-New Yorker, he knew firsthand how important Drupal meetups and camps are for networking and learning. After he moved to Shanghai, he decided that he wanted to share the valuable experience of face-to-face time with his new local community, which had skilled developers who were mostly disconnected from each other and the wider global community.

After building momentum through holding a number of meet ups, Sheng applied for grants in 2013 and 2014 to put on a Shanghai Drupal camp. With the funds, he flew in a Drupal Rock Star to come keynote each of the camps — Forest Mars and John Albin — and the camp doubled in size and there are now hundreds of people who come out to these camps.

While the investment of flying John Albin out to Shanghai from Taiwan was relatively small, the impact and ROI was huge both for the camps and for the greater Drupal community: camp attendees learned to contribute back to the larger global community, almost like a small R&D investment. It wouldn’t have been possible without a community grant.

DrupalCamp Donetsk

Tatiana of the Drupal Association worked with her colleagues in Donetsk to put together a DrupalCamp in Donetsk, in spite of the revolution. A lot of people came together and connected both to each other and to the global community, and used a grant to pay for the food and coffee— and for us at the Association, that grant stands as a sign of positive support from the greater Drupal community in spite of the strife that was going on in Donetsk.

In the end, lots of thanks needs to go around. First, I’d like to thank Gabor, Sheng and Tatiana and all community leaders for turning your vision into reality and for the time and passion you pour into Drupal. We are appreciate all that you do to unite and grow Drupal.

Secondly, none of this would be possible without the three community leaders who manage the volunteer program: Mike Anello, Amy Scarvada, and Thomas Turnbull. Your passion for growing the community is doing great things.

Finally, I want to issue a big thank you to our Drupal Association Members for making these stories a reality. If you want to be come a member and help more of these programs around the world come to life, please sign up today at https://assoc.drupal.org/membership.

Catégories: Elsewhere

Matthias Klumpp: AppStream 0.7 specification and library released

Planet Debian - mer, 16/07/2014 - 17:03

Today I am very happy to announce the release of AppStream 0.7, the second-largest release (judging by commit number) after 0.6. AppStream 0.7 brings many new features for the specification, adds lots of good stuff to libappstream, introduces a new libappstream-qt library for Qt developers and, as always, fixes some bugs.

Unfortunately we broke the API/ABI of libappstream, so please adjust your code accordingly. Apart from that, any other changes are backwards-compatible. So, here is an overview of what’s new in AppStream 0.7:

Specification changes

Distributors may now specify a new <languages/> tag in their distribution XML, providing information about the languages a component supports and the completion-percentage for the language. This allows software-centers to apply smart filtering on applications to highlight the ones which are available in the users native language.

A new addon component type was added to represent software which is designed to be used together with a specific other application (think of a Firefox addon or GNOME-Shell extension). Software-center applications can group the addons together with their main application to provide an easy way for users to install additional functionality for existing applications.

The <provides/> tag gained a new dbus item-type to expose D-Bus interface names the component provides to the outside world. This means in future it will be possible to search for components providing a specific dbus service:

$ appstream-index what-provides dbus org.freedesktop.PackageKit.desktop system

(if you are using the cli tool)

A <developer_name/> tag was added to the generic component definition to define the name of the component developer in a human-readable form. Possible values are, for example “The KDE Community”, “GNOME Developers” or even the developer’s full name. This value can be (optionally) translated and will be displayed in software-centers.

An <update_contact/> tag was added to the specification, to provide a convenient way for distributors to reach upstream to talk about changes made to their metadata or issues with the latest software update. This tag was already used by some projects before, and has now been added to the official specification.

Timestamps in <release/> tags must now be UNIX epochs, YYYYMMDD is no longer valid (fortunately, everyone is already using UNIX epochs).

Last but not least, the <pkgname/> tag is now allowed multiple times per component. We still recommend to create metapackages according to the contents the upstream metadata describes and place the file there. However, in some cases defining one component to be in multiple packages is a short way to make metadata available correctly without excessive package-tuning (which can become difficult if a <provides/> tag needs to be satisfied).

As small sidenote: The multiarch path in /usr/share/appdata is now deprecated, because we think that we can live without it (by shipping -data packages per library and using smarter AppStream metadata generators which take advantage of the ability to define multiple <pkgname/> tags)

Documentation updates

In general, the documentation of the specification has been reworked to be easier to understand and to include less duplication of information. We now use excessive crosslinking to show you the information you need in order to write metadata for your upstream project, or to implement a metadata generator for your distribution.

Because the specification needs to define the allowed tags completely and contain as much information as possible, it is not very easy to digest for upstream authors who just want some metadata shipped quickly. In order to help them, we now have “Quickstart pages” in the documentation, which are rich of examples and contain the most important subset of information you need to write a good metadata file. These quickstart guides already exist for desktop-applications and addons, more will follow in future.

We also have an explicit section dealing with the question “How do I translate upstream metadata?” now.

More changes to the docs are planned for the next point releases. You can find the full project documentation at Freedesktop.

AppStream GObject library and tools

The libappstream library also received lots of changes. The most important one: We switched from using LGPL-3+ to LGPL-2.1+. People who know me know that I love the v3 license family of GPL licenses – I like it for tivoization protection, it’s explicit compatibility with some important other licenses and cosmetic details, like entities not loosing their right to use the software forever after a license violation. However, a LGPL-3+ library does not mix well with projects licensed under other open source licenses, mainly GPL-2-only projects. I want libappstream to be used by anyone without forcing the project to change its license. For some reason, using the library from proprietary code is easier than using it from a GPL-2-only open source project. The license change was also a popular request of people wanting to use the library, so I made the switch with 0.7. If you want to know more about the LGPL-3 issues, I recommend reading this blogpost by Nikos (GnuTLS).

On the code-side, libappstream received a large pile of bugfixes and some internal restructuring. This makes the cache builder about 5% faster (depending on your system and the amount of metadata which needs to be processed) and prepares for future changes (e.g. I plan to obsolete PackageKit’s desktop-file-database in the long term).

The library also brings back support for legacy AppData files, which it can now read. However, appstream-validate will not validate these files (and kindly ask you to migrate to the new format).

The appstream-index tool received some changes, making it’s command-line interface a bit more modern. It is also possible now to place the Xapian cache at arbitrary locations, which is a nice feature for developers.

Additionally, the testsuite got improved and should now work on systems which do not have metadata installed.

Of course, libappstream also implements all features of the new 0.7 specification.

With the 0.7 release, some symbols were removed which have been deprecated for a few releases, most notably as_component_get/set_idname, as_database_find_components_by_str, as_component_get/set_homepage and the “pkgname” property of AsComponent (which is now a string array and called “pkgnames”). API level was bumped to 1.

Appstream-Qt

A Qt library to access AppStream data has been added. So if you want to use AppStream metadata in your Qt application, you can easily do that now without touching any GLib/GObject based code!

Special thanks to Sune Vuorela for his nice rework of the Qt library!

And that’s it with the changes for now! Thanks to everyone who helped making 0.7 ready, being it feedback, contributions to the documentation, translation or coding. You can get the release tarballs at Freedesktop. Have fun!

Catégories: Elsewhere

Dirk Eddelbuettel: Introducing RcppParallel: Getting R and C++ to work (some more) in parallel

Planet Debian - mer, 16/07/2014 - 16:56
A common theme over the last few decades was that we could afford to simply sit back and let computer (hardware) engineers take care of increases in computing speed thanks to Moore's law. That same line of thought now frequently points out that we are getting closer and closer to the physical limits of what Moore's law can do for us.

So the new best hope is (and has been) parallel processing. Even our smartphones have multiple cores, and most if not all retail PCs now possess two, four or more cores. Real computers, aka somewhat decent servers, can be had with 24, 32 or more cores as well, and all that is before we even consider GPU coprocessors or other upcoming changes.

And sometimes our tasks are embarassingly simple as is the case with many data-parallel jobs: we can use higher-level operations such as those offered by the base R package parallel to spawn multiple processing tasks and gather the results. I covered all this in some detail in previous talks on High Performance Computing with R (and you can also consult the Task View on High Performance Computing with R which I edit).

But sometimes we can't use data-parallel approaches. Hence we have to redo our algorithms. Which is really hard. R itself has been relying on the (fairly mature) OpenMP standard for some of its operations. Luke Tierney's (awesome) keynote in May at our (sixth) R/Finance conference mentioned some of the issues related to OpenMP. One which matters is that OpenMP works really well on Linux, and either not so well (Windows) or not at all (OS X, due the usual issue with the gcc/clang switch enforced by Applem but the good news is that the OpenMP toolchain is expected to make it to OS X is some more performant form "soon"). R is still expected to make wider use of OpenMP in future versions.

Another tool which has been around for a few years, and which can be considered to be equally mature is the Intel Threaded Building Blocks library, or TBB. JJ recently started to wrap this up for use by R. The first approach resulted in a (now superseded, see below) package TBB. But hardware and OS issues bite once again, as the Intel TBB is not really building that well for the Windows toolchain used by R (and based on MinGW).

(And yes, there are two more options. But Boost Threads requires linking which precludes easy use as e.g. via our BH package. And C++11 with its threads library (based on Boost Threads) is not yet as widely available as R and Rcpp which means that it is not a real deployment option yet.)

Now, JJ, being as awesome as he is, went back to the drawing board and integrated a second threading toolkit: TinyThread++, a small header-only library without further dependencies. Not as feature-rich as Intel Threaded Building Blocks, but at least available everywhere. So a new package RcppParallel, so far only on GitHub, wraps around both TinyThread++ and Intel Threaded Building Blocks and offers a consistent interface available on all platforms used by R.

Better still, JJ also authored several pieces demonstrating this new package for the Rcpp Gallery:

All four are interesting and demonstrate different aspects of parallel computing via RcppParallel. But the last article is key. Based on a question by Jim Bullard, and then written with Jim, it shows how a particular matrix distance metric (which is missing from R) can be implemented in a serial manner in both R, and also via Rcpp. The key implementation, however, uses both Rcpp and RcppParallel and thereby achieves a truly impressive speed gain as the gains from using compiled code (via Rcpp) and from using a parallel algorithm (via RcppParallel) are multiplicative! Between JJ's and my four-core machines the gain was between 200 and 300 fold---which is rather considerable. For kicks, I also used a much bigger machine at work which came in at an even larger speed gain (but gains become clearly sublinear as the number of cores increases; there are however some tuning parameters).

So these are exciting times. I am sure there will be lots more to come. For now, head over to the RcppParallel package and start playing. Further contributions to the Rcpp Gallery are not only welcome but strongly encouraged.
Catégories: Elsewhere

Acquia: Drupal for Digital Commerce – Bojan Živanović

Planet Drupal - mer, 16/07/2014 - 14:49

Bojan and I chatted at Drupal Dev Days 2014 about one of the newest and most important weapons available in Drupal's eCommerce arsenal: recurring billing for digital commerce in Drupal Commerce.

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur - Elsewhere