Agrégateur de flux

Don Armstrong: H3ABioNet Hackathon (Workflows)

Planet Debian - mer, 24/08/2016 - 16:40

I'm in Pretoria, South Africa at the H3ABioNet hackathon which is developing workflows for Illumina chip genotyping, imputation, 16S rRNA sequencing, and population structure/association testing. Currently, I'm working with the imputation stream and we're using Nextflow to deploy an IMPUTE-based imputation workflow with Docker and NCSA's openstack-based cloud (Nebula) underneath.

The OpenStack command line clients (nova and cinder) seem to be pretty usable to automate bringing up a fleet of VMs and the cloud-init package which is present in the images makes configuring the images pretty simple.

Now if I just knew of a better shared object store which was supported by Nextflow in OpenStack besides mounting an NFS share, things would be better.

You can follow our progress in our git repo: [https://github.com/h3abionet/chipimputation]

Catégories: Elsewhere

Mediacurrent: "Shrop" Talk at Drupal Camp Asheville 2016

Planet Drupal - mer, 24/08/2016 - 15:55

On August 13th, I had the pleasure of enjoying another Drupal Camp Asheville. This has become one of my favorite Drupal camps because of the location and quality of camp organization. It has the right balance of structure, while maintaining a grassroots feel that encourages open discussion and sharing.

Catégories: Elsewhere

Drupal Bits at Web-Dev: Hook Update Deploy Tools: Node import FAQs

Planet Drupal - mer, 24/08/2016 - 15:12

Using the Drupal module Hook Update Deploy Tools to move node content  can be an important part to a deployment strategy. 

What is the unique ID that connects an export to an import?

To create the export file, the node id is used to create the file.  After that, the filename and 'unique id' references the alias of that node.  So when you import the node, the node id on the production site will be determined by looking up the alias of the node.  If a matching alias is found, that is the node that gets updated.  If no matching alias is found, a new node gets created.  The alias becomes the unique id.

What are the risks of this import export model?

At present the known risks are:

  1. If the exported node uses entity references that do not exist on prod, the entity reference will either not be made, or reference an entity that is using that entity id on prod.  This can be mitigated by exporting your source node while using a recent copy of the production DB.
  2. If the exported node uses taxonomy terms that do not exist on prod, the tag may import incorrectly. This can be mitigated by exporting your source node while using a recent copy of the production DB.
  3. if you are using pathato and the existing pattern on the production site is different than the pattern on your sandbox.  The imported node will end up with a different alias, resulting in an invalid import.  The imported node will be deleted since it failed validation and the hook_update_N will fail. This can be mitigated by exporting your source node while using a recent copy of the production DB.
  4. File attachments.  There is currently not a way to bring attached files along with them unless the files already exist with a matching fid on production.
What if I am using an entity reference or a taxonomy that does not exist on production?

See answers 1 and 2 in What are the risks of this import export model?

Does the import show up as a revision?

Yes it does, and the revison note contains the imported note, but also indicates it was imported with Hook Update Deploy Tools.  The revision will take on the status of the exported node.  If the exported node was unpublished, the impoirted revision will be unpublished.

What happens if the import does not validate?

If the import was to an existing node, the update revision wil be deleted and return the node to its last published revision.  If the import was for a node that did not exist on the site, the node and its first revision will be deleted.  In either case, if the import was run through a hook_update_N, that update will fail and allow it to be re-run once the issue is resolved.

What if the alias or path is already in use by another node?

If the alias is in use by a node, that node will be updated by the import.  The alias is the unique id that links them not the nid.

What if the alias or path is already in use by a View or used by a menu router?

If the alias is in use on the site by something other than a node, the import will be prevented.  If the import is being run by a hook_update_N() then the update will fail and can be run when the issue is resolved.

Is there a limit to the number of nodes that can be imported this way?

Technically, there is no real limit.  Realistically, it is not a great workflow to move all of your content this way.  It is not a good workflow.  This export import method is best reserved for mission critical pages like forms or thankyou pages that go along with a Feature deployment.  It is also good for pages that often get destroyed during early site development like style guides and example pages.

Catégories: Elsewhere

WDTutorials.com: Drupal 8 Tutorial #43 : Twig Tweak Module (Article + Video)

Planet Drupal - mer, 24/08/2016 - 15:00

Twig Tweak module adds some useful functions and filters to use in templates.

Catégories: Elsewhere

DrupalEasy: DrupalEasy Podcast 184 - PMA (Marc Drummond - Next Steps in Drupal Theming)

Planet Drupal - mer, 24/08/2016 - 14:54

Direct .mp3 file download.

Marc Drummond (mdrummond), Front-end developer at Lullabot, Drupal core contributor, and self-processed Star Wars expert joins Kelley and Mike to discuss all the things the Drupal front-end community has been talking about lately. We also discuss the next major version of Drupal, whether or not a major Drupal contrib module will be deprecated, as well as our picks of the week.

Interview DrupalEasy News Three Stories
  1. Proposal: Deprecate Field Collections for Drupal 8, focus on Entity Reference Revisions & Paragraphs.
  2. The Average Web Page (Data from Analyzing 8 Million Websites).
  3. There will never be a Drupal 9 vs. There will be a Drupal 9, and here is why.
Sponsors Picks of the Week Upcoming Events Follow us on Twitter Five Questions (answers only)
  1. Disney
  2. Docker for Mac
  3. Writing a fantasy novel
  4. Llama
  5. DrupalCamp Twin Cities
Intro Music
  • Chunk-y Town - performed by Marc Drummond at Twin Cities DrupalCamp 2016.
Subscribe

Subscribe to our podcast on iTunes, Google Play or Miro. Listen to our podcast on Stitcher.

If you'd like to leave us a voicemail, call 321-396-2340. Please keep in mind that we might play your voicemail during one of our future podcasts. Feel free to call in with suggestions, rants, questions, or corrections. If you'd rather just send us an email, please use our contact page.

Catégories: Elsewhere

Gábor Hojtsy: Want to get issues resolved in Drupal core? Find community with an initiative!

Planet Drupal - mer, 24/08/2016 - 14:36

In my previous post I explained why there will be a Drupal 9 even though we have previously unseen possibilities to add new things within Drupal 8.x.y. Now I'd like to dispel another myth, that initiatives are only there to add those new things.

Drupal 8 introduced initiatives to the core development process with the intention that even core development became too big to follow, understand or really get involved with in general. However because there are key areas that people want to work in, it makes sense to set up focused groups to organize work in those areas and support each other in those smaller groups. So initiatives like Configuration Management, Views in Core, Web Services, Multilingual, etc. were set up and mostly worked well, not in small part because it is easier to devote yourself to improving web services capabilities or multilingual support as opposed to "make Drupal better". Too abstract goals are harder to sign up for, a team with a thousand people is harder to feel a member of.

Given the success of this approach, even after the release of Drupal 8.0.0, we continued using this model and there are now several groups of people working on making things happen in Drupal 8.x. Ongoing initiatives include API-first, Media, Migrate, Content Workflows and so on. Several of these are primarily working on fixing bugs and plugging holes. A significant part of Migrate and API-first work to date was about fixing bugs and implementing originally intended functionality for example.

The wonder of these initiatives is they are all groups of dedicated people who are really passionate about that topic. They not only have plan or meta issues linked in the roadmap but also have issue tags and have regular meeting times. The Drupal 8 core calendar is full of meetings happening almost every single workday (that said, somehow people prefer Wednesdays and avoid Fridays).

If you have an issue involving usability, a bug with a Drupal web service API, a missing migration feature and so on, your best choice is to bring it to the teams already focused on the topics. The number and diverse areas of teams already in place gives you a very good chance that whatever you are intending to work on is somehow related to one or more of them. And since no issue will get done by one person (you need a reviewer and a committer at minimum), your only way to get something resolved is to seek interested parties as soon as possible. Does it sound like you are demanding time from these folks unfairly? I don't think so. As long as you are genuinely interested to solve the problem at hand, you are in fact contributing to the team which is for the benefit of everyone. And who knows, maybe you quickly become an integral team member as well.

Thanks for contributing and happy team-match finding!

Ps. If your issue is no match for an existing team, the friendly folks at #drupal-contribute in IRC are also there to help.

Catégories: Elsewhere

Zyxware Technologies: [Drupal-8] How to send a mail programmatically in Drupal-8

Planet Drupal - mer, 24/08/2016 - 14:33

This article covers, how to send email programmatically in your Drupal 8 site. There are two main steps to send an email using Drupal 8. First we need to implement hook_mail() to define email templates and the second step is to use the mail manager to send emails using these templates. Let's see an example for sending an email from the custom module, also the following name spaces.

DrupalDrupal 8Drupal Planet
Catégories: Elsewhere

Unimity Solutions Drupal Blog: Identification of an Open Source Video Annotations Tool for NVLI

Planet Drupal - mer, 24/08/2016 - 14:00

As mentioned in our earlier blog on Video Annotations: A powerful and innovative tool for education, the most intriguing feature of the pilot version of NVLI is Video Annotation. UniMity Solutions assisted in building Annotation feature for Audio and Video assets. This involved identifying and integrating an open plugin that supported video and audio annotations and a generic annotation store module that was plugin agnostic.

Catégories: Elsewhere

Zlatan Todorić: Take that boredom

Planet Debian - mer, 24/08/2016 - 07:45

While I was bored on Defcon, I took the smallest VPS in DO offering (512MB RAM, 20GB disk), configured nginx on it, bought domain zlatan.tech and cp'ed my blog data to blog.zlatan.tech. I thought it will just be out of boredom and tear it apart in a day or two but it is still there.

Not only that, the droplet came with Debian 8.5 but I just added unstable and experimental to it and upgraded. Just to experiment and see what time will I need to break it. To make it even more adventurous (and also force me to not take it too much serious, at least at this point) I did something on what Lars would scream - I did not enable backups!

While having fun with it I added letsencrypt certificate to it (wow, that was quite easy).

Then I installed and configured Tor. Ende up adding an .onion domain for it! It is: pvgbzphm622hv4bo.onion

My main blog is still going to be zgrimshell.github.io (for now at least) where I push my Nikola (static site generator written in python) generated content as git commits. To my other two domains (on my server) I just rsync the content now. Simple and efficient.

I must admit I like my blog layout. It is simple, easy to read, efficient and fast, I don't bother with comments and writing a blog in markdown (inside terminal as all good behaving hacker citizen) while compiling it with Nikola is breeze (and yes, I did choose Nikola because of Nikola Tesla and python). Also I must admit that nginx is pretty nice webserver, no need to explain the beauty of git but I can't recommend enough of rsync.

If anyone is interested in doing the same I am happy to talk about it but these tools are really simple (as I enjoy simple things and by simple I mean small tools, no complicated configs and easy execution).

Catégories: Elsewhere

Drupal Bits at Web-Dev: Import nodes as as part of deployment using Hook Update Deploy Tools

Planet Drupal - mer, 24/08/2016 - 05:52

With the 7.x-1.18 release of Hook Update Deploy Tools for Drupal 7 it is now possible to export a node on a development sandbox, commit the export file to the repository, then import it using either a hook_update_N() or using drush site-deploy-import node

Pros:

  • No need to re-create a node on prod after a client approves it.
  • Early content that keeps getting wiped out by database snapshots (think style guides) can get re-created instantly with a single drush command.
  • Content imported into an existing node shows up as a revision.
  • Atomated deployment is testable and repeatable on all dev environments.
  • No uuid required.
Workflow Example:

You have a styleguide you created on your sandbox and want to deploy it to the production site.

  1.  Create the node on your sandbox (node id = 1234).
  2. Export the node to an export file.
    drush site-deploy-export 1234
  3. The command created an export file named  for the alias of the node being exported
    ex: site-deploy/node_source/helpzZzstyle-guide.txt  ('zZz' represents '/')
  4. Create a hook_update_N() to import the file on deployment
     

    <?php
    /**
     * Import a the style guide
     */
    function site_deploy_update_7129() {
      $nodes = array('help/style-guide');
      $message = HookUpdateDeployTools\Nodes::import($nodes);
      return $message;
    }
    ?>
  5. Commit the file and update hook to your repo.
  6. Push the code, run 'drush updb'
drush updb -y
Site_deploy  7129  Import a the style guide

Site_deploy: Updated: node/1234: help/style-guide - successful.
Summary: Imported Nodes 1/1.  Completed the following:
   [help/style-guide] => Updated: node/1234
  
Performed update: site_deploy_update_7129

or the import can be performed by

drush site-deploy-import  help/style-guide
Catégories: Elsewhere

Drupal @ Penn State: Drupal 8 Theme Generation and Development Intro Using the Drupal Console

Planet Drupal - mer, 24/08/2016 - 01:56

Here is a screen cast of how to get started with Drupal 8 theme development.

In the video I cover:

  • using the drupal console to generate a theme from a base theme
  • creating a libraries yml file
  • adding global css to your theme
  • Using Kint with the devel module
  • debugging twig
  • adding your own twig file to your theme
Catégories: Elsewhere

Drupal @ Penn State: Lower the Drupal 8 development barrier to entry by using the Drupal Console to generate boiler plate code.

Planet Drupal - mer, 24/08/2016 - 01:56

I admit that I haven't really looked at Drupal 8 too much yet. There is a variety of reasons why I haven't and I surely don't want this to turn into a forum listing the pros and cons of D8. We can leave that for another post. 

Catégories: Elsewhere

Drupal @ Penn State: The Care and Feeding of Your Website

Planet Drupal - mer, 24/08/2016 - 01:56

A question on the PSU DUG Slack channel got me thinking. How is it that websites are still being constructed at Penn State without any thought being put in as to how its is going to be maintained? Or by whom?  

To be clear, I am not talking about content creation or maintenance, but maintaining the code/server/DB/etc. that supports or runs the site? Or to develop new features and functionality, going beyond just updating code or applying security patches. Of course, this is not restricted to Drupal development - there are many other examples.

Catégories: Elsewhere

PreviousNext: Introducing Drush CMI tools

Planet Drupal - mer, 24/08/2016 - 01:46

Now we've got the experience of a number of production D8 sites under our belt we took the time to consolidate our CMI workflow into some useful drush commands.

And naturally we've open sourced them.

Read on to find out more about our drush CMI tools.

Catégories: Elsewhere

GVSO Blog: [GSoC 2016: Social API] Week 13: Thanks GSoC!

Planet Drupal - mer, 24/08/2016 - 00:07
[GSoC 2016: Social API] Week 13: Thanks GSoC! Submitted by gvso on Tue, 08/23/2016 - 18:07

Students' final evaluations is over, and only mentors' evaluations is left. During these months, I have been working on projects to harmonize social networking functionality in Drupal and documenting them. Notwithstanding, the Social API project started as an idea for a framework in fact, the main components provide extensible functionality. Therefore, I documented the process of creating new implementers.

Tags Drupal Drupal Planet GSoC 2016
Catégories: Elsewhere

Roy Scholten: UX meeting recap

Planet Drupal - mar, 23/08/2016 - 23:58

Two meetings every week since end of march this year. Safe to say we’ve found a consistent rhythm.

And it’s working. It’s become a useful way to check in on current priorities, review patches while screensharing (visuals, transitions, flows!), decide on next steps and generally discuss hard problems without having to type so much.

The agenda for today was
  1. Roadmap – The core roadmap was updated to current state of things. Use this page to get a bird’s eye view on where Drupal core is moving towards.
  2. Ideation process – The first part of going from idea to plan got positive feedback and helpful questions and suggestions. Maybe a few words from actual maintainers and then we can make it so.
  3. Status page – We have a beautiful new design that now needs review and more code to create a complete patch. If you know your core markup and CSS, go have a look!
  4. Block place design update – An issue that iterates the design of an initial commit. We quickly discussed what the feedback should be and I added a comment to that effect right then and there. It’s an example of managing scope, pushing to focus on the actual fix first, and defer new, potentially good ideas to a followup discussion.
  5. Sample content – Kevin shared his initial thoughts and ideas for adding sample content, structure and configuration to core. More questions then answers but that’s just where we’re at for now. You are welcome to add your questions and ideas, please do.

As always, most welcome to join if you’re interested. Find us in the ux channel of the Drupal Slack room, or follow @drupalux on the twitters.

Tags: drupaluxuxmeetingdrupalplanetSub title: Topics du jour, how we work, where you can help, the usual
Catégories: Elsewhere

Drupal Blog: Drupal 8.2, now with more outside-in

Planet Drupal - mar, 23/08/2016 - 21:14

Over the weekend, Drupal 8.2 beta was released. One of the reasons why I'm so excited about this release is that it ships with "more outside-in". In an "outside-in experience", you can click anything on the page, edit its configuration in place without having to navigate to the administration back end, and watch it take effect immediately. This kind of on-the-fly editorial experience could be a game changer for Drupal's usability.

When I last discussed turning Drupal outside-in, we were still in the conceptual stages, with mockups illustrating the concepts. Since then, those designs have gone through multiple rounds of feedback from Drupal's usability team and a round of user testing led by Cheppers. This study identified some issues and provided some insights which were incorporated into subsequent designs.

Two policy changes we introduced in Drupal 8—semantic versioning and experimental modules—have fundamentally changed Drupal's innovation model starting with Drupal 8. I should write a longer blog post about this, but the net result of those two changes is ongoing improvements with an easy upgrade path. In this case, it enabled us to add outside-in experiences to Drupal 8.2 instead of having to wait for Drupal 9. The authoring experience improvements we made in Drupal 8 are well-received, but that doesn't mean we are done. It's exciting that we can move much faster on making Drupal easier to use.

In-place block configuration

As you can see from the image below, Drupal 8.2 adds the ability to trigger "Edit" mode, which currently highlights all blocks on the page. Clicking on one — in this case, the block with the site's name — pops out a new tray or sidebar. A content creator can change the site name directly from the tray, without having to navigate through Drupal's administrative interface to theme settings as they would have to in Drupal 7 and Drupal 8.1.

Making adjustments to menus

In the second image, the pattern is applied to a menu block. You can make adjustments to the menu right from the new tray instead of having to navigate to the back end. Here the content creator changes the order of the menu links (moving "About us" after "Contact") and toggles the "Team" menu item from hidden to visible.

In-context block placement

In Drupal 8.1 and prior, placing a new block on the page required navigating away from your front end into the administrative back end and noting the available regions. Once you discover where to go to add a block, which can in itself be a challenge, you'll have to learn about the different regions, and some trial and error might be required to place a block exactly where you want it to go.

Starting in Drupal 8.2, content creators can now just click "Place block" without navigating to a different page and knowing about available regions ahead of time. Clicking "Place block" will highlight the different possible locations for a block to be placed in.

Next steps

These improvements are currently tagged "experimental". This means that anyone who downloads Drupal 8.2 can test these changes and provide feedback. It also means that we aren't quite satisfied with these changes yet and that you should expect to see this functionality improve between now and 8.2.0's release, and even after the Drupal 8.2.0 release.

As you probably noticed, things still look pretty raw in places; as an example, the forms in the tray are exposing too many visual details. There is more work to do to bring this functionality to the level of the designs. We're focused on improving that, as well as the underlying architecture and accessibility. Once we feel good about how it all works and looks, we'll remove the experimental label.

We deliberately postponed most of the design work to focus on introducing the fundamental concepts and patterns. That was an important first step. We wanted to enable Drupal developers to start experimenting with the outside-in pattern in Drupal 8.2. As part of that, we'll have to determine how this new pattern will apply broadly to Drupal core and the many contributed modules that would leverage it. Our hope is that once the outside-in work is stable and no longer experimental, it will trickle down to every Drupal module. At that point we can all work together, in parallel, on making Drupal much easier to use.

Users have proven time and again in usability studies to be extremely "preview-driven", so the ability to make quick configuration changes right from their front end, without becoming an expert in Drupal's information architecture, could be revolutionary for Drupal.

If you'd like to help get these features to stable release faster, please join us in the outside-in roadmap issue.

Thank you

I'd also like to thank everyone who contributed to these features and reviewed them, including Bojhanyoroypwolaninandrewmacphersongtamaspetycompzsofimajor,SKAUGHTnod_effulgentsiaWim Leerscatchalexpott, and xjm.

And finally, a special thank you to Acquia's outside-in team for driving most of the design and implementation: tkolearywebchicktedbowGábor Hojtsytim.plunkett, and drpal.

Acquia's outside-in team celebrating that the outside-in patch was committed to Drupal 8.2 beta. Go team!

Catégories: Elsewhere

Reproducible builds folks: Reproducible Builds: week 69 in Stretch cycle

Planet Debian - mar, 23/08/2016 - 14:56

What happened in the Reproducible Builds effort between Sunday August 14 and Saturday August 20 2016:

Fasten your seatbelts

Important note: we enabled build path variation for unstable now, so your package(s) might become unreproducible, while previously it was said to be reproducible… given a specific build path it probably still is reproducible but read on for the details below in the tests.reproducible-builds.org section! As said many times: this is still research and we are working to make it reality.

Media coverage

Daniel Stender blogged about python packaging and explained some caveats regarding reproducible builds.

Toolchain developments

Thomas Schmitt uploaded xorriso which now obeys SOURCE_DATE_EPOCH. As stated in its man pages:

ENVIRONMENT [...] SOURCE_DATE_EPOCH belongs to the specs of reproducible-builds.org. It is supposed to be either undefined or to contain a decimal number which tells the seconds since january 1st 1970. If it contains a number, then it is used as time value to set the default of --modification-date=, --gpt_disk_guid, and --set_all_file_dates. Startup files and program options can override the effect of SOURCE_DATE_EPOCH. Packages reviewed and fixed, and bugs filed

The following packages have become reproducible after being fixed:

The following updated packages appear to be reproducible now, for reasons we were not able to figure out. (Relevant changelogs did not mention reproducible builds.)

  • vulkan/1.0.21.0+dfsg1-1 by Timo Aaltonen.

The following 2 packages were not changed, but have become reproducible due to changes in their build-dependencies: tagsoup tclx8.4.

Some uploads have addressed some reproducibility issues, but not all of them:

Patches submitted that have not made their way to the archive yet:

Bug tracker house keeping:

  • Chris Lamb pinged 164 bugs he filed more than 90 days ago which have a patch and had no maintainer reaction.
Reviews of unreproducible packages

55 package reviews have been added, 161 have been updated and 136 have been removed in this week, adding to our knowledge about identified issues.

2 issue types have been updated:

Weekly QA work

FTBFS bugs have been reported by:

  • Chris Lamb (16)
  • Santiago Vila (2)
diffoscope development

Chris Lamb, Holger Levsen and Mattia Rizzolo worked on diffoscope this week.

Improvements were made to SquashFS and JSON comparison, the https://try.diffoscope.org/ web service, documentation, packaging, and general code quality.

diffoscope 57, 58, and 59 were uploaded to unstable by Chris Lamb. Versions 57 and 58 were both broken, so Holger set up a job on jenkins.debian.net to test diffoscope on each git commit. He also wrote a CONTRIBUTING document to help prevent this from happening in future.

From these efforts, we were also able to learn that diffoscope is now reproducible even when built across multiple architectures:

< h01ger> | https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope.html shows these packages were built on amd64: < h01ger> | bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb < h01ger> | 366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb < h01ger> | and on i386: < h01ger> | bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb < h01ger> | 366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb < h01ger> | and on armhf: < h01ger> | bd21db708fe91c01ba1c9cb35b9d41a7c9b0db2b 62288 diffoscope_59_all.deb < h01ger> | 366200bf2841136a4c8f8c30bdc87057d59a4cdd 20146 trydiffoscope_59_all.deb

And those also match the binaries uploaded by Chris in his diffoscope 59 binary upload to ftp.debian.org, yay! Eating our own dogfood and enjoying it!

tests.reproducible-builds.org

Debian related:

  • show percentage of results in the last 24/48h (h01ger)
  • switch python database backend to SQLAlchemy (Valerie)
  • vary build path varitation for unstable and experimental for all architectures. (h01ger)

The last change probably will have an impact you will see: your package might become unreproducible in unstable and this will be shown on tracker.debian.org, while it will still be reproducible in testing.

We've done this, because we think reproducible builds are possible with arbitrary build paths. But: we don't think those are a realistic goal for stretch, where we still recommend to use ´.buildinfo´ to record the build patch and then do rebuilds using that path.

We are doing this, because besides doing theoretical groundwork we also have a practical goal: enable users to independently verify builds. And if they only can do this with a fixed path, so be it. For now

To be clear: for Stretch we recommend that reproducible builds are done in the same build path as the "original" build.

Finally, and just for our future references, when we enabled build path variation on Saturday, August 20th 2016, the numbers for unstable were:

suite all reproducible unreproducible ftbfs depwait not for this arch blacklisted unstable/amd64 24693 21794 (88.2%) 1753 (7.1%) 972 (3.9%) 65 (0.2%) 95 (0.3%) 10 (0.0%) unstable/i386 24693 21182 (85.7%) 2349 (9.5%) 972 (3.9%) 76 (0.3%) 103 (0.4%) 10 (0.0%) unstable/armhf 24693 20889 (84.6%) 2050 (8.3%) 1126 (4.5%) 199 (0.8%) 296 (1.1%) 129 (0.5%) Misc.

Ximin Luo updated our git setup scripts to make it easier for people to write proper descriptions for our repositories.

This week's edition was written by Ximin Luo and Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.

Catégories: Elsewhere

myDropWizard.com: Survey Results From "Is Drupal Hard?"

Planet Drupal - mar, 23/08/2016 - 14:51

A few weeks ago, we had A Survey! Is Drupal Hard?

First of all, thank you for taking the time to answer (even though we had a short-lived technical snafu!). At myDropWizard, we believe in transparency and openness, so I'm going to share the unfiltered data with you - as well as what my thoughts are in interpreting this non-scientific study.

The Data

Some Issues

  1. Many of those answering would be biased towards Drupal
  2. The choices were somewhat arbitrary, and no doubt some were left out
  3. There was an initial bug in the survey keeping some good data out
  4. The choice "It's about what I would expect" is probably better labeled as something more along the lines of "an average web developer should be able to accomplish their needs in a reasonable amount of time"
Analysis

So, there were plenty of flaws in the data, but that won't keep me from drawing a few conclusions - and I'm anxious to hear what others feel as well.

Drupal 7 Still a Favorite

"0" respondents claimed it "impossible" to do complex things while coupled with the lowest number of "Never Used It / No Opinion" at 5.

Catégories: Elsewhere

Nuvole: Maintain local development configuration with Configuration Split

Planet Drupal - mar, 23/08/2016 - 14:21
Answering the most commonly asked question about Configuration Management in Drupal 8; and a preview of our DrupalCon training.

This post is an excerpt from the topics covered by our DrupalCon Dublin training: Drupal 8 Development - Workflows and Tools.

For the last two years we have been giving trainings and presentations at various Drupal events about configuration management and its new workflows in Drupal 8. One of the recurring questions has been:

How do I keep some configuration from being deployed? For example the devel module and its configuration?

Until now we have answered to use drush with the --skip-modules flag and then to gitignore the configuration for devel. But then you can't share the development configuration and the process is error prone when there are more modules and other configuration items that depend on the configuration you gitignore.

For some simpler cases where configuration needs to be different between environments (for example the error verbosity) the configuration override system allows to override the configuration in settings.php. This is a solution for some cases, however, you can not override which modules are enabled or override configuration that doesn't exist.

Enter: Configuration split!

Our new module Configuration split splits the configuration when exporting it with a special Drupal Console command. It can be configured to split out enabled modules and given blacklisted configuration and it will then separate all the configuration that is dependent on the listed modules or configuration. The module's settings also allow to set a folder to which the separated configuration will be exported to.

That way the configuration set which you use to deploy configuration between different environments is a subset of your development configuration and the trusty configuration system of Drupal 8 can be used unharmed. Of course when importing with the special command the split configuration is merged back, allowing you to keep your development configuration in place.

"To split" is a synonym for "to break" and as such "Configuration split" has a dangerous ring to it. This is on purpose because the exported subset is on purpose not what you have on your development site and not what you have locally tested. So you need to compensate that with a workflow that imports and verifies the configuration you are going to deploy. This is better than to import and export individual configuration because Drupal needs the whole set of configuration to do its checks.

How do I use it?

Download and enable the Configuration split module like any other module. Then configure it under admin/config/development/configuration/config_split. Set the split folder to a different folder than your normal config sync folder. If you want a prettier interface, consider using Chosen. Then use the Drupal Console command config_split:export and config_split:import to export and import respectively.

Let's look at the devel example from above. We typically version the configuration outside of the webroot in ../config/sync as seen by Drupal. (In the project root when starting a project with drupal-composer/drupal-project.) So the folder we specify for config_split would be ../config/dev. The module to filter would be Devel and the rest can be left empty. The devel.settings will be detected automatically. Note though that the system.menu.devel does not depend on the devel module and can not be detected automatically, but it is easy to add it to the blacklisted config and it could theoretically be deployed without breaking anything.

The config_split.settings.yml could look something like this:

folder: ../config/dev
module:
  devel: 0
theme: {  }
blacklist:
  - system.menu.devel

Finally the following command will export the configuration to the default sync directory without the devel module enabled and export the devel configuration into the dev directory.
web$ ../vendor/bin/drupal config_split:export

Now if you would import the configuration through the UI or with drush cim the devel module would be un-installed, and you can do that to see the site without its development configuration. However, If you want the development configuration to stay or become active and the devel module installed use the following command:
web$ ../vendor/bin/drupal config_split:import

How does it work internally?

We implemented a StorageWrapper that allows filters to interact with the configuration after it has been read and before it is written to the wrapped FileStorage during the import and export operation. The SplitFilter has a secondary storage and decides where to read from or write to. This is a very similar concept to what drush does with its --skip-modules flag since we will want to easily integrate this with drush in the future.

What comes next?

The module is still in an early development stage and some more additions in the scope of splitting configuration could be added. The subset without the split configuration could be verified after exporting it and we could warn the user if it couldn't be imported. Or for example we currently use only config_split.settings but if the need arises we could support multiple split configurations. Or we could add a "gray list" to ignore some configuration that exists rather than removing it when splitting, essentially making it a configuration override outside of the scope of Drupal's runtime. This could be useful when maintaining several sites that are almost the same but all have their little "special snowflake" configuration which in turn could be synchronized with the normal workflow.

It is important to understand that the configuration system of Drupal has limitations that are there for a good reason. Most of them are to ensure data integrity and robustness and reliability of the synchronisation and so on. In other words measures to protect you from accidentally breaking your site. Using tools like config_split or drush --skip-modules you circumvent some of these security and integrity checks so use them with caution.

Since the module is not required for the regular functioning of a Drupal 8 site (it can even be used to blacklist itself) it can already be used in the development process of your current projects already. Your feedback is welcome, see you in the issue queue.

Tags: Drupal PlanetDrupal 8DrupalConTrainingCode Driven Development
Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur