The goal of the Spark distribution is to incubate authoring experience improvements in a Drupal 7 and Drupal 8. It was announced earlier this month, and since then we've been hard at work on initial research and design.

The Spark team's primary focus is on improving Drupal's content authoring and editing experience, and the first feature we're prioritizing is in-place editing: the ability to edit content, menus, etc. directly on the page, without the need to navigate to a separate edit form. Think of it as "true" WYSIWYG.

Members of Acquia's design team spent time analyzing how some of the most widely adopted Open Source as well as proprietary CMSs do in-place editing. We then prototyped some initial ideas, and performed usability testing on those prototypes to see what works and what doesn't. After a number of iterations, we're happy to report that the usability testing has validated Spark's general design direction. People loved the prototype. Now is a good time for us to share our initial prototype and to solicit further feedback from the community so we can shift gears into implementation.

The following 5-minute video walks through the HTML/JS prototype, and also provides a bit of background on the Spark project:

Our goal is to deliver this functionality in a contributed module for Drupal 7 first and foremost, which will live at the In-Place Editing project on drupal. This module will be bundled into the Spark distribution. Depending on how it is received, I hope we can also target this functionality for Drupal 8 core.

From a technical architecture standpoint, we are currently in the process of selecting the WYSIWYG editor to use in Spark for in-place editing of HTML content. For now, we plan to focus on supporting only the Filtered/Full HTML text formats in order to get us to something testable faster.

Later, we are hoping to branch out into other areas of authoring experience too, including helping with the content creation form improvements that the Drupal usability team has been spear-heading, as are well as the layouts UI work being actively discussed in the usability group. The Drupal usability team is doing an incredible job with these issues, and once fully staffed, I would like to see the Spark team help implement these improvements for Drupal 8 and backport them to Drupal 7 so we can ship it with the Spark distribution. (Did I mention that the Spark team is hiring? ;-))

As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if this functionality sounds exciting to you and you'd like to help!

This webinar covers background of the main componenents of services: servers, resources, and authentication. Followed by a live demo demonstrating session authentication, setup and configuration of a REST server, setup of a single endpoint, user and node resource examples, and testing via JSON protocols using tools like XHR Poster. This session is useful anyone seeking a quick way to integrate external applications with Drupal.

 

Create simple or complex publishing workflows for your content editors with this guide.

What’s new with the Open Outreach distribution for nonprofits? Lots!

There are now over 250 sites using Open Outreach. After working on getting this distribution up and running for so long, it's gratifying to see that it's starting to build some momentum. We’re looking for more Open Outreach sites to profile on the Open Outreach site, so if you’ve got one up and running, we’d love to hear about it.

Pilot project

As part of our efforts to get even more groups using Open Outreach, we’re launching a pilot project to help nonprofit and grassroots groups easily and affordably access this new distribution. The pilot will also allow us to gather evaluation materials to keep fine-tuning Open Outreach to meet groups' needs. We’ve got some interest but could use help getting the word out. If you work with or know about a nonprofit that needs a new Drupal 7 website, please direct them to the pilot project details. Thanks!

First Open Outreach release candidate

As of the latest release - our first release candidate, issued on May 10 - Open Outreach is now available as a fully packaged download on drupal. This is a great step forward and we’re appreciative of all the work that went into making this possible.

Speaking of releases, we’ve switched to new release approach. When security releases come out for Drupal core or contrib projects included in Open Outreach, we’ll offer a version just with those security updates. Then, when we offer a next version release it will include new functionality or bug fixes.

Next initiatives

Our next major focus in expanding the functionality of Open Outreach is to develop CRM integration. We’ve taken the first step in developing a Debut Member feature that provides members roles and incorporates content access to allow for private, members-only content. Next up is choosing a CRM solution to build on. We’re currently leaning towards a feature built on RedHen, the impressive native Drupal CRM initiative.

We're also working on adding Apps support, so it's easier to discover and add new Open Outreach compatible features.

New contributors

It’s great that other Drupal shops are starting to use Open Outreach to build sites. It’s even better that they are joining in with the development work. Thanks to EchoDitto for their work on developing some new candidate Debut features including Debut Press Release and to developer Paul Mackay for his work on Debut Newsletter and Debut Location. We hope to include some of these contributions in future releases of Open Outreach.

Pantheon version in the works

And finally, we are working with the Pantheon team to offer Open Outreach for install on their amazing platform. This is going to make it even easier for groups to get going using Pantheon’s great set up.

As always, to find out more about Open Outreach visit the site or contact us.

Thanks,

Nedjo and Rosemary, the Open Outreach team

Tags: 

• Open Outreach

Feed: 

• Drupal Planet

• Facebook
• Twitter

Today, I made public a whole bunch of commits I made while improving the Code coverage project for use with ReviewDriven. You may remember the screenshot I included in Part 2: Breathing new life into the testbot which is where this is coming from. Thanks to the improvements the module now actually works and is much more efficient, polished, accurate, and much more. With that in mind I am proud to announce the first stable release of the project targeted at Drupal 7.14.

Using the module you can get coverage reports for individual page executions or any combination of tests. Code coverage reports can be extremely useful in determining areas of code that are not tested at all or provide a snapshot of the code involved in generating a page.

Pages

Code coverage can be recorded by adding ?code_coverage=true to the end of a page URL. After the page has completed execution a linked will be placed at the bottom of the HTML which will display outside the page style.

The link will open the coverage report generated for that page request. The report will include all the files that where loaded during the execution of the page.

Tests

Similarly, a link is provided for the code coverage recorded during a test run.

Reports

The report includes two parts: 1) the summary or index, and 2) the line-by-line coverage information. The links described above point to the summary of the coverage information.

The links in the summary point to the line-by-line coverage information overlayed on the corresponding code. The colors indicate the following.

• green = executed
• red = not executed
• gray = ignored (or non-executable)

Filters

The coverage scope may be filtered to focus on improving coverage for a particular module/file/directory. Reducing the scope will also improve the coverage recording performance which may be useful when when dealing with large tests.

Future

I have already integrated the Code coverage project with Conduit (the open source ReviewDriven platform) which will be replacing the current system running qa.drupal. The plan is to get the new platform up and running in parallel with the current system at which time regular coverage runs against core (and contrib projects) can be made publicly available.

.node img { margin: 5px 50px; }

Tags:

• drupal
• code coverage
• qa.drupal
• reviewdriven

Drupal is a powerful CMS right out of the box. But let's be honest. The real reason that Drupal has gained such traction in the crowded PHP CMS space isn't because it is loaded with bells and whistles, but because it can be extended in seemingly infinite ways through add-on modules. In fact, there are well over seven thousand modules available from Drupal. Why is it that Drupal enjoys such a wealth of user-contributed add-on code?

The answer is that Drupal's API (Application Programmer Interface) provides the golden combination of simplicity and power. Almost every phase of Drupal's page building process can be intercepted and the data modified. But powerful modules can still be written in just a few dozen lines of code.

In the next few pages we are going to create a module from scratch. We will build a module using the Block API – the system used to generate block content. The module we create in this article is going to provide a block that displays the number of members (user accounts) on the site.

This is how we will proceed:

1. We will create a new module directory
2. Then we will create a .info (dot-info) file to describe the module
3. From here, we will create our basic .module (dot-module) file and introduce Drupal programming
4. Next, we will create a couple of “block hooks” to define the behaviors of our new block
5. Using the administration interface, we will turn on our new module and enable the block

Prerequisites

For this article, it is assumed that you have the following:

• Basic PHP development knowledge
• A running Drupal 7 instance with admin access
• Access to the filesystem for your Drupal 7 instance
• A code editor or PHP IDE

To get started, you will need a working Drupal 7 instance that you can access as an administrator. You will also need to be able to create files and directories inside of that Drupal installation. The examples in this article are done on a standard install of Drupal 7.0 with no contributed modules.

Creating a Module

Typically, a Drupal module has at least these three pieces:

Author Matt Butcher

Matt Butcher is a Senior Developer for ConsumerSearch, an About /New York Times Company. With over a dozen years of experience in web development, Matt has contributed to many Open Source projects. He maintains numerous Drupal modules. He is also the lead developer for QueryPath, a jQuery-like PHP XML and HTML parser. Matt has written six books (three on Drupal) and countless articles. He is a blogger on php|Architect and contributes regularly to IBM DeveloperWorks. He really likes milkshakes.

DrupalCon Munich is at the end of the summer, and will be here before we know it. Conference sessions and pre-conference trainings are now announced!

Tied into this year’s theme of “Open Up! Connecting systems and people,” our amazing local and global track chair teams worked diligently to review, rank, and select the final 78 sessions of the 333 sessions proposed. See all 78 Selected Sessions (80% of total number of conference sessions) from the following tracks:

• Coding and Development
• Community
• Frontend
• Business and Strategy
• Sitebuilding
• DevOps

These sessions join our Keynote Speakers and Featured Sessions.

Call for Core Conversations

Core Conversations session submissions are now open! Core Conversations are a place for people actively working and contributing to Drupal core or drupal to meet, discuss, and plan the future of Drupal. Have a 15 minute or 30 minute talk relating to Drupal core? Submit your talk today! Call for Core Conversations ends June 29 and selected sessions will be announced July 3 when BoFs open.

Early-Bird Registration + Prepaid Tickets

If you haven't bought your ticket yet, now is the time! The early-bird registration rate of 400 € will end June 15 at 11:59 CEST. After this, ticket prices increase to 475 €.

Are you purchasing DrupalCon tickets on behalf of one or more people? Buy prepaid tickets for your team now and capture the 400 € ticket price (until June 15).

Prepaid tickets can be redeemed for DrupalCon registration up until August 17 at 11:59 CEST when online ticket sales and registration closes.

Register Now and Save!

sessionstrainingCore ConversationsBoF

This week David Hahn joins me to talk about starting and growing a local Drupal User Group.

Here's what we talked about: Starting a local Drupal User Group

• How is a user group different from a DrupalCon or Drupal Camp?
• Is there a format that’s best? (one presenter, many presenters, support desk)
• How did you choose a physical location? (Are there things that you need ie: projector, one big table, many small tables?)
• What do you talk about in a user group?

Growing a local Drupal User Group

• How do you get more Drupal users to come out? (groups.Drupal, facebook)
• When attendance is sporadic, how do you attract/retain consistent members?
• How do you set (or change) expectations of attendees if everyone’s just coming to hire/get help with a specific problem?

Questions from Twitter... (well, actually email this time)

• Phil Ward asked:
  1. How do you hold meetups that cater to all levels of experience?
  2. At what point do you start holding informative meetups and migrate away from just chatting?
• @transition asked:
  1. We face a couple of challenges with our DUG. One is getting more local Drupalers to come out. This month we started to experiment with Lightning Talks and we may steal the "Drupal News" idea I just saw. So, what suggestions does DJ Hahn have for that? Now we're using G.D.O and Facebook to get the word out. But our attendance is lower than we'd like and it's sporadic. Not many consistent, repeat attendees. How do we attract/retain a critical mass?
  2. The other issue is the TYPE of attendees we often get. Too often we're getting what I'll call 'talent grabbers', instead of people interested in making a contribution to the Drupal community. It's a mix of the following types.
     1. "I'm looking for a Drupal Expert to...":
        • work on a rush project we promised someone else we could do. We don't know much about Drupal, but we heard it was cool.
        • do my Drupal for me. I started a Drupal project, but it's too hard now and I don't want to be bothered with it. In either case, sometimes there's a suggestion of said "Drupal Expert" being paid, but it's often iffy.
     2. "I want a specific answer to my specific site development question/problem." I realize this is a common task for User Groups, but without the critical mass, it turns our DUG into a very small "Live Drupal Help Desk", which people will think SUCKS if we don't have answers to every esoteric question.
  3. I've been to a few other local tech meetups and I've seen similar issues, so I know it's not JUST us. But our core group is smaller, so the problems seem bigger.  Should we work more on trying to DEVELOP the local Drupal community/ecosystem (create our own farm team of people who can/will contribute)? Or are we not going about reaching the existing community in the best way?
  4. Also, do we have dates yet for Dallas Drupal Days? :-)

Submitted on Wed, 05/30 - 00:00

One of the hardest concepts for new users of Drupal to grasp is that Drupal is not a page management system but a content management system. That may seem obvious, but it's actually an important distinction; Drupal doesn't think in terms of pages but in pieces of content. Not every page that will be displayed is a piece of content, and not every piece of content will have a page.

To understand how to build pages in Drupal, it's important to understand the Drupal Stack; that is, the order in which a Drupal architect will approach a build-out. There are actually four separate and distinct concepts at work: Content, Data slices, Layout, and Display. (See Figure 1.)

• By Content, we mean the data model within Drupal. Generally this means nodes and fields—Drupal's primary content object—but in Drupal 7, it refers to any entity and entity type. This is the structure of the content we are managing and how different pieces of content inter-relate;
• Data slices are sections of our content that we want to display. In the vast majority of cases, these are defined using the Views module. Each of these slices ends up as a displayable chunk, such as a block or a page callback;
• Layout refers to how those displayable chunks are placed on the page. Generally there are two ways that is done in Drupal: either with the core blocks system or with the contributed Panels module;
• Display, finally, refers to the visual look and feel of the site. This is the theme layer, which is composed of HTML, CSS, and sometimes Javascript.

As with most parts of web design, designing in layers allows for a more robust, flexible, and sustainable end product. Let's look at each in turn.

Author Larry Garfield

Larry has been building web sites since Webcrawler was still the leading search engine. Before coming to Drupal he took a sabbatical for several years to work as a Palm OS developer and mobile product reviewer. These days he haunts Palantir where he was the technical lead for the DrupalCon Chicago Mobile app. Currently he is leading the Web Services initiative for Drupal 8, and occasionally remembers to sleep. Larry also recently co-authored Drupal 7 Module Development from Packt Publishing.

For consistency's sake it is always a good idea to output any file download links the same way throughout any website. If you are using file uploads attached to nodes on your Drupal 7 website, this is generally taken care of for you. You will notice that all file links are displayed with a consistent icon set (which can be overridden), as well as a consistent link. This applies to all node pages and any views that contain the downloadable files.

Post Topics:  Drupal Drupal 7 Core Concepts Drupal Planet

read more

Our support and maintenance customers aren't always previously existing clients of ours. In some cases, we're brought onboard to extend, modify or maintain existing Drupal websites that were created and configured by a different vendor. We absolutely take pride in being a go-to resource in terms of Drupal maintenance and support, but jumping into a project mid-life can present a variety of, well, crises. One of those is file permissions.

Permissions getting you down

Every systems administrator has their own custom tailored approach when it comes to file permissions. In some cases this approach is fairly straightforward; in some cases it's not. And then there are servers that have gone through a variety of administrators, each leaving their respective evidences in the form of users, user groups, filesystem owners and the like. When it comes to support and maintenance, my primary goal isn't to call server administration shots. My first order of business is simply to gain the access I need to begin module upgrades, front end adjustments and custom development without stepping on anyone's toes or blowing a server's security wide open.

There are probably a few approaches to ironing out file permissions before digging into to the real fun Drupal development stuff. Here's the one I took:

When it's a group thing, nobody gets left out

The basic idea is to create a new user group, add all current filesystem owners to that group, grant the group appropriate access, then change the Drupal base directory's group to your new group. This will provide the access necessary for you to get on with your Drupal administration without cutting in on any users' pre-existing permissions or file ownership.

In order to proceed with the approach I'll be outlining, I'll be making three assumptions. If these don't sound like your situation, you may want to check out a different solution.

1. You're working on a fairly standard Linux / Unix server (We'll say the Drupal install directory is at /public_html)
2. Your client or third-party vendor has created a user for you (We'll call it supportperson)
3. Your client or third-party vendor has either granted you root access or is willing to perform some operations for you as root

Let's say that file ownership of your base Drupal directory is distributed between several users: root, apache, adminperson and sysadmin. Your user, supportperson, doesn't own a thing. Time to make this a group affair:

# As root, create a new group groupadd webadmin   # As root, add each preexisting user, minus *apache* to your new group gpasswd -a adminperson webadmin gpasswd -a sysadmin webadmin   # Don't forget to add yourself gpasswd -a supportperson webadmin   # Adding apache to your new group may introduce some security concerns, but you still need to ensure apache can read and write from the files directory. We can just change the files directory owner to apache chown -R apache sites/all/files/   # From the webroot, go down one folder then change the webroot directory's group cd .. chgrp -R webadmin public_html/   # Now add write and execute permissions for the webadmin group. You'll need this to go Drupaling chmod -R g+wx public_html/   # You're done here! Let's get out of root exit

That's it! At this point your user, supportperson, should have everything it needs to manage your Drupal website. You're also done with root access, so you won't need to play Russian Roulette every time you want to poke around on the server.

This post will give you a list what to check when you go live with a drupal 7 website and how you can control it and automate it. You need to check this go live checklist each time you keep integrating new stuff during deployment to test if everything is still working. To save time this task can be automated.

Intro Read moreSubmitted by Dominique De Cooman on Tue 05-29 14:31automation configuration d7tip golive webmasterDrupal 7 tip: How to automate and control your go live checklist

read more

Start:  05-29 19:00 - 20:00 UTC Online meeting (eg. IRC meeting) Organizers:  JohnAlbin

Please join us for our next IRC meeting to discuss issues related to the Drupal 8 mobile initiative. The meeting will be held in #drupal-mobile on IRC at 19:00 UTC on Tuesday, May 29. Using IRC is easy; Drupal provides a guide to using IRC.

Tuesday, May 29:
San Francisco — 12pm
New York — 3pm
London — 8pm
Taipei — 3am (Wednesday)
Convert to your timezone

Agenda

As a reminder, the scope of the D8 Mobile Initiative includes:
- Mobile-friendly Drupal admin
- Responsive design issues
- Front-end performance
- Converting existing D8 themes to be responsive

• Bring your issues to review and discuss!

Please post your proposed discussion topics in the comments.

• Drupal 8 Initiatives

Start:  05-29 12:00 - 13:00 America/Los_Angeles Online meeting (eg. IRC meeting) Organizers:  heyrocker

Hey everyone! It's that time again! Lets gather around the campfire and discuss what is up with the configuration management initiative! Specifically I'd like to get more discussion around some architecture cleanup discussion we've been having and also report the results of a long conversation we had this week about internationalization. Anything else to talk about? Let me know!

The meeting will be held in #drupal-cmi on freenode.

• Core

As it often is, sexism in the tech industry was the topic of a lot of back-and-forth on Twitter this past week. It started with the revelation1 that a modeling agency in Denver had been contracted to staff "booth babes" in the DrupalCon exhibit hall back in March, and continued (as it so often does) with debate over what behavior is appropriate at professional-ish industry events like DrupalCon.

The issue of "booth babes"2 is the one that got under my skin the most, so let's talk about that. First, allow me outline my basic position on the issue:

• I have no problem with sex. Sex can be a natural, zesty enterprise, but that doesn't mean it has a place at professional events.
• I believe that the mere presence of "booth babes" is actively detrimental to the gender equality of any event or the industry in which it takes place.
• I do not think a dress code for booth staff or event attendees is appropriate, nor am I convinced (yet) that this is a problem that should be addressed by an official code of conduct or exhibitor agreement or anything like that.

The problem with booth babes is simple: hiring sexy ladies to stand at a booth and attract men to it results in those men assuming that beautiful women in the booths are only there to attract them.

That's it. It's not some puritanical view of sex, as was suggested to me, nor a problem with sexiness, as was suggested to others.

I don't know why this is so hard to get one's head around. Booth babes are there only to sexually arouse men3 and draw them into the booth. They cannot answer questions about the product or provide deep information about it.

Their knowledge of the company or product is not the problem, though; the problem is that everyone comes to assume that the sexy ladies in the booths are just that: sexy ladies who don't know anything about the product. Women who are actually active in the community and industry (and who already have a hard enough time being taken seriously in said) are then brushed aside by those who assume that they're just there as eye candy.

This fact was driven home for me when I was talking to a guy at DrupalCamp Maryland a few months ago. The topic came up, and he proudly announced that when he's interested in a company in an exhibit hall, he'll walk straight past any women to the nerdy-looking dude at the back of the booth, figuring that he's the guy who actually knows what he's talking about.

He could not have made my point better for me, but I still had to slowly spell it out for him: this exactly problem. The women you walk past may well be the lead developer(s) on the product, but you assume they're just there as eye candy because of the fact that booth babes are around.

This is why some of the conversation on Twitter this week infuriated me so. It's not about any puritanical view of sex. It's not about being uncomfortable with sexiness. It's entirely about further marginalizing women in an industry where gender equality is a long-standing issue that needs to be addressed. There's no way that this is hard to comprehend, nor did anyone actually answer to this point on Twitter, so I can only assume that they would rather pretend that it's not a real issue.

The closest thing I got to a real response on this was the assertion that the person I was talking to had sexy guys at his booth, and I was being sexist for assuming that "booth babes" had to mean women.

Seriously, dude?

This point—and the long conversation that followed the next day, about what constitutes appropriate behavior among people who are attracted to others at tech events—points to an incredible blind spot that plagues members of our community who refuse to see this as a problem:

There is not gender equality in our world right now.

You can argue that it's sexist to assume that "booth babes" refers to women. You can argue from the position that men and women should be treated equally, and that women can hit on men just as men can hit on women, and there's no difference between the two. I can understand why one would take this position, from a logical standpoint, but it simply has no bearing on reality. Behaving as if we have achieved gender equality—and thus, that these issues do not exist—does nothing to rectify those existing inequalities. We can't just pretend that treating everyone equally will eventually make it so; it's going to take more than that.

As I noted earlier, I don't believe that an official code of conduct is the best way to address these problems: tech events should have one in place, but it will take more than that to make a real difference, and there are issues that cannot be adequately addressed by rules and regulations. For example, I was also told I was being sexist for proposing that women at these events should be held to a dress code, to prevent the kind of outfits that booth babes might wear. To be clear, I never proposed nor inferred this, but it indicates the problem with addressing this by official means: should there be a dress code in place? Should exhibit hall staff be limited to full-time employees of each company exhibiting? How can you regulate stuff like that?

I maintain that peer pressure is going to be a much more effective solution. We need to make it clear that we will not do business with the kind of company that thinks women are only good for attracting horny geeks to their booth. We need to call out colleagues who behave inappropriately, who make sexist jokes or harass other attendees or staff at these events. We need to explain—again and again and with small words when necessary—why "booth babes" and "booth dudes" are inherently unequal.

We'd all like to believe that gender inequality is a thing of the past, but people are so willing to demonstrate, time after time, that we aren't there yet.

Further reading:

• Dear Technology World – Please Stop Trying To Give Me An Erection
• What’s the big deal?
• Newsflash: sexism in geek communities demeans everybody
• The Elephant in the Computer Lab

1. It's worth noting that the modeling agency blogged about this months ago, but it only got any attention (as far as I know) when someone discovered the blog post last week. ↩

2. Do I need to keep putting "booth babes" in quotes? I feel like I should just because it is such an air-quotey term, but we all know what I'm talking about. ↩

3. Well, straight men and lesbians, but we know what the target demographic is. ↩

In my last post, we learned how to customize CKEditor with the WYSIWYG Module. We explored how to apply our own settings to CKEditor using a little javascript and a small custom module. Today we're going to delve even deeper into what we can customize in CKEditor. Specifically we'll be looking into the dialog API. By the time we're done with it, our CKEditor will be jacked up with a faux-hawk,  flaming skull tattoos, and ready to stroll into the club and punch the first guy that looks at him cock-eyed.

read more

Drupal 7's new Field API is a great feature. Unfortunately, theming an entity and its fields can be quite a daunting task. The main reason for this, is that the field variables that get passed to template files are not particularly themer-friendly. Themers are HTML markup and CSS coders; they're not PHP or Drupal coders. When themers start writing their node--page.tpl.php file, all they really want to know is: How do I output each field of this page [node type], exactly where I want, and with minimal fuss?

It is in the interests of improving the Drupal Themer Experience, therefore, that I present the Template Field Variables module. (As the project description says,) this module takes the mystery out of theming fieldable entities. For each field in an entity, it extracts the values that you actually want to output (from the infamous "massive nested arrays" that Drupal provides), and it puts those values in dead-simple variables.

Koumbit is recruiting a PHP programmer/analyst.

The technical qualifications of the candidate should include programming, system configuration, updates, and data migrations. As a consultant, the candidate should be able to understand and synthesize client needs, and offer personalized support and training as needed.

The candidate should have a degree in computer science or equivalent training and experience. They should be versatile, familiar with programming for the web and agile development, able to work well independently, and able to adapt to the evolving needs of the organisation. Experience working in the non-profit sector is an asset. A desire to help community organisations find ways to use technology effectively and strategically is essential.

The primary responsibility of the candidate will be the development and customisation of websites created with Drupal and/or CiviCRM. Drupal is a popular content management system (CMS), and CiviCRM is a client relationship management tool used by non-profits to manage members, on-line donations, and events. Both are free & open source software projects based on PHP and MySQL. Experience with Drupal and/or CiviCRM would be an advantage but is not a requirement for a candidate able to rapidly learn new software platforms. Candidates should be able to communicate in French. A high level of written and spoken French would be an asset but is not a requirement.

Koumbit has developed websites for local and international non-profits. Founded on principles of openness and equality, we specialize in free software and are organized as a non-hierarchical collective. Koumbit employees set their own work schedule and participate in the decision making process of the group. They earn a common salary of $23 per hour.

You can meet our team each Friday afternoon at our office at 6833 avenue de l'Épée, suite 308.

AttachmentSize

During past 2 weeks we had slow progress on all fronts, with the biggest impediment - resource constraints (as in too few people to do too many things).

We are very close to deployment of updates to Case studies section on Drupal. This will be the first step of redesign of that section. In future we are planning to add slideshow (bmaheshs and the team at Tekriti Software are working on this right now) and various other enhancements.

read more

While vendor prefixes are a subject of constant discussion, the developers don't want to wait and are using it more and more. But due to their draft nature, prefixes changes so much that is very hard to keep track of them all.

“Border radius needs a prefix for Webkit... Maybe... And for Firefox? I know that don't need for Opera... I mean, well, is better to test it... I wonder if works with IE? AHHHHHH!!!!”
You're not alone.

read more