Drupal aggregator

titantemplatescom posted a photo:

ben.j.reed posted a photo:

A 3D render of the Drupal Icon. Created in AutoDesk Maya 2010 in full HD.

titantemplatescom posted a photo:

titantemplatescom posted a photo:

titantemplatescom posted a photo:

titantemplatescom posted a photo:

Knowledge Language English Thresholds, Code Freeze, Getting Features into Drupal 8, Criticals and Majors in DrupalCathy Theys06/11/2013 - 03:50

Instead of doing 2 things myself, I'm doing one and trying to make it possible for X others to do the same.

(OK, I might be doing more than one thing, but the sentiment is the same. grin)

I've been making a little noise about change records; posting instructions and encouraging people to take a stab at drafting the first versions for some change records. Why?

For many reasons, but one big reason is there are a few features I want to see get into Drupal 8 still.

Features?! Yep. There is still some hope of getting features in. I'm hoping for Add configuration translation user interface module in core, some issues from Refactor account workflow, ... and I'm sure other cool things.

...there are a lot of small, non-destabilizing features that would make Drupal 8 better. Especially for the kinds of iterative improvements that we would allow into 8.1 or 8.2, it doesn't make sense to hold those up until then, if we're able to get them into 8.0 without it delaying the 8.0 release date. To help with this goal, catch and I have discussed a plan for allowing some features to continue to be committed to core up until RC1, providing we are under thresholds.

-Dries from Code Freeze and Thresholds

More up-to-date information on where we are in the release cycle is in the Drupal.org release cycle page. The code freeze (API freeze) date for Drupal 8 is July 1, 2013... July 1 is quickly approaching.

What are the threshold numbers? We want to be below 15 critical bugs, 100 major bugs, 15 critical tasks, 100 major tasks

There is the possibility for new features, when issues are under these counts:

• Critical bugs, across D7 and D8: no more than 15 [We have 35, 0 RTBC]
• Major bugs, across D7 and D8: no more than 100 [We have 156, 8 RTBC]
• Critical tasks, across D7 and D8: no more than 15 [We have 39, 0 RTBC, 12 need change notification]
• Major tasks, across D7 and D8: no more than 100 [We have 156, 5 RTBC]

(Taken from Drupal core issue count thresholds docs page on d.o.)

What can people do?

We have a support system in place to help people and make that experience rewarding for the project and for the individual. Contributor task document pages help people figure out how to do what needs to be done.

You don't have to do a bunch, just picking one thing will really help. It is not hopeless!

Take for example change notifications. We really are making a dent in them already. Just in the last week, people have made 21 change records. Thanks ParisLiakos, larowlan, Gábor Hojtsy, Shyamala, tim.plunkett, fago, Wim Leers, patrickd, swentel, andypost, chx, Berdir!

• needs change notification 12 critical tasks need change notification and the Contributor task: Write up a change record for a Drupal core issue document helps anyone who has not make a change record figure out how to go through the process of helping make a change record.
• needs review 77 of the threshold issues need review and the Contributor task: Review a Drupal core patch document helps people get started reviewing, has a link to more detail on how to do reviews and xjm's review guide has tips too.
• needs manual testing 9 need manual testing and the Contributor task: Manually test a patch for a Drupal issue document helps figure out how to test, and also how to write up the results for posting back to the issue queue.
• needs accessibility review 4 need accessibility review and the Contributor task: Manually do accessibility testing of a patch for a Drupal issue document includes tools to help people get set up for accessibility reviews.
• needs issue summary update 84 need issue summary update and the Contributor task: Write an issue summary for an existing Drupal Core issue document gives a strategy for tackling issue summaries. Anyone can edit the issue summaries and it is more than just pasting in the html from the template, it is also making sure the information is there regarding the motivation, remaining tasks, etc. Another thing that helps issues, is adding a steps to reproduce, related issues and follow-up issues section to the issue summary. Issue summary updates are an investment, and take a bit of time, but they are worth it and are key to getting things moving in Drupal 8 (See: xjm's Help!).
• needs tests 49 need tests and the Contributor task: Write an automated test for a Drupal core bug document is a good starting point. Also helpful are: simpletest documentation for a start on using SimpleTest and xjm's presentation from MWDS on tests.

Coordination. So many people starting to work on so many tasks.

Pick an issue you want to work on, then add a comment on the issue saying what task you are about to start doing. (Typically the assigned field is only used when someone is actively making a new patch for an issue. For other tasks, like reviews, drafting change notices, issue summary updates, etc, making a comment on the issue is fine.)

Have questions?

It's ok to ask questions in a comment on the issue. It works well because people "following" the issue will see your question and can help you out.

Want real live support, from humans?!

From the irc bot factoid: core mentoring?

Want to contribute to Drupal core? Come to core contribution mentoring!  Two timeslots, (Tuesdays 02:00 UTC and Wednesdays 16:00 UTC) in #drupal. More info: http://drupal.org/core-mentoring, http://modulesunraveled.com/podcast/003-jess-and-core-office-hours-modules-unraveled-podcast. | Twitter: @drupalmentoring | Create an account at http://drupalmentoring.org

Or try the #drupal-contribute irc channel any hour of the day.

Daniel Mai posted a photo:

Site criado para loja de lingerie.
Tecnologias:
✓ Drupal
✓ HTML + CSS
✓ Flash

☆ lotusdalua.com

titantemplatescom posted a photo:

titantemplatescom posted a photo:

Recently, I had the special fun of migrating a new client’s site over to a new host. Everything was going smoothly and quickly until I got to the Files folder. It contained a 4-gigabyte hodgepodge of images, thumbnails, pdfs, known site backups and unknown site backups (Yes, unknown! I don't count the WordPress version of the site from six years ago as a "known about" backup). It got me thinking about one part of Drupal that I think many take for granted: The Files system. Drupal is three-part system: Database, Code and Files. When planning a site architecture, often the Files folder gets treated like the red-headed step child of the three; forgotten, neglected and rather ignored.

However, that’s not the way it should be. Drupal is a content management system. No matter what type of content, whether doc, image, or a PowerPoint on how many kittens and puppies it takes to make a good calendar, Files are just as much content as the text describing said cute kittens and puppies. And this type of content is much easier to manage then most people think.

I’m not talking about the Media module, a hopeful dream of the Drupal world that I still believe in and could still use some more loving. I’m just talking about what comes after "sites/default/files/..." When writing new content, we often upload files and images along with our post about how our cat fell asleep in the kitchen sink. Instead of just having all those images and files placed first level in the Files folder, why not have them go into a "blog" folder or a "fluffy" folder. That way we don’t need to look at 10,000 images upon opening the Files folder.

When adding a file upload field to a content type, you can set a default path to house the files that will be uploaded. Using tokens, you can create default path structures that handle all the folder architecture for you. I like to separate folders by content type, year/month/day uploaded, taxonomy term, and/or type of file. An example token setup for a default path may look like this: [node:content-type]/[node:created:short] or [node:content-type]/[node:nid].

The benefit is that whenever I go into the Files folder, I have instant information about the files contained inside. An image with the name of 348jkdldhisoj.png is not helpful to me, but if it’s located at say "sites/default/files/blog/may2013/img/cat_photos/348jkdldhisoj.png," then I have a good idea of what that image is. If you are naming a folder without the use of tokens, be descriptive as to what that folder actually contains. Don’t label it “images” and expect the world to know what that universally means.

The point I’m making is you don't have all of your files on your computer located on your desktop, do you? No, you have them in human-readable, ordered folders. When I’m looking for my legally downloaded episodes of Family Guy, I don't want to have to look through a folder that also contains clips of my sister’s cat getting scared by his own image in the mirror (although that one always makes me laugh when I come across it). So put the same thought into your Drupal sites/default/files folder. Your site, the cats of the web, and your local Drupal support guy will appreciate it.

On a current site in development I am using Ubercart to provide a renewable subscription service. To make the user experience clean, I wanted to protect the user from going 'shopping' to add their subscription. To do this I decided to use a rule to add the product to the user cart when the user is created by an administrator or when the subscription is cancelled or fails payment. I tried the Ubercart Rules module, but this is mainly for dealing with orders and not carts, and did not contain the needed add to cart rule.

read more

I've been looking at various LiveChat modules for Drupal sites and after testing a number out I finally found one I liked, Zopim LiveChat.

It's slick, quick and provides all the basic requirements plus a few neat additional things such as user stats, history, visitor lists, customisable sounds. If you wanted you could have unlimited chats for $11.20 a month or the full version for only $20 a month!

read more

titantemplatescom posted a photo:

Drupal's editorial experience has improved considerably over the past several realeases, and Drupal 8 promises to be even better. However, it's still easy for writers and editors to collide with each other when they collaborate. If two people edit the same piece of content at the same time, one user's changes are inevitably lost. Fortunately, the Content Locking module is ready to help.

Adam Evertsson is the head honcho behind DrupalCamp Gothenburg two years in a row, member of the Swedish podcast Drupalsnack and always fond of the community, both locally and globally. He really came for the code and stayed for the community. 

Personal blog tags: drupalcamps

drush aliases allow you to run a drush commands on your local server but actually execute the command on a remote server. This is a real time saver when working locally and then you want to do something on the remote server. Your specific workflows will depend on your particular setup but, as an example on Acquia dev cloud, how about pushing code up to your remote dev server and running updatedb in two commands.

$ git push origin $ drush @site.dev updatedb -y

Setting up your local computer to use an alias needs a little configuration. Alias configuration files can go into a .drush folder in your home directory. You can add as many alias files as you like here with the naming convention:

sitename.aliases.drushrc.php

Each file can contain any number of aliases descriptions which are just entries in a multi dimensional array, the key of which is the subitem for that alias. For example, an alias file called mysite.aliases.drushrc.php with one dev entry like this ...

$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'example.myserver.com', 'remote-user' => 'mysite', );

... gives one alias which is accessed via the @mysite.dev drush argument. For example,

drush @mysite.dev status

There is also a drush command to get you started on producing an alias drushrc file:

drush sa [uri] Holy Cow! What else can I do with drush aliases?

I am glad you asked. How about download the remote db in one command ...

drush @mysite.dev sql-dump > /tmp/dbdump.sql

Note: don't use --result-file here as that will put the sql file on the remote server!

How about bring all the remote files down to your local system? From the root of the site on your local install run ...

drush rsync @mysite.dev:sites/default/files/ sites/default/files/

Note: Run drush help rsync for help with this one!

Notes on Acquia and Drush aliases

We often use Acquia dev cloud to host our client's sites. On Acquia hosted sites setting up local drush aliases are made very simple. Under the cloud menu on the subscription tab there is a utility link which describes exactly how to add the alias files to your local computer.

Acquia executes drush commands using drush 4 by default. To use drush 5, you'll need to edit your alias files in the .drush folder and for each environment add a path-aliases entry which describes which drush script to execute. The precise syntax is shown below.

$aliases['dev'] = array( 'parent' => '@parent', 'site' => 'mysite', 'env' => 'dev', 'root' => '/var/www/html/mysite.dev/docroot', 'remote-host' => 'mysite.com', 'remote-user' => 'mysite', 'path-aliases' => array( '%drush-script' => 'drush5', ), ); Other reading

This link shows all the goodness that can be put into a sites drushrc file ... http://drush.ws/examples/example.aliases.drushrc.php

Read moreDrupal, Drush aliases and how to use themBy John Ennew | 10th June 2013

It sometimes seems to me, that there are two different types of Drupal module maintainers: the ones who create a stable 1.0 release as soon as any code is working; and those who leave their modules "unstable" for years until they finally pluck up the courage to go 1.0. (I guess there also have to be some with the right middle approach, but those propably just don't catch one's eye as much.) There are actually projects in the top 10 of contrib module usage without a stable 7.x release (although there may of course be good reasons for that).
Anyways, in that pattern I'm definitely one of the latter group. I have only recently gotten to eventually creating stable releases for a number of modules (though some of them already had several thousand users) – Search API Database search (over 11k users) and Search API Pages (almost 3k users) are still waiting – and the 1.0 release of the Search API itself also took extremely long (by which time it also already had over 2000 reported* users).

In that context, it is kind of a milestone that there is now finally a 1.0 release of the Search API Solr Search module. (If you are not familiar with it, it's pretty self-explanatory: it allows you to use Apache Solr with the Search API.) As with the other modules, it had already been production-ready for quite some time, and currently has almost 5000 users.

In the case of the Solr Search module, though, there were several good reasons to wait with a stable release – foremost, the Apache Solr Common Configurations project, though definitely a good thing, changed the configuration files quite drastically when the module was otherwise stable. We also managed to add numerous feature (like location search support) and fix a lot of bugs, but those would have probably worked as well in subsequent minor releases. There were some other major refactorings, though, (foremost the effort to get rid of the external library dependency) whose inclusion in the 1.0 release is definitely beneficial.

Additionally, for the Solr Search module the 1.0 stable release is also kind of a promise: with it, I'm saying that I'm now confident that no major changes to the config files will be necessary anymore, so that there won't be the necessity for re-indexing the content for future new (minor) releases. Time will tell whether I'll be able to keep that promise but, as said, I'm quite confident.

So, if you shied away from giving the module a spin in the past, due to its missing stable release: it has been ready for quite some time now, but now it's official!
For all existing users: upgrade to the new stable release and see if there are features or bug fixes that help you out (or, hopefully not, any bugs you can report)! Recent additions include support for SSL, field collapsing, Solr 4.x and location-based searches.
(Also, check out the new documentation, if you haven't done so already!)

* By the way, is there any data or estimations out there on what percentage of users the Drupal.org usage statistics actually capture?

Image credit: Sergey Melkonov

Tags: search api solrplanet

When was the last time your website had a facelift or you audited your Drupal modules, site security, SEO, etc?

We believe website redesigns fundamentally fall into two categories: the right and the wrong.

The right way delivers true value to an organization and the wrong way just consumes time and money for window dressing—which does nothing for your bottom line. 

Recently a few of our teammates gathered our thoughts around Drupal website redesigns. As we talked through the different areas we coach our customers on, we decided to put them into one eBook.

"Preparing for a Drupal Website Redesign" is a collection of important suggestions your organization should consider before embarking on your next website design. Suggestions such as:

An essential feature of a dynamic site would be to let its users add some contents to it. Often this is done using HTML forms. Drupal offers a rich and relatively simple way to use API for building forms for its Developers. In Drupal parlance it is referred as Form API (or FAPI).

Google Plus One Linkedin Share Button Tweet Widget Facebook Like