Feed aggregator

Jonathan Dowland: Metropolis

Planet Debian - Fri, 09/09/2016 - 12:55

Every year since 2010 the Whitley Bay Film Festival has put on a programme of movies in my home town, often with some quirk or gimmick. A few years back we watched "Dawn Of The Dead" in a shopping centre—the last act was interrupted by a fake film-reel break, then a load of zombies emerged from the shops. Sometime after that, we saw "The Graduate" within a Church as part of their annual "Secret Cinema" showing. Other famous stunts (which I personally did not witness) include a screening of Jaws on the beach and John Carpenter's "The Fog" in Whitley Bay Lighthouse.

Massive thanks to Hunter North Recruitment for sponsoring Metropolis https://t.co/mphzHPCQ6O @snattaz pic.twitter.com/S9MNQmeLWZ

— Whitley Film Fest (@wbayfilmfest) August 14, 2016

This year I only went to one showing, Fritz Lang's Metropolis. Two twists this time: it was being shown in The Rendezvous Cafe, an Art-Deco themed building on the sea front; the whole film was accompanied by a live, improvised synthesizer jam by a group of friends and synth/sound enthusiasts who branded themselves "The Mediators" for the evening.

Metropolis live soundtrack preparations at the Rendezvous Cafe. Doors open 19.30 #metropolis pic.twitter.com/AdAqNVdEdx

— Whitley Film Fest (@wbayfilmfest) August 14, 2016

I've been meaning to watch Metropolis for a long time (I've got the Blu-Ray still sat in the shrink-wrap) and it was great to see the newly restored version, but the live synth accompaniment was what really made the night special for me. They used a bunch of equipment, most notably a set of Korg Volcas. The soundtrack varied in style and intensity to suit the scenes, with the various under-city scenes backed by a pumping, industrial-style improvisation which sounded quite excellent.

I've had an interest in playing with synthesisers and making music for years, but haven't put the time in to do it properly. I left newly inspired and energised to finally try to make the time to explore it.

Categories: Elsewhere

PreviousNext: We could add default content to Drupal core, but what would that mean?

Planet Drupal - Fri, 09/09/2016 - 05:07

There has been some movement of late around adding some default content to the standard profile.

This was originally reignited by Roy Scholten in his getting something in the box post.

As author and co-maintainer of the default content module for Drupal 8, I wanted to share my thoughts on the potential of adding it to Drupal core.

Categories: Elsewhere

Drupal core announcements: User Guide 8.x-2.0 released!

Planet Drupal - Fri, 09/09/2016 - 00:51

At long last, the copy editing of the User Guide is done! (If you've been a member of this group for a while, you should know what I'm talking about; if not, go browse the archives at https://groups.drupal.org/documentation for the last 1.5 years or so). I'd like to thank everyone who helped with editing tasks, and especially Jojy Alphonso (jojyja), who did the vast majority of the copy editing. THANK YOU!

So, the guide is in very good shape, and I just made an official release of version 8.x-2.0, corresponding to Drupal Core 8.2.x (which is supposed to be released soon). It should be live on Drupal.org soon, in HTML format, for your reading pleasure (not sure exactly when, since the reduced Drupal Association staff is pretty busy, but we're working on it). I'll post a link in a comment here when that happens.

Meanwhile, you can go to the User Guide project page and download the release, which contains all of the source files (which are written in AsciiDoc markup language), as well as PDF, ePub, and Mobi ebook versions (those are in the "ebooks" folder/directory of the archive you get when you download the project).

Enjoy!

Also... The next step will be to translate the User Guide into other languages. The enthusiastic and experienced Catalan and Hungarian language teams will be starting on that shortly, and refining the process so that hopefully the other language teams can get started soon as well. If you want to help translate the Guide, you should start by joining the translation team on https://localize.drupal.org for your language. Thanks!

Categories: Elsewhere

Lullabot: Syntax is Syntax? Lullabot's Non-Drupal Development Work

Planet Drupal - Thu, 08/09/2016 - 22:00
Did you know that Lullabot does a significant amount of non-Drupal work? Matt and Mike sit down with several Lullabots who are working on non-Drupal projects including Node, Swift, and React. We talk pros and cons of working in various languages, how they compare to our PHP world, and lots more.
Categories: Elsewhere

DrupalCon News: Wining and Dining in Dublin

Planet Drupal - Thu, 08/09/2016 - 20:45

Dublin is a great place to eat out.

You probably won’t be surprised to learn that Dublin has a pretty good selection of bars and restaurants and selecting just a few is a difficult task. This is most certainly not a comprehensive list of venues, but here is a selection of our favourites.

Let us begin with that most important institution: the full Irish breakfast!

Categories: Elsewhere

Jamie McClelland: Wait... is that how you are supposed to configure your SSD card?

Planet Debian - Thu, 08/09/2016 - 19:43

I bought a laptop with only SSD drives a while ago and based on a limited amount of reading, added the "discard" option to my /etc/fstab file for all partitions and happily went on my way expecting to avoid the performance degradation problems that happen on SSD cards without this setting).

Yesterday, after a several month ordeal, I finally installed SSD drives in one of May First/People Link's servers and started doing more research to find the best way to set things up.

I was quite surprised to learn that my change in /etc/fstab accomplished nothing. Well, not entirely true, my /boot partition was still getting empty sectors reported to the SSD card.

Since my filesystem is on top of LVM and LVM is on top of an encrypted disk, those messages from the files system to the disk were not getting through. I learned that when I tried to run the fstrim command on one of the partitions and received the message that the disk didn't support it. Since my /boot partition is not in LVM or encrypted, it worked on /boot.

I then made the necessary changes to /etc/lvm/lvm.conf and /etc/crypttab, restarted and... same result. Then I ran update-initramfs -u and rebooted and now fstrim works. I decided to remove the discard option from /etc/fstab and will set a cron job to run fstrim periodically.

Also, I learned of some security implications of using trim on an encrypted disk which don't seem to outweigh the benefits.

Categories: Elsewhere

Annertech: How to Get the Most out of DrupalCon Dublin

Planet Drupal - Thu, 08/09/2016 - 13:34
How to Get the Most out of DrupalCon Dublin

DrupalCon is big. It's got hundreds of sessions. A similar amount of BoFs. Approximately 2,000 attendees. Social events left, right, and centre. It's not hard to get confused, miss things that you promised not to, and leave thinking "damn, I could have done that better". At Annertech, we're Ireland's most seasoned DrupalCon attendees. Here's our guide to making the most of it.

Categories: Elsewhere

Drop Guard: Meet us in Dublin at booth #105!

Planet Drupal - Thu, 08/09/2016 - 12:00

Only 20 days are left until we head to Dublin to join the DrupalCon 2016! It’s the first time that we, the Drupal agency team from Bright Solutions (which is the "birthplace" of Drop Guard), arrive at a Con only with our Drop Guard team, so we can focus on our most famous contribution to the Community: our update management service tool “Drop Guard”.

Yes, we’d be happy to show people the great values which Drop Guard provides - but most of all we look forward to personal and honest conversations to progress in our work and as part of the Community!

 

Drupal Drupal Planet Drupalcon
Categories: Elsewhere

Flocon de toile | Freelance Drupal: Introduction to Drupal 8 module : Permissions by field

Planet Drupal - Thu, 08/09/2016 - 07:51
The powerful access control system provided by Drupal 8 and permissions can prove to be a decisive criterion for choosing Drupal. This system is the basis of modules as Organic Group or Domain access, which respectively implement groups within the same site and implement a virtual multi-site architecture. The Permissions by field module allows us to control access to contents of a Drupal site in several generic methods, relying on the power of Entity Reference and the Drupal Field API, and to be able to delegate complex management access rights to content publishers according to their needs. Discover this module and the different possible use cases.
Categories: Elsewhere

Antonio Terceiro: Debian CI updates for September 2016

Planet Debian - Thu, 08/09/2016 - 00:07

debci 1.4 was released just a few days ago. Among general improvements, I would like to highlight:

  • pretty much every place in the web UI that mentions a PASS or a FAIL also displays the tested package version. This was suggested to me on IRC by Holger
  • I also tried to workaround an instability when setting up the LXC containers used for the tests, where the test bed process setup would finish without failure even though some steps in the middle of it failed. This caused the very final step for the debci-specific setup to fail, so there was no debci user inside the container, which caused tests to fail because that user was missing. Before that was fixed I was always keeping an eye on this issue, fixing the issue by hand, and re-triggering the affected packages by hand, so as far I can tell there is no package whose status has been permanently affected by this.
  • Last, but not least, this release brings an interesting contribution by Gordon Ball, which is keeping track of different failure states. debci will now let you know whether a currently failing package has always failed, has passed in a previous version, or if the same version that is currently failing has previously passed.

ci.debian.net has been upgraded to debci 1.4 just after that. At the same time I have also upgraded autodep8 and autopkgtest to their latest versions, available in jessie-backports. This means that it is now safe for Debian packages to assume the changes in autopkgtest 4.0 are available, in special the $AUTOPKGTEST_* environment variables.

In other news, for several weeks there were had issues with tests not being scheduled when they should have. I was just assuming that the issue was due to the existing test scheduler, debci-batch, being broken. Today I was working on a new implementation that is going to be a lot faster, I started to hit a similar issue on my local tests, and finally realized what was wrong. The fact is that debci-batch stores the timestamp of the last time a package has been scheduled to run, and it there are no test result after that timestamp, it assumes the package is still in the queue to be tested, and does not schedule it again. It turns out that a few weeks ago, during maintainance work, I had cleared the queue, discarding all jobs that were there, but forgot to reset those timestamps, so when debci-batch came around again, it checked the timestamp of the last request and did not make new requests because there was no test result after that timestamp! I cleared all those timestamps, and the system should now go back to normal.

That is it for now. I you want to contribute to the Debian CI project and want to get in touch, you can pop up on the #debci channel on the OFTC IRC network, or mail the autopkgtest-devel mailing list.

Categories: Elsewhere

Drupal Blog: Drupal 8.2.0-rc1 is available for testing

Planet Drupal - Thu, 08/09/2016 - 00:07

The first release candidate for the upcoming Drupal 8.2.0 release is now available for testing. With Drupal 8, we made major changes in our release process, adopting semantic versioning and scheduled releases. This allows us to make significant improvements to Drupal 8 in a timely fashion while still providing backwards compatibility. Drupal 8.2.0 is the second such update, expected to be released October 5.

Download Drupal-8.2.0-rc1

8.2.x includes many REST improvements; new experimental modules for content moderation, block placement, a sidebar to configure site elements in place, and end date support; and many other features and improvements. You can read a detailed list of improvements in the announcements of beta1, beta2, and beta3.

What does this mean to me? For Drupal 8 site owners

The final bugfix release of 8.1.x has been released. 8.1.x will receive no further releases following 8.2.0, and sites should prepare to update from 8.1.x to 8.2.x in order to continue getting bug and security fixes. Use update.php to update your 8.1.x sites to the 8.2.x series, just as you would to update from (e.g.) 8.1.4 to 8.1.5. You can use this release candidate to test the update. (Always back up your data before updating sites, and do not test updates in production.)

For module and theme authors

Drupal 8.2.x is backwards-compatible with 8.1.x. However, it does include internal API changes and API changes to experimental modules, so some minor updates may be required. Review the change records for 8.2.x, and test modules and themes with the release candidate now.

For translators

Some text changes were made since Drupal 8.1.0. Localize.drupal.org automatically offers these new and modified strings for translation. Strings are frozen with the release candidate, so translators can now update translations.

For core developers

All outstanding issues filed against 8.1.x are automatically migrated to 8.2.x now. Future bug reports should be targeted against the 8.2.x branch. 8.3.x will remain open for new development during the 8.2.x release candidate phase. For more information, see the beta and release candidate phase announcement.

Your bug reports help make Drupal better!

Release candidates are a chance to identify bugs for the upcoming release, so help us by searching the issue queue for any bugs you find, and filing a new issue if your bug has not been reported yet.

Categories: Elsewhere

Xeno Media: Drupal HTML Formatter Module

Planet Drupal - Wed, 07/09/2016 - 21:32

We used the Acquia Lightning distribution in developing this site.  Lightning, takes full advantage of the awesomeness of Panels and Panelizer to display content defaults, and override on a per node basis.  We used Panelizer to set up displays for the full node displays, and the Teaser node displays.

This brought up a problem where I wanted to set up the title of the node using an H1 on the full display, but an H2 on the teaser.  We thought of overriding two templates to do this, but that didn't seem like a sustainable solution as we quickly realized there were other places we needed similar functionality, like choosing different html elements, and adding classes to fields of various sorts.

We had this functionality in Drupal 7 thanks to the Title module, and it's "Wrapped and Linked" widget.  In D7, the main purpose of the Title module was to turn the title into a field so it could be translated.  Since translation was moved into core in D8, there hasn't been a lot of movement on porting Title to D8, and that module was not an option.

After a quick discussion between Albert and I, he quickly got to work and started to work on the Drupal HTML Formatter module.  It is a simple module that lets you add HTML tags to fields that are strings, timestamps, datetime, referenced and entities.  You can add any HTML/HTML5 tag, add classes, and you can also set if the content is linked to content which is almost always required on entity reference fields.

To use, install as you normally do and enable the HTML Formatter module.  If your site is a Panels based display, one that uses Panelizer or Page Manager, and your Block, and select Html field formatter from the Formatter dropdown.  Then add your HTML Tag, and if needed, add the Class Name, and check the Link to Content checkbox and Save.

Not using Panels?  Well have no fear as the HTML Formatter also works on the normal Manage display tab of entities.  Select Html field formatter from the Format dropdown.  Then click on the settings cog to expand the options and you will see the same three options.

We developed this as way of giving back to the Drupal community, as I can imagine that there are others who have run into this need.  Let us know what you think.  You can find us on Twitter at @alb3rtski, @thejimbirch, and @xenophiles.

Categories: Elsewhere

Third & Grove: The Death of Drupal Commerce as an Ecommerce Solution

Planet Drupal - Wed, 07/09/2016 - 20:57
The Death of Drupal Commerce as an Ecommerce Solution justin Wed, 09/07/2016 - 14:57
Categories: Elsewhere

Wouter Verhelst: Installing files for other applications with autotools

Planet Debian - Wed, 07/09/2016 - 18:40

Let's say you have a configure.ac file which contains this:

PKG_CHECK_VAR([p11_moduledir], "p11-kit-1", "p11_module_path") AC_SUBST([p11_moduledir])

and that it goes with a Makefile.am which contains this:

dist_p11_module_DATA = foo.module

Then things should work fine, right? When you run make install, your modules install to the right location, and p11-kit will pick up everything the way it should.

Well, no. Not exactly. That is, it will work for the common case, but not for some other cases. You see, if you do that, then make distcheck will fail pretty spectacularly. At least if you run that as non-root (which you really really should do). The problem is that by specifying the p11_moduledir variable in that way, you hardcode it; it doesn't honour any $prefix or $DESTDIR variables that way. The result of that is that when a user installs your package by specifying --prefix=/opt/testmeout, it will still overwrite files in the system directory. Obviously, that's not desireable.

The $DESTDIR bit is especially troublesome, as it makes packaging your software for the common distributions complicated (most packaging software heavily relies on DESTDIR support to "install" your software in a staging area before turning it into an installable package).

So what's the right way then? I've been wondering about that myself, and asked for the right way to do something like that on the automake mailinglist a while back. The answer I got there wasn't entirely satisfying, and at the time I decided to take the easy way out (EXTRA_DIST the file, but don't actually install it). Recently, however, I ran against a similar problem for something else, and decided to try to do it the proper way this time around.

p11-kit, like systemd, ships pkg-config files which contain variables for the default locations to install files into. These variables' values are meant to be easy to use from scripts, so that no munging of them is required if you want to directly install to the system-wide default location. The downside of this is that, if you want to install to the system-wide default location by default from an autotools package (but still allow the user to --prefix your installation into some other place, accepting that then things won't work out of the box), you do need to do the aforementioned munging.

Luckily, that munging isn't too hard, provided whatever package you're installing for did the right thing:

PKG_CHECK_VAR([p11_moduledir], "p11-kit-1", "p11_module_path") PKG_CHECK_VAR([p11kit_libdir], "p11-kit-1", "libdir") if test -z $ac_cv_env_p11_moduledir_set; then p11_moduledir=$(echo $p11_moduledir|sed -e "s,$p11kit_libdir,\${libdir},g") fi AC_SUBST([p11_moduledir])

Whoa, what just happened?

First, we ask p11-kit-1 where it expects modules to be. After that, we ask p11-kit-1 what was used as "libdir" at installation time. Usually that should be something like /usr/lib or /usr/lib/gnu arch triplet or some such, but it could really be anything.

Next, we test to see whether the user set the p11_moduledir variable on the command line. If so, we don't want to munge it.

The next line looks for the value of whatever libdir was set to when p11-kit-1 was installed in the value of p11_module_path, and replaces it with the literal string ${libdir}.

Finally, we exit our if and AC_SUBST our value into the rest of the build system.

The resulting package will have the following semantics:

  • If someone installs p11-kit-1 your package with the same prefix, the files will install to the correct location.
  • If someone installs both packages with a different prefix, then by default the files will not install to the correct location. This is what you'd want, however; using a non-default prefix is the only way to install something as non-root, and if root installed something into /usr, a normal user wouldn't be able to fix things.
  • If someone installs both packages with a different prefix, but sets the p11_moduledir variable to the correct location, at configure time, then things will work as expected.

I suppose it would've been easier if the PKG_CHECK_VAR macro could (optionally) do that munging by itself, but then, can't have everything.

Categories: Elsewhere

Chromatic: Drupal Code Standards: Documentation

Planet Drupal - Wed, 07/09/2016 - 17:56

This is the fourth post in a series about coding standards. In this post we’ll talk about why good, standardized documentation is crucial to your project, and review Drupal coding standards regarding documentation and comments.

Other posts in this series:

  1. Drupal Code Standards: What Are They?
  2. Drupal Code Standards: How Do We Implement Them?
  3. Drupal Code Standards: Formatting
  4. Drupal Code Standards: Documentation
  5. Drupal Code Standards: The t() function
  6. Drupal Code Standards: Object Oriented Coding & Drupal 8
  7. Drupal Code Standards: Twig in Drupal 8
Why is documentation important?

Documentation tells us what our code does. How it’s set up, what variables it uses, what it returns. It tells us what to expect from our code.

But I know what my code does!

Sure you do, right now, you just wrote it. But how about 2 months or 10 projects from now? What about someone else? The key is to make your code maintainable by everyone. Of course, ideally, you’re writing code that’s easy to comprehend because you did everything in a perfectly logical and straightforward way. But comment it thoroughly, just in case. You might also do something clever to solve a tricky problem, but to the next person, it might look like a mistake. Documentation can clear this up.

But my code is so good, it’s self-documenting!

Of course it is. But even to the best programmer, documentation is still quicker and easier to read than code. Documentation is especially helpful for beginner programmers - say someone who’s just starting with Drupal and PHP is looking through your code to see if it does what they need - if you can spell it out for them, you’ll help them figure out what they need a lot faster. Thanks to Drupal’s documentation standards, we have a few ways to document your code that are designed to be quick and easy for the developer writing the code, and the developers reading and modifying it. That said, try to avoid repetetive inline comments - you don't need to comment on every single line of code, especially if it's very clear what it's doing. Comment on functions, large blocks of code, tricky things, things that may change - think about what might be unclear to the next person to look at it.

Doc Blocks

One of the most important parts of documentation in Drupal is doc blocks - these are specially formatted blocks of information that go both at the top of each PHP file and before each function.

File Doc Blocks

A file doc block goes at the top of a file to give you an overview of what the file contains. These go at the top of every PHP file, and while it is still in the process of being adopted as an official standard, there should be one blank line between the opening tag and the doc block. Here’s an example from the Backup and Migrate module:

<?php /** * @file * Create (manually or scheduled) and restore backups of your Drupal MySQL * database with an option to exclude table data (e.g. cache_*). */

It’s short and simple and explains what to expect in this module file. Each function will be documented separately, so this doesn’t need to be extensive. On the next line after the file tag, we have a description. The @file doc block may also commonly include @author and @version.

/** * @file * Provides hook implementations for the chromatic_blog module. * * @author Chris Free * * @version 1.0 */

In something like a template file, you’ll see more detail in the @file doc block, because the rest of the file may not have as much documentation. The @file doc block may often spell out available variables.

Here’s an example from the Bartik theme:

/** * @file * Bartik's theme implementation to provide an HTML container for comments. * * Available variables: * - $content: The array of content-related elements for the node. Use * render($content) to print them all, or * print a subset such as render($content['comment_form']). * - $classes: String of classes that can be used to style contextually through * CSS. It can be manipulated through the variable $classes_array from * preprocess functions. The default value has the following: * - comment-wrapper: The current template type, i.e., "theming hook". * - $title_prefix (array): An array containing additional output populated by * modules, intended to be displayed in front of the main title tag that * appears in the template. * - $title_suffix (array): An array containing additional output populated by * modules, intended to be displayed after the main title tag that appears in * the template. * * The following variables are provided for contextual information. * - $node: Node object the comments are attached to. * The constants below the variables show the possible values and should be * used for comparison. * - $display_mode * - COMMENT_MODE_FLAT * - COMMENT_MODE_THREADED * * Other variables: * - $classes_array: Array of html class attribute values. It is flattened * into a string within the variable $classes. * * @see template_preprocess_comment_wrapper() */ Function Doc Blocks

A function doc block goes just before every function in every PHP file. No exceptions. Even if it’s a one-line function, it gets a doc block. Now, coder will let you get away with only putting the one-line summary of your function, this is all that’s technically required. For some functions, this may be appropriate. But if your function has any parameters or return values, you should absolutely be documenting them. Yes, it’s more work upfront, but it’s vital work that saves time in the future.

Here we’ll look at a function from the Backup and Migrate module.

This passes coder, it’s got a one-line summary of the function:

/** * Restore from a file in the given destination. */

But this is better:

/** * Restore from a file in the given destination. * * @param string $destination_id * The machine-readable path of the backup destination. * @param object|string $file * The file object, or its name. * @param object|array $settings * A settings object, or array to create a settings object. * * @return object|bool * Returns the file, or FALSE if the restore had any errors. */

Does this take a little more time? Absolutely. But I guarantee you will have a better understanding of the code if you write out documentation that’s as detailed as possible. Now we know what is passed to the function, what each variable is, and what the function returns. Good documentation can also aid in debugging - if the documentation doesn’t match what’s happening in the code, you know something is wrong, and you’ve got a starting point for fixing it.

Tags

There are a variety of tags you can use in your doc blocks to indicate what this documentation is about, and they’re expected to go in a certain order, as follows:

Each type of tag should be separated by a blank line. The most-used tags in function doc blocks are probably @param and @return.

Here’s an example of how the Countries module uses some of the other tags:

/** * Generate a country form. * * @ingroup forms * * @see countries_admin_form_validate() * @see countries_admin_form_submit() */

Groups and topics are tags that come from Doxygen, on which these standards are based, and it helps to group generated documentation from the API module. From Drupal.org:

@defgroup, @addtogroup, @ingroup, @{, @}: Groups and topics

The @defgroup tag is used to define a "group" (in Doxygen terms), which the API module displays as a Topic page. A @defgroup tag needs to be in its own docblock (not inside a file description docblock, function docblock, class docblock, etc.). A group defined by @defgroup has an identifier (starting with a letter, and composed of numbers, letters, underscores, periods, and hyphens), a title, a summary, and documentation. In addition, individual "items" (files, functions, classes, and other things that are documented with docblocks in the API module) can be designated as being "in" the group. The API module makes a page for each group/topic, and on the page, it lists all of the items that are part of the group.

Here’s an example of @defgroup from Drupal 8 core - groups are used more often when you have a large amount of code, like core does. You’ll also see an example of @code and @endcode used here - this tells the API Module to format that text as code.

/** * @defgroup php_wrappers PHP wrapper functions * @{ * Functions that are wrappers or custom implementations of PHP functions. * * Certain PHP functions should not be used in Drupal. Instead, Drupal's * replacement functions should be used. * * For example, for improved or more secure UTF8-handling, or RFC-compliant * handling of URLs in Drupal. * * For ease of use and memorizing, all these wrapper functions use the same name * as the original PHP function, but prefixed with "drupal_". Beware, however, * that not all wrapper functions support the same arguments as the original * functions. * * You should always use these wrapper functions in your code. * * Wrong: * @code * $my_substring = substr($original_string, 0, 5); * @endcode * * Correct: * @code * $my_substring = Unicode::substr($original_string, 0, 5); * @endcode * * @} */

And in another function block, we’ll see:

@ingroup php_wrappers

Which tells us that this function is part of the php_wrappers group. It’s a handy way to organize your code once you get the hang of it!

The @deprecated tag is useful if you don’t want to delete a function - someone could have custom code that relies on it.

/** * Wrapper for country_load(). * * @deprecated * Use country_load($iso2) instead. */ Lists

You can create lists in your doc blocks that will be interpreted by the API module as unordered lists. They can also make it easier to read. Start the line with a hyphen to indicate a list item. Here is an example from the CKEditor module:

/** * Implementation of hook_requirements(). * * This hook will issue warnings if: * - The CKEditor source files are not found. * - The CKEditor source files are out of date. * - Quick upload and/or the built-in file browser are used and $cookie_domain is not set. */ Implements hook_xyz().

If you are implementing a hook - for example, hook_menu, all you have to put in the function doc block is:

/** * Implements hook_menu(). */

In fact, if you put more than this, coder will give you a warning such as:

8 | WARNING | Format should be "* Implements hook_foo().", "* Implements | | hook_foo_BAR_ID_bar() for xyz_bar().",, "* Implements | | hook_foo_BAR_ID_bar() for xyz-bar.html.twig.", or "* Implements | | hook_foo_BAR_ID_bar() for xyz-bar.tpl.php.".

You also do not need to duplicate the documentation for the function, such as the parameters. If you do, you’ll get a warning such as:

11 | WARNING | Hook implementations should not duplicate @param documentation

If it’s really important that you document something that has changed in your implementation, never skimp on documentation. However, you can always put the documentation inside the function if you want to keep coder happy about the docblock.

API Module

Why are these doc blocks so important, and why do they have to be formatted so exactly? The API Module parses the information in doc blocks into documentation, so it’s especially important to make sure the format is correct. Any documentation that strays from this format will be human-readable, but won’t be properly parsed. The documentation found at https://api.drupal.org/api/drupal is all generated this way.

Inline Comments

Inline comments are important, because this is what you’ll use to explain your code throughout your files. Drupal generally uses the C++-style \\ notation, though C-style comments (\* *\) are allowed, but discouraged within functions. Inline comments shouldn’t follow a statement - this means they must get their own line. It’s usually understood that a comment precedes the line it’s commenting on, but you can always make this clearer by saying something like "The following line does XYZ."

Remember from our previous post on formatting that inline comments must always end in a full stop, and must never be longer than 80 characters. Here’s an example from a contrib module:

Wrong:

'iso2' => array( '12', // Numerical '', // Empty '$s', // Special char 'au', // Duplicate 'd', // Single property 'ddd', // Too long ),

Right:

'iso3' => array( // Numerical. '123', // Special char. '$ss', // Duplicate. 'aus', // Single char. 'd', // Double char. 'dc', // Too long. 'xaaa', ),

Right, but discouraged:

'numcode' => array( '1001', /* Too big. */ '-1', /* Too small. */ '-12', /* Too small. */ '-123', /* Too small. */ '$23', /* Special char. */ '23#', /* Special char. */ '048', /* Duplicate. */ '4', /* Duplicate. */ '04', /* Duplicate. */ ), Content Style Guide

Drupal.org has a style guide for content on the site, and it’s encouraged to use this guide for anything you write inside of Drupal code. Much of it is the style of various industry-related terms, along with Drupal specific terms. It’s worth giving it an overview. The clearer our content, the better we can communicate with each other and with new Drupal users!

We’ve covered why documentation is essential, how to write file and function doc blocks for the API module in your Drupal code, and inline comments. As detailed as this may seem, it’s still only an overview - the Drupal.org page has even more detail! But this guide will get your started and give you a reference point. Now go forth and document!

In our next post on coding standards, we’ll take a detailed dive into just one essential Drupal function - the t() function. Learn when and when not to use it in both Drupal 7 and Drupal 8!

Hero Image Attribution: dangerismycat CC

Categories: Elsewhere

Stanford Web Services Blog: Git: Find the First Tag Containing a Specified Keyword

Planet Drupal - Wed, 07/09/2016 - 17:00

Today's post is a quick tutorial how to use "git grep" and "git tag" to find the earliest tag that contains a particular line of code.

TL;DR: use:

git grep <regexp> $(git rev-list --all)

and

git tag --contains=<commit hash>

Categories: Elsewhere

Mike Gabriel: Debian's GTK-3+ v3.21 breaks Debian MATE 1.14

Planet Debian - Wed, 07/09/2016 - 13:21
sunweaver sighs...

This short post is to inform all Debian MATE users that the recent GTK-3+ upload to Debian (GTK-3+ v3.21) broke most parts of the MATE 1.14 desktop environment as currently available in Debian testing (aka stretch). This raises some questions here on the MATE maintainers' side...

Questions
  1. Isn't GTK-3+ a shared library? This one was rhetorical... Yes, it is.

  2. One that breaks other application with every point release? Well, unfortunately, as experience over the past years has shown: Yes, this has happened several times, so far — and it happened again.

  3. Why is it that GTK-3+ uploads appear in Debian without going through a proper transition? This question is not rhetorical. If someone has an answer, please enlighten me.

Potential Counter Measures

For Debian MATE users running on Debian testing: This is untested, but it is quite likely that your MATE desktop environment will work again, once you have reverted your GTK-3+ library back to v3.20. For obtaining old Debian package versions, please visit the https://snapshots.debian.org site.

Prospective

The MATE 1.16 release is expected for Sep 20th, 2016. We will do our best to provide MATE 1.16 in Debian before this month is over. MATE 1.16 will again run smoothly (so I heard) on GTK-3+ 3.21.


light+love
sunweaver (who is already scared of the 3.22 GTK+ release, luckily the last development release of the GTK+ 3-series)

Categories: Elsewhere

Amazee Labs: The Amazee Labs sessions track record for DrupalCon Dublin

Planet Drupal - Wed, 07/09/2016 - 13:08
The Amazee Labs sessions track record for DrupalCon Dublin

It’s a track record! For the upcoming DrupalCon in Dublin, 13 tracks will feature talks for an audience of thousands of people coming together for Drupal. We are proud to be represented in 6 of those tracks.

Josef Dabernig Wed, 09/07/2016 - 13:08

Curious about the latest and greatest in decoupled web architectures and how they integrate with Drupal? No compromises – React, Relay and GraphQL on Drupal 8 by Sebastian Siemssen (fubhy), Campbell Vertesi and Moshe Weitzman in the Horizons track is mainly targeted at experienced developers. Sebastian, Campbell and Moshe share their experience with setting up a Drupal website architecture based on these latest technologies.

It’s almost 10 years since Amazee has started reaching for the stars. Check out A tale about building businesses and sleeping on sofas by Dania Gerhardt in the Business track. As the CEO of our Cape Town office, founder & partner she is happy to share her very own startup and business story. Attend her session to find out about building five companies in nine years on three continents.

The way we build sites and implement layouts has changed massively over time. Remember Contemplate, Context or the Panels modules? The session How to create content layouts in Drupal 8 by Josef Dabernig (dasjo) and Inky Talbot (Inky3d) in the Site Building track features the current best practices that Amazee Labs has developed during the last 3 years; since we started to work witn Drupal 8.

Scaling high-performance websites around the globe is one challenge that our DevOps team enjoys tackling. To CDN and beyond! Speed up websites beyond the US and Europe by Bastian Widmer (dasrecht) in the Performance and Scaling track features a good mix of best practices and lessons learned on setting up CDN's with Drupal, hosting in mainland China and other fun optimizations that the Amazee.io team has done.

Automation and watertight processes are really what you want when it comes to ensuring the security of your web applications. Drupal Security: There is a Mini-DrupalGeddon every week and how to survive it is a joint session by Michael Schmid (schnitzel) from the Amazee.io team and Manuel Pistner (manuelBS) from DropGuard in the Drupal Showcase track. Join these two experts in Drupal hosting and security automation to find out about the Drupal security patch release process and how we integrate it into our CI/CD workflows.

What makes us effective, how do we accomplish tasks? My talk Let me help you help me - Selfish empowerment of others in the Being Human track is all about trial and error with leadership both in the Drupal community and at work. I’m looking forward sharing my experience with delegating tasks and supporting others on their career paths.

Interested? We look forward to seeing you September 26-30 at DrupalCon Dublin. Find us there in one of our sessions or at our booth, but also remember - all sessions will be recorded and put up on the Drupal Association YoutTube channel.

Categories: Elsewhere

PreviousNext: Custom views filters with Search API and Simple Hierarchical Select

Planet Drupal - Wed, 07/09/2016 - 11:04

A recent project involved the use of the Simple Hierarchical Select module to input category data for a particular content type. Simple Hierarchical Select provides a clean way of browsing hierarchical vocabularies to easily add taxonomy terms to nodes.

An initially tricky user interface problem to utilise this module with Search API and Views exposed filters was solved using a couple of Drupal 8 plugins and a bit of smart thinking!

Categories: Elsewhere

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

Planet Debian - Wed, 07/09/2016 - 10:14

What happened in the Reproducible Builds effort between Sunday August 28 and Saturday September 3 2016:

Media coverage

Antonio Terceiro blogged about testing build reprodubility with debrepro .

GSoC and Outreachy updates

The next round is being planned now: see their page with a timeline and participating organizations listing.

Maybe you want to participate this time? Then please reach out to us as soon as possible!

Packages reviewed and fixed, and bugs filed

The following packages have addressed reproducibility issues in other packages:

The following updated packages have become reproducible in our current test setup after being fixed:

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

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

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

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

Reviews of unreproducible packages

706 package reviews have been added, 22 have been updated and 16 have been removed in this week, adding to our knowledge about identified issues.

5 issue types have been added:

1 issue type has been updated:

Weekly QA work

FTBFS bugs have been reported by:

  • Chris Lamb (8)
  • Lucas Nussbaum (3)
diffoscope development

diffoscope development on the next version (60) continued in git, taking in contributions from:

  • Mattia Rizzolo:
    • Better and more thorough testing
    • Improvements to packaging
    • Improvements to the ppu comparator
strip-nondeterminism development

Mattia Rizzolo uploaded strip-nondeterminism 0.023-2~bpo8+1 to jessie-backports.

A new version of strip-nondeterminism 0.024-1 was uploaded to unstable by Chris Lamb. It included contributions from:

  • Chris Lamb:
    • Improve code quality of zip, jar, ar, png processors
  • AYANOKOUZI, Ryuunosuke:
    • Preserve file attribute information of target file (#836075)

Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches.

disorderfs development

Holger added jobs on jenkins.debian.net to run testsuites on every commit. There is one job for the master branch and one for the other branches.

tests.reproducible-builds.org

Debian: We now vary the GECOS records of the two build users. Thanks to Paul Wise for providing the patch.

Misc.

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

Categories: Elsewhere

Pages

Subscribe to jfhovinne aggregator