Agrégateur de flux

Phase2: Accelerating with Drupal 8

Planet Drupal - ven, 20/03/2015 - 16:09

Today is an exciting day for the Drupal community! Collectively, we’re all moving a few steps closer to a full release of Drupal 8 with the help of a program called Drupal 8 Accelerate. This is a pilot program from the Drupal Association designed to put $250,000 of community funds towards eliminating the last 50 critical issues between us and release.

The Drupal Association has been an incredible leader in the effort to release Drupal 8, pledging to set aside $62,500 to match every dollar donated to the provide Drupal 8 Acceleration Grants.

What’s the latest with Drupal 8 Accelerate?

But we knew we could do even more to turbocharge this project. Today we are announcing that D8 Accelerate is now getting a huge boost from seven anchor sponsors, who have pledged to “match the match,” amplifying every donation made and accelerating the community’s investment in Drupal 8.

Phase2, Acquia, Appnovation, Lullabot, Palantir, PreviousNext, and Wunderkraut have collectively pledged another $62,500 to match the Drupal Association’s matches of community donations. This is an all-out, everyone-in community effort to move D8 from beta to release. Our goal is to bring the total to $250,000 available for grants by September. We are now more than half way there.

Why should we all want Drupal 8 to succeed?

The answer is simple: D8 will empower us to use Drupal the way many of us have wanted to for a long time. D8 improves the API layer, multi-lingual capabilities, theming and the editor experience. It also makes is much more powerful for developers (which matters a lot to us at Phase2).

Historically, it has been a challenge to integrate new libraries or different front-end elements without a lot of leg work. Imagine, for example, how the availability of Twig theming will enhance your projects. Or how flexible implementations can be with dependencies on meaningful external software integrated through Symfony routing. We will even be able to more seamlessly incorporate mobile apps into the digital strategies we develop, correcting one of the main weak points of previous Drupal releases.

Put simply, Drupal 8 is a win for our collective clients, and therefore it is a win for all of us.

Phase2 & Drupal 8

At Phase2, we want Drupal 8 to succeed because our clients have increasingly big needs and major challenges, and we believe that Drupal 8 is moving in the direction to address those. For that reason, we’ve made investing in Drupal 8 a priority, not only by way of the Drupal 8 Accelerate program, but also in the form of contributed code and shared knowledge gleaned from major enterprise Drupal 8 implementations.

Taking on early Drupal 8 implementations enables us to commit our people to the D8 cause, while directly supporting our client’s mission. It also provides us with a group of advanced scouts to report back from the front lines and develop training for the rest of our team.

Principle among these scouts was Software Architect Jonathan Hedstrom, whose contributions to D8 include Drush support, core patch reviewing, testing and re-rolling, writing tests, modules upgrades (Redis), and more. In addition to Jonathan, Senior Developer Brad Wade made important front-end contributions, while Software Architect Mike Potter has been a significant part of Features development.

We’ll be sharing a lot of what we learned from our D8 work so far at DrupalCon Los Angeles, so stay tuned for our session announcements next!

 An all-out, everyone-in effort

It took the whole Drupal community – including individuals, companies, the Drupal Association – to get D8 to the place it is now. We are honored to have contributed alongside everyone involved. It has certainly been a heavy lift for many community members, so to each of these people and organizations, we say thank you. The success of Drupal 8 is the most important priority of our community.

However, Drupal 8 still needs a strong push to get over the finish line. So we must ask one more time for the support of our fellow Drupalers. We all have a major stake in the success of the project, and everyone can play an instrumental role getting it out the door. Even the smallest donation makes a difference when every dollar you donate is now matched, compounding your impact. You can read more about how the funds actually support the grant program to achieve the work on the Drupal Association D8 Accelerate page.

If you would like to donate, please visit the D8 Accelerate Fundraising site and please consider using my profile as a way to easily make your contribution so we can start enjoying those launch parties!

Catégories: Elsewhere

Drupal Association News: Ready, Set, Drupal 8! D8 Accelerate Fundraiser

Planet Drupal - ven, 20/03/2015 - 15:59

Last November we launched Drupal 8 Accelerate, a grant program designed to eliminate Drupal 8 release blockers. Through the progam, we’ve made a small number of grants that have had a huge impact. In fact, we only have about 50 release blockers left between us and release. So now the Association is going to take it to the next level. We've already pledged $62,500 of our general operating budget in 2015 as matching funds for you donations. Now we are announcing that the board has partnered with 7 outstanding community supporters to “match the match” and provide another $62,500 of the program, bringing us to $125,000 available for grants.

Now it's your turn! We're asking you to help us raise another $125,000 to make the total amount available for these grants $250,000. You can give knowing that every dollar you contribute is already matched by the Association and these anchor donors, doubling your impact. Your donations will allow us to make more grants, faster, increasing our impact and getting D8 out the door!

This is an all-out, everyone-in effort to raise $250,000 to kill the last release blockers in our way.This is our moment - together, we are going to move Drupal 8 from beta to release with the Drupal 8 Accelerate program. We already know it works. Drupal 8 Accelerate grants have already tackled release blockers issues related to menus, entity field validation, and caching. As a donor, you will always know exactly what you're funding because we're making it all public

Join us today and make your donation. The sooner we get this done, the sooner we can all enjoy those launch parties!

Special thanks to our anchor donors, Acquia, Appnovation, Lullabot, Palantir.net, Phase2, PreviousNext, and Wunderkraut, for making this matching campaign possible.  These seven organizations stepped up to the plate and made this entire campaign possible. Thank them on Twitter using the #D8Accelerate hashtag.

The D8 Accelerate project is designed to help move Drupal 8 from the initial beta to a full release. This directly relates to the Association's mission: uniting a global open source community to build and promote Drupal. This is a pilot program from the Drupal Association to put $250,000 of community funds toward accelerating the release of Drupal 8, due to the strategic impact this work has on the entire Drupal ecosystem.

Catégories: Elsewhere

Steve McIntyre: Tour of Australia

Planet Debian - ven, 20/03/2015 - 15:24

Jo and I just got back from our massive holiday in Australia. We had an awesome time overall, fitting in lots of stuff in 4 weeks. Time for a quick write-up and some photos!

We flew into Sydney, then straight onto Uluru for the obligatory sunset and sunrise viewings. We didn't climb the Rock, both for sensitivity reasons and (to be more honest!) it looked way too much like hard work in 40-plus degree heat.

Coach over to Alice Springs, where we had a very quick look around before taking the Ghan train down to Adelaide. The train was fun for a day, and we got to see a lot of desert. In Adelaide, we had a look around the city (lovely colonial feel!) and got a couple of evenings in fun comedy shows at the Fringe. Great fun!

On to Tasmania, where we did a quick (3 days) run around the island by car: into Hobart, up the east coast. Stopped in Swansea (a nice version!) for some heavenly Devonshire teas, then on up to Grindelwald near Launceston. Visited Trowunna Wildlife Park to see (and cuddle!) lots of local animals, which was amazing - Jo's favourite day of the holiday. Then on to Queenstown and drive back down to Hobart past some impossibly beautiful views around Cradle Mountain. Tassie's gorgeous - like the best bits of Scotland, Wales and Cornwall but with even fewer people and better weather.

Next, on to Sydney for Harry and Cath's wedding. We stayed up in Chatswood. Not knowing anything about the area beforehand, we were a little surprised to basically find ourselves back in Hong Kong! We spent most of the weekend catching up with friends from the wedding group, and the wedding itself was at Quarantine Station, overlooking the harbour. It couldn't have been a more perfect location / weather / view for our friends' big day! We squeezed in a couple of the open-top bus tours of Sydney on the Sunday, but got caught in the horrendous storm that hit and ended up sheltering downstairs under cover on the bus. I'm told Bondi is lovely, but it all looked grey from the bus. :-P

Down to Melbourne on the train (bit of a wasted day, in hindsight), where we wandered around the city quite a bit. Caught up with an old friend who lives there for a day, and we did a wine tour up the Yarra Valley which was fun too.

Up to Port Douglas, where we headed out to the Reef for my highlight of the holiday: a snorkelling tour with some local marine experts who showed us the local flora and fauna. We also visited a local Aboriginal cultural centre, skyrail and scenic railway around Kuranda village.

Down to Hervey Bay and a 1-day tour of Fraser Island - an amazing place in combination with quite a thrill-ride experience just being driven around on the sand tracks. Finally, down to Brisbane where we wandered around and visited both the Lone Pine Koala Sanctuary (more cuddles!) and the Gold Coast. Then the long flights home. Whew!

We're knackered now. We knew we could't fit everything in, but we're glad we travelled all over and got tastes of almost everything. Now we can work out where we want to spend more time on our future visit(s). We'll definitely want to head over and see Perth and some of WA next time, and definitely more time in Tasmania, Sydney and Adelaide.

Catégories: Elsewhere

Lucas Nussbaum: Several improvements to UDD’s Bug Search and Maintainer Dashboard

Planet Debian - ven, 20/03/2015 - 08:36

Several improvements have been made to UDD’s Bug Search and Maintainer Dashboard recently.

On the Maintainer Dashboard side, the main new feature is a QA checks table that provides an overview of results from lintian, reproducible builds, piuparts, and ci.debian.net. Check the dashboard for the Ruby team for an example. Also, thanks to Daniel Pocock, the TODO items can now be exported as iCalendar tasks.

Bugs Search now has much better JSON and YAML outputs. It’s probably a good start if you want to do some data-mining on bugs. Packages can now be selected using the same form as the Maintainer Dashboard’s one, which makes it easy to build your own personal bug list, and will suppress the need for some of the team-specific listings.

Many bugs have been fixed too. More generally, thanks to the work of Christophe Siraut, the code is much better now, with a clean separation of the data analysis logic and the rendering sides that will make future improvements easier.

As the reminder, it’s quite easy to hack on UDD (even if you are not a DD). Please report bugs, including about additional features you would like to see!

Catégories: Elsewhere

Noah Meyerhans: Building OpenWRT with Docker

Planet Debian - ven, 20/03/2015 - 06:23

I've run OpenWRT on my home router for a long time, and these days I maintain a couple of packages for the project. In order to make most efficient use of the hardware resources on my router, I run a custom build of the OpenWRT firmware with some default features removed and others added. For example, I install bind and ipsec-tools, while I disable the web UI in order to save space.

There are quite a few packages required for the OpenWRT build process. I don't necessarily want all of these packages installed on my main machine, nor do I want to maintain a VM for the build environment. So I investigated using Docker for this.

Starting from a base jessie image, which I created using the Docker debootstrap wrapper, the first step was to construct a Dockerfile containing instructions on how to set up the build environment and create a non-root user to perform the build:

FROM jessie:latest MAINTAINER Noah Meyerhans <frodo@morgul.net> RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get -y install \ asciidoc bash bc binutils bzip2 fastjar flex git-core g++ gcc util-linux gawk libgtk2.0-dev intltool jikespg zlib1g-dev make \ genisoimage libncurses5-dev libssl-dev patch perl-modules \ python2.7-dev rsync ruby sdcc unzip wget gettext xsltproc \ libboost1.55-dev libxml-parser-perl libusb-dev bin86 bcc sharutils \ subversion RUN adduser --disabled-password --uid 1000 --gecos "Docker Builder,,," builder

And we generate a docker image based on this Dockerfile per the docker build documentation. At this point, we've got a basic image that does what we want. To initialize the build environment (download package sources, etc), I might run:

docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt sh -c "cd /src/openwrt/openwrt && scripts/feeds update -a"

Or configure the system:

docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt make -C /src/openwrt/openwrt menuconfig

And finally, build the OpenWRT image itself:

docker run -v ~/src/openwrt:/src/openwrt -u builder -t -i jessie/openwrt make -C /src/openwrt/openwrt -j3

The -v ~/src/openwrt:/src/openwrt flags tell docker to bind mount my ~/src/openwrt directory (which I'd previously cloned using git) to /src/openwrt inside the running container. Without this, one might be tempted to clone the git repo directly into the container at runtime, but the changes to non-bind-mount filesystems are lost when the container terminates. This could be suitable for an autobuild environment, in which the sources are cloned at the start of the build and any generated artifacts are archived externally at the end, but it isn't suitable for a dev environment where I might be making and testing small changes at a relatively high frequency.

The -u builder flags tell docker to run the given commands as the builder user inside the container. Recall that builder was created with UID 1000 in the Dockerfile. Since I'm storing the source and artifacts in a bind-mounted directory, all saved files will be created with this UID. Since UID 1000 happens to be my UID on my laptop, this is fine. Any files created by builder inside the container will be owned by me outside the container. However, this container should not have to rely on a user with a given UID running it! I'm not sure what the right way to approach this problem is within Docker. It may be that someone using my image should create their own derivative image that creates a user with the appropriate UID (creation of this derivative image is a cheap operation in Docker). Alternatively, whatever Docker init system is used could start as root, add a new user with a specific UID, and execute the build commands as that new user. Neither of these seems as clean as it could be, though.

In general, Docker seems quite useful for such a build environment. It's easy to set up, and it makes it very easy to generate and share a common collection of packages and configuration. Because images are self-contained, I can reclaim a bunch of disk space by simple executing "docker rmi".

Catégories: Elsewhere

Darren Mothersele: Introducing Stylex: Atomic design, style guides, and prototyping with Silex and Twig

Planet Drupal - ven, 20/03/2015 - 01:00

I've been working a lot with Atomic design (component-based design) with Drupal recently, and I've witnessed huge improvements on projects where it has been introduced. The main advantage being the decoupling of the development of the back-end from the development of the front-end code.

I've covered this in more detail previously, I'm running some workshops on Atomic Design in Drupal, and I have more to say on this in the future. Today I want to tell you about a simple tool I'm using to speed up the process.

The main purpose of this tool is to simplify the construction of prototype sites or style guides for front-end code. There are several tools already available, including the excellent Pattern Lab, but I wanted something incredibly simple.

I basically just wanted to make use of the power of Twig templates for mocking up front-end code, with an easy way to load in demo content (from yml files).

 Barebones project

I've created a barebones Stylex project on GitHub that demonstrates this, but you probably want to follow along in the setup, so you know what's going on...

Basic setup

I've packaged this for Composer so getting started is easy. Assuming you already have Composer installed globally all you need to do is create a folder for your project and run the following command:

composer require darrenmothersele/stylex dev-master

This will download Stylex from Github and all the dependencies. It creates the composer.json file for you and downloads all the code for the dependencies into a vendor folder.

As a bare minimum you will need to create a index.php to run the application, and a starter template templates/index.html.

Create a file in the project root (same location as the generated composer.json file) called index.php with the following code:

<?php require_once __DIR__ . '/vendor/autoload.php'; $app = new Stylex\Application(); $app->run();

Then create a templates folder and create the first page template, templates/index.html in this folder:

<html> <head> <title>Hello!</title> </head> <body> {% block content %} <h1>Hello, world!</h1> {% endblock %} </body> </html>

You can run the application with PHP's build in web server. Simply run the following command:

php -S localhost:8000

Now, browse to http://localhost:8000 to see the website.

Adding pages

You can add more pages, and make use of Twig's awesome template inheritance feature. For example, to create an 'About us' page, create a new file in the templates folder called about.html with the following content:

{% extends 'index.html' %} {% block content %} <h1>About us</h1> {% endblock %}

This inherits the whole template from index.html but replaces the content block with a new block of content specific to this page. Browse to http://localhost:8000/about to see the result (make sure PHP's web server is running - see above).

Using data

You can create YAML data files and then use them in your templates. Create a folder called data and then add *.yml files with your data. In any template these are then available using the filename. For example, to create a data file for your navigation links, create a file called data/main_menu.yml with the following content:

- title: Home path: / - title: About Us path: /about

Because the filename is main_menu.yml this data is now available to read in template files using {{ main_menu }}. Let's add a component template to style the menu. See my posts on Atomic design in Drupal to find out more about component templates. For now, just create a file in templates/components/menu.html with the following content:

<ul> {% for item in main_menu %} <li> <a href="{{ item.path }}">{{ item.title }}</a> </li> {% endfor %} </ul>

Now you can include the menu in your page template, by adding the following to your index.html file:

{% include 'components/menu.html' %} Using sample content

Stylex supports creating sample content using Markdown format with YAML front matter. This is a simple way to manage blobs of content with associated metadata. By using Markdown and YAML together to create sample content you can keep the sample content out of your front-end mockups and prototypes. This is another useful decoupling that makes life easier.

In this approach sample content is stored in subfolders under a content folder. You can have multiple types of content, and organise them into subfolders under a main content folder. Let's create a first article as an example. First create your content and then content/articles folder, then create a sample file called content/articles/first_post.md with the following content:

--- title: My First Post excerpt: Lorem ipsum dolor sit amet, consectetur adipisicing elit. image: http://placebee.co.uk/640x480/1 --- Lorem ipsum dolor sit amet, consectetur adipisicing elit. Voluptas ipsam veritatis officia unde incidunt doloribus veniam eligendi ea maiores delectus excepturi aspernatur illum, voluptates quas odit harum cupiditate cum maxime...

See the Stylex Barebones for the full example, I've abbreviated the content here. The main point is to show how you can include YAML metadata above the main Markdown formatted content.

You can then reference this content from your templates. For example, to print out the title of that first post you created, use the following in your Twig template:

{{ content.articles.first_post.title }}

Or, more useful, print out the titles of all articles:

{% for post in content.articles %} <h2>{{ post.title }}</h2> {% endfor %}

Or, yet even more useful (if you're building an atomic design), output all the articles using a component template:

{% for post in content.articles %} {% include 'components/teaser.html' with post only %} {% endfor %}

For this to work, create a component template for the teaser by creating a templates/components/teaser.html file with the following content:

<div class="teaser"> <h2 class="teaser-title"> {{ title }} </h2> <img src="{{ image }}" alt="" class="teaser-image"> {{ content|raw }} </div>

You can create subfolders to organise different types of sample content, for example, add an events folder content/events and they will be available in your templates as {{ content.events }}

 Debugging

If you're getting error messages, you can turn on debugging. In the index.php file that you created simple add the following line before $app->run();

$app['debug'] = TRUE; Conclusion

This just does the basics to allow you to use Twig templates to quickly build out front-end code. It reads in sample content and data from yml files and allows you to easily combine them with template files to create a prototype site.

The next step is to reset Drupal's markup and get it generating the exact same markup. This is covered more in my Atomic Design in Drupal workshops.

You'll probably want to add your favourite front-end tools into this. In particular, I like to add a Gruntfile to do less/sass compilation, etc.

Drop me a line if you find this useful, or have any ideas for how it can be improved.

Thanks!

Darren

Catégories: Elsewhere

Code Karate: Creating a hierarchy of users with the Drupal Subuser module

Planet Drupal - ven, 20/03/2015 - 00:57
Episode Number: 198

In this episode we cover the Drupal Subuser module. This module makes it easy to allow your users to manage other users on your site. This works great if you want to allow a site manager to be able to add in users of a specific role, but not have access to the full Drupal User Administration pages.

Tags: DrupalDrupal 7Site BuildingDrupal Planet
Catégories: Elsewhere

Zlatan Todorić: Icelandic Pirate Party

Planet Debian - jeu, 19/03/2015 - 23:59

So according to latest survey the Icelandic Pirate Party is now the largest party in this awesome country. A reason more to move there, double of reasons to learn from the country that shown so many examples for society in last 6 years. Are they springing a new great modern society?

Catégories: Elsewhere

Drupal core announcements: Propsed policy: Re-activate the head2head project and use it for D8 beta-to-beta upgrades in the short-term

Planet Drupal - jeu, 19/03/2015 - 22:37

In order to support a beta-to-beta upgrade path for Drupal 8 users sooner, the core committers have posted a proposal that recommends re-activating the http://drupal.org/project/head2head project in contrib and building the beta-to-beta upgrade path there in the short-term. This allows early adopters to have access to an upgrade path much earlier than core would be able to provide, and also gives us a "safe space" to test beta-to-beta upgrades prior to supporting them formally in core, without slowing down our current velocity on critical issue fixing.

Please share your thoughts, especially if you're one of the adventurous early adopters who are actively building on Drupal 8 already!

Catégories: Elsewhere

Lior Kaplan: CVE assignment without upstream knowledge

Planet Debian - jeu, 19/03/2015 - 18:33

In the past few months I’ve been dealing with aligning PHP CVE information to enable easier tracking of security fixes. The two main locations are the NEWS file which is part of each release and the changelog available on the website which is more popular (and easier to update).

Usually the CVE are assigned per PHP.net security team request or with cooperation with one of the Linux distribution’s teams (either PHP or security), as should be in a good ecosystem.

Recently I got a few notifications issued by Debian about its PHP package, which I wasn’t familiar with these CVE IDS. When checking this, I found out a few CVE assigned per 3rd party (Linux distribution, bug reporter, etc…) request without upstream knowledge. Digging deeper I found out that some CVE were assigned a month after the fixes were released, while others were only a week or two after. While this makes sure the security information is documented, it’s harder to add the information after tagging and releasing.

In another case, while discussing about a CVE for a specific bug, we found out one was already assigned per the reporter’s request but without the our or the upstream library knowledge. Even if the issue isn’t severe, upstream should get a fair chance to fix issue before making them public. Which also leads to a problem with requesting CVE IDs on a public mailing list which in some cases leads to security information leakage. We should balance transparency with some grace period for upstreams (as projects share code).


Filed under: Debian GNU/Linux, PHP
Catégories: Elsewhere

Shomeya: All about that trace, 'bout that trace

Planet Drupal - jeu, 19/03/2015 - 17:25

No one likes debugging code when it breaks and you can't figure out why it's broken. That piece of code might have been hard enough to write in the first place, or maybe it's a snippet that "should work" from a coworker, or maybe the documentation is missing, or maybe.... But what if you've checked, double and triple checked, and it's still not your code, it's something else in the system – code you're calling out to, or something that is calling your code – what do you do then?

Enter the backtrace, (also known as stack trace, or just trace). A powerful weapon in any software developers toolkit, it is more and more useful as the software you develop grows in complexity (Drupal 8 anyone?)

Read more
Catégories: Elsewhere

Drupal Easy: Book Review: Programming Guide to Drupal

Planet Drupal - jeu, 19/03/2015 - 16:20

O'Reilly's Programmer's Guide to Drupal, written by Jennifer Hodgdon is a solid book for Drupal developers of all skill levels. I'd argue that it is one of the better books for PHP developers wanting to learn more about Drupal. It provides a wealth of solid information on a nice array of topics that professional Drupal developers should know. It's not a long read (less than 100 pages of actual content), but the structure and variety of topics covered makes it a great reference for best practices and intermediate to advanced "what's the best way to do this?" topics in Drupal development.

-->

read more

Catégories: Elsewhere

Drupal Watchdog: Painless User Docs

Planet Drupal - jeu, 19/03/2015 - 15:21
Article

User documentation is a tricky thing to manage. On the one hand, docs are invaluable to your clients. But on the other, keeping “Write User Manual” at the top of your priority list is next to impossible, especially as you approach your go-live date.

The secret to squeezing good user docs into your schedule is to approach them the same way you would any other deliverable: create as little as possible from scratch by building on work you’ve already done, keep your users in mind at all times, and work efficiently.

That all sounds pretty familiar, right? Let’s talk about how to adapt these practices to user documentation.

Build a Template

Every site you build is different and requires a tailored set of docs. But that doesn’t mean you should be writing documentation from scratch each time. Instead, take a few hours to pull together a docs template. Working from a template can take the documentation process from a long, painful slog at deadline-time to a set of manageable little writing sprints, spread out over the entire development process.

Where to start?

First, pull together the elements that will appear in every user manual, for example, a general introduction to Drupal. Include chapters that cover the steps in content creation, an overview of the administrative menus, and a layman’s definition of things like nodes, blocks, and views. All these chapters will remain virtually untouched, from one site to the next, saving countless hours of writing.

As you build out the framework for your docs, keep your content as modular as possible. Creating self-contained chunks does two things for you: it makes it easy to rearrange sections from one manual to the next – without extensive rewrites – plus, it helps you keep track of what content needs updating and what doesn’t.

Once you’ve got the basics covered and the overall structure of your template worked out, writing your docs will be a simple matter of filling in details. If you write up features and functionality as they are being built, by the time you’re in the deadline crunch, your docs will be 90 percent complete.

Catégories: Elsewhere

Patrick Matthäi: Todays wheezy-backports work

Planet Debian - jeu, 19/03/2015 - 13:30

Hello,

I have updated geoip in wheezy-backports today from version 1.5.0-3~bpo70+1 to 1.6.2-4~bpo70+1, which includes also the new generators for the City and ASN database. This is also a prerequisite for the upcoming geoip-database updates!

For the otrs users: Now you can also install otrs 3.3.9-3~bpo70+1 in Wheezy, instead of the realy old version 3.2.11-1~bpo70+1.

Catégories: Elsewhere

Cheppers blog: Rebuilding the Cheppers website with Drupal 8: On The Road

Planet Drupal - jeu, 19/03/2015 - 11:59

The Cheppers team has decided to make our new website with Drupal 8. You can read about how and why we made this decision here. The following series of posts will document our progress, share the important lessons we learn, and highlight any mistakes we make in order to help others as they set out to use Drupal 8. This post will focus on exporting and importing site configuration.

Catégories: Elsewhere

Mario Lang: Why is Qt5 not displaying Braille?

Planet Debian - jeu, 19/03/2015 - 11:36

While evaluating the cross-platform accessibility of Qt5, I stumbled across this deficiency:

#include <QApplication> #include <QTextEdit> int main(int argv, char **args) { QApplication app(argv, args); QTextEdit textEdit; textEdit.setText(u8"\u28FF"); textEdit.show(); return app.exec(); }

On my system, this "application" does not show the correct glyph. If pretends to not know how to render 28FF. However, my braille display shows the correct character, so the encoding is OK. In the same X11 desktop, gedit and "cat" can display Unicode braille. So I apparently have the necessary fonts installed.

Any insights? What do I need to do, to convince Qt to display glyphs in the range 2800-28FF?

Catégories: Elsewhere

Patrick Matthäi: Egypt 2015

Planet Debian - jeu, 19/03/2015 - 11:31

Hi,

until the end of last week I were my first time in Egypt at Hurghada. Interesting country and culture but I have to think about it if I would travel again to Egypt :D

I also travelled to Luxor to visit the city itself, to drive on the Nil river and to visit some attractions like the Luxor-Temple and the “Totentempel of Hatschepsut”.

Catégories: Elsewhere

KnackForge: Programmatically create a node in drupal 7

Planet Drupal - jeu, 19/03/2015 - 10:17

Steps for programmatically creating node in drupal7,
1. Create a new node object.
2. Save the object using the node_save() function.

Basic Node Creation :

$complaint_body = 'Your node complaint body text'; $node = new stdClass();  // Create a new node object $node->type = 'company';  // Content type $node->language = LANGUAGE_NONE;  // Or e.g. 'en' if locale is enabled node_object_prepare($node);  //Set some default values $node->title = 'Your node title'; $node->body[$node->language][0]['value'] = $complaint_body; $node->body[$node->language][0]['summary'] = text_summary($complaint_body); $node->body[$node->language][0]['format'] = 'full_html'; $node->status = 1;   // (1 or 0): published or unpublished $node->promote = 0;  // (1 or 0): promoted to front page or not $node->sticky = 0;  // (1 or 0): sticky at top of lists or not $node->comment = 1;  // 2 = comments open, 1 = comments closed, 0 = comments hidden // Add author of the node $node->uid = 1; // Set created date $node->date = 'complaint_post_date'; $node->created = strtotime('complaint_post_date'); $path = 'content/mytest-' . date('YmdHis'); $node->path = array('alias' => $path); // Save the node node_save($node);

Add custom fields

Catégories: Elsewhere

KnackForge: Hide and override drupal status messages

Planet Drupal - jeu, 19/03/2015 - 10:17

      This blog describes how to hide and override drupal status messages while creating and editing nodes.

      When you create or edit the nodes, drupal displays status messages like 'node has been created' and 'node has been updated'. Some may not be interested to view these messages. You can hide these messages using drupal_get_messages(). It returns all messages that have been set using drupal_set_message(). You need to add it to a custom submit handler for the corresponding form. You can add custom submit handler using either hook_form_alter() or hook_form_form_id_alter() in drupal. 

       To hide drupal status messages, use the code below. For example, i have hidden the status messages only for article node form.

<?php /** * Implement hook_form_alter() */ function kf_form_alter(&$form, &$form_state, $form_id) { if ($form_id == 'article_node_form') { // to add custom submit handler $form['actions']['submit']['#submit'][] = 'kf_article_form_submit'; } } /** * Implement kf_article_form_submit */ function kf_article_form_submit($form, &$form_state) { // to hide drupal status messages drupal_get_messages('status'); } ?>

       Similarly you can override these status messages. For that, you need to add messages after drupal_get_messages() in the custom submit handler.

Catégories: Elsewhere

Bryan Braun: An Opinionated Guide to Getting Help with Drupal

Planet Drupal - jeu, 19/03/2015 - 04:12

You are facing a Drupal problem and you need help. We've all been there.

Drupal is a mature open source project with a vast community, so there are a lot places you can look for help*, and they all have their pros and cons. I’ve spent nearly 4 years trying them all and I found that some options work better for me than others. If you want to save yourself the experimenting and just use the opinionated approach I use today, then stick around; this is the guide to getting help with Drupal that I wish I had several years ago.

Without further ado, here is the list of support channels I currently use, prioritized in the order that I use them:

1. Google It

Many things can be solved quickly through an online search. Drupal.org has a search bar, and I tried to use it a lot when I was getting started, but I’ve since learned that you just can’t compete with Google when it comes to search. Pro-tip: you can search Drupal.org exclusively from Google by using the “site” keyword: “site:drupal.org."

Strength: Access to a ton of content. Exact searching of error messages.
Weakness: You often have to know the right vocabulary

2. Ask People you Work With

Online searches can fall short when your problem is fairly specific, or you don’t know the right vocabulary to use to describe your problem. Sometimes you just need to point at a screen and say “have you ever seen this before?” Face to face communication is fast, and effective (as long as you’ve got somebody experienced around you can talk to).

Strength: Face to face communication is often faster and easier
Weakness: Success will depend entirely on who you work with

3. Ask On Stack Exchange

Stack Exchange is a well-designed Q&A site that provides community-curated answers to programming questions. You’ll find that there are Drupal questions on both the main site (stack overflow.com) as well as the Drupal-specific site (drupal.stackexchange.com), but you’ll want to ask Drupal questions on the Drupal site. I have found the community there to be very active with most of my questions receiving responses in a matter of hours.

Strength: It’s a forum highly optimized for a good Q&A experience.
Weakness: The wrong kind of questions won’t survive here (like subjective questions or site-specific issues)
Link: http://drupal.stackexchange.com

4. Drupal.org Issue Queues

If you can isolate your issue down to a specific project (like a module, theme, or Drupal core) then you can go to the Drupal.org issue queue for help. If your issue has already been reported in the queue, you may find recommendations from the maintainer or even patches that fix the problem. Otherwise you can report the issue yourself. On one occasion I needed to fix an unfamiliar search-related issue that was outside my skill set, and I reported it in the issue queue of a contrib project. The maintainer got back to me in 2-3 days and posted a patch that fixed it. I benefited by getting a fix from an expert (which could have taken me days/weeks to figure out myself), and the project benefited from my QA work (the fix was included in the next module release). That’s the power of open source.

Strength: Can get expert feedback (and maybe even fixes) from module maintainers.
Weakness: Not useful unless you have isolated the issue.
Link: http://www.drupal.org/project/<project-name>/issues

5. Official Documentation

By official documentation, I’m talking about the Docs on Drupal.org, explanations on Module pages, or information found in README.txt files. These docs are often a great place to look if you are looking for help getting a module or theme installed and set up for the first time. Other than that, I haven’t had much luck browsing through them for my specific issues. The way I see it, if something in the official docs addresses your problem, you’ll come across it when googling your issue.

Strength: Entry-level instructions and set-up steps.
Weakness: Contains a lot of old information. Difficult to browse.
Link: http://drupal.org/documentation

6. Twitter

It’s hard to have a good conversation in 140 characters, but if you have enough followers who know Drupal (or you can get a retweet from somebody who does) then it can still be valuable. One way I’ve used it effectively is to ask my question on StackOverflow and then send the link out to Twitter to give it some attention if I’m not getting answers.

Strength: You may have more success asking your personal connections.
Weakness: 140 character limitation. Question can get lost in the mix.
Link: https://twitter.com

7. IRC

The Drupal community has IRC chatrooms on freenode at #drupal and #drupal-support designed for support. Some people really like using IRC for support; In some ways it’s like the “asking people you work with" suggestion above. That being said, I’ve always struggled to get answers via IRC. I feel awkward jumping in when there are already conversations in the channel, and several times I’ll ask a question but it promptly gets lost in the back scroll with no response. Plus, questions asked in IRC are usually not archived or searchable so the conversation you have won't benefit future people with your problem. So your mileage may vary, but I’ve yet to have a successful support experience on IRC.

Strength: Community of experts
Weakness: Chatrooms are not designed for Q&A.
Link: http://drupal.org/irc

Other Options

There are other options that I won’t discuss in detail. They all have strengths and weaknesses (which I’ll list below), but they aren’t really part of my main help workflow for one reason or another.

  • Drupal.org Forums - My questions have gone unanswered here. I’ve seen successful threads, but they seem pretty rare to me.
  • Groups.Drupal.org - Quality varies widely from group to group. I’ve seen groups with good discussion and others with lots of spam.
  • Local User groups - Good for subjective questions but not deep troubleshooting.
  • Books - Good for generic instruction, site building, and walkthroughs but not for heavy custom development.
  • Training - Can be online, on-site, or workshops. Good for generic instruction, site building, and walkthroughs but not for heavy custom development.
  • Conferences - Good for generic instruction and subjective questions. Not great for deep troubleshooting.
  • Example modules - Good for learning Drupal coding patterns but not for troubleshooting
  • Professional Services - Good for getting high-level architecture and security recommendations. Offering varies depending on the provider.
  • Api docs - Good for looking up specific Drupal  API functions.
  • [Insert your social network here]

Finally, whatever you ask, and whoever you ask it to, remember that you have a responsibility to ask good questions.

* Here’s the official drupal.org page on getting help (we covered all the options here and more).

Catégories: Elsewhere

Pages

Subscribe to jfhovinne agrégateur