Planet Drupal

Subscribe to feed Planet Drupal
Drupal.org - aggregated feeds in category Planet Drupal
Bijgewerkt: 3 uur 30 min geleden

Drupal core announcements: Drupal 7 core release on Wednesday, January 1 (or Thursday, January 2)

di, 2013/12/31 - 4:51am
Start:  2014-01-01 (All day) - 2014-01-02 (All day) America/New_York Sprint Organizers:  David_Rothstein

The monthly Drupal core bug fix release window is this Wednesday, and since it has been a while since the last one, I plan to release Drupal 7.25 on that date. However, in practice the release might not happen until Thursday, due to the holiday and to give people a bit more time to test the latest code. Per our release policy, this will be a bug fix release only (no security fixes).

The final patches for 7.25 have been committed and the code is frozen (excluding documentation fixes and fixes for any regressions that may be found in the next couple days). So, now is a wonderful time to update your development/staging servers to the latest 7.x code and help us catch any regressions in advance.

The relevant change records for Drupal 7.25 are listed below. This is not the full list of changes, rather only a list of notable API additions and data structure changes that might affect a number of other modules, so it's a good place to start looking for any problems:

You might also be interested in the tentative CHANGELOG.txt for Drupal 7.25 and the corresponding list of important issues that will be highlighted in the Drupal 7.25 release notes.

If you do find any regressions, please report them in the issue queue. Thanks!

Upcoming release windows after this week include:

  • Wednesday, January 15 (security release window)
  • Wednesday, February 5 (bug fix release window)

For more information on Drupal core release windows, see the documentation on release timing and security releases, and the discussion that led to this policy being implemented.

Categorieën:

Configuration Management Initiative: Upcoming CMI Meetings

di, 2013/12/31 - 2:33am

Contrary to popular belief, the Drupal 8 Configuration Management Initiative (CMI) is not done. In fact, there is still a fair amount of work remaining. To help get some momentum, we are going to start holding CMI IRC meetings in #drupal-cmi every other Monday at 20:00 UTC (3pm Eastern). Our next IRC meeting will be Monday, January 13 at 20:00 UTC. Additional meetings will be on January 27, February 10, 24, etc. All of the Drupal 8 initiative meetings, including the CMI meetings, are listed on the calendar on Drupal 8 Updates and How to Help.

Anyone who is interested in helping to get Drupal 8 closer to having a working configuration system is welcome to join the IRC meetings. That said, we have a lot of complex problems to solve. While it would certainly be helpful to check out the the issues listed under the tabs above (Focus Issues, Beta Blocker, Novice Issues, etc.) our most important issues at the moment are listed on the meta issue Making configuration synchronisation work.

Tags:
Categorieën:

Acquia: 2013 Greatest Hits – Gaelan Steele meets Dries

ma, 2013/12/30 - 10:55pm

One of my favorite Drupal moments in 2013 was meeting Gaelan Steele in person at DrupalCon Portland. This was eclipsed very quickly by being present when Gaelan and Dries met for the first time - and having my podcast microphone on! This was probably also eclipsed by Gaelan schooling Dries on how he learned to use Drupal ... see his answer below and in the podcast.

Categorieën:

Friendly Machine: Omega vs. Zen - Which Base Theme Should You Choose?

ma, 2013/12/30 - 6:23pm

If you’ve been reading my posts for a while, you’ll know that I’m a fan of the Omega base theme and have used it in many of my projects. As I’ve gotten more familiar with it, I’ve noticed it bears a striking resemblance to the latest release of Zen.

For those of you not familiar with Drupal base themes, Zen has long been the most popular. I thought I’d take a look at the two of these themes and see how they really match up and which one might be the better choice for a given project.

Big Changes to Omega

First things first - Omega 4 bears only a passing resemblance to Omega 3. It’s essentially a complete re-write (see my overview) and the changes may be jarring for those who’ve become familiar with Omega 3’s UI layout tools.

Those tools are long gone. As I noted above, what you have with Omega 4 is something strikingly similar to Zen in almost every way. Much of this has to do with both maintainers adhering to emerging best practices in front end development, but it's also due to choice of tools.

Feature Comparison

Below is a table that shows some of the features of both Zen and Omega.

Feature Omega Zen  HTML5 Yes Yes  Sass + Compass Yes Yes  Swappable layouts Yes Yes  Default grids Susy Zen Grids  Drush support Yes Yes  IE conditional classes Yes Yes  Mobile first Yes Yes  HTML5 shiv, Respond.js Yes Yes

Quite a bit of overlap wouldn’t you say? Having worked with both themes, I can tell you it’s pretty easy jumping back and forth between them. Conceptually, they are essentially the same, with only minor differences in implementation.

One thing that sticks out to me is that both are very flexible. You can create an Omega sub-theme using Zen Grids, for example. Likewise you can create a Zen sub-theme using Omega’s default grid system, Susy.

The SMACSS approach to modular CSS makes it a snap to move some of your boilerplate styles between themes. They’re both put together in a really smart way and offer big improvements over previous approaches to theme development.

And of course, both use Sass + Compass, which seems to be preferred over LESS among Drupal developers.

One Difference Between Zen and Omega

We see that the two of these base themes have a lot in common, but in what ways are they different? Well, one difference seems to stem from the choice of default grid system.

Omega 4 uses Susy, and from what I understand, it has frequent updates that may break backward compatibility. This means you’ll need to keep careful track of your Gem versions, particularly when working in a team, if you want your Sass to compile correctly. The maintainer of Omega has explained how to set things up in this comment.

I suppose it could be argued that what he’s describing is a best practice generally, but will most people go through all of that? My experience tells me no. It really seems like a potential trouble spot, but I’m not sure. Perhaps Omega 4 hasn’t been around long enough to hear of missing Gemfiles causing issues - maybe it won’t be a problem at all.

That said, the “ideal set up” is a point of difference. With Zen you can get started with less hassle. Does this mean Zen is better than Omega? I don’t think so. For some, this will fit right in with the way they are already working.

The Big Difference

The biggest difference between the two base themes is Omega’s inclusion of layouts. These are predefined, Panels-style layouts that can be used with the Context Omega module to apply layouts to specific pages, content types or whatever other condition you may require.

These layouts can also be used with Panels Everywhere. In fact, the Omega layouts will appear in Panels when you have both Omega and Panels installed. Keep in mind, however, you can’t use these with vanilla Panels - only with Panels Everywhere. This is because Omega 4 layouts are variations on page.tpl.php and therefore control the entire layout of the page rather than just the node.

Sebastian Siemsen, the co-maintainer of Omega, did a long screencast on how to use Omega 4, including strategies for use with Panels for those that are interested.

So Which Is Better?

Of course the answer here is, “it depends”. If you like building sites with Panels Everywhere, then Omega 4 might have the edge. If you don’t like the development set up of Omega 4, then Zen might be a better choice. Another thing in Zen's favor is far superior documentation.

However, I think the truth is that it hardly matters which of these two you choose. Personally, I use both and I think that’s rather a good thing. It allows me to easily switch between them depending on the requirements of a given project.

If you have any comments on this post, you may politely leave them below.

Categorieën:

TimOnWeb.com: Let's Drup Up The Week. Issue 13

ma, 2013/12/30 - 1:44pm

This is the 13th issue of the weekly Drupal news round-up and the last one in the year 2013. The last week was pretty silent and it was hard to find something interesting, but in the end I've managed to dig some Drupal gold for you. Today will be no dessert, because of the sad events happening in my country of origin.

Wish you all a Happy New Year! Be healthy and happy, the rest is not so important. Let's Drup Up The Week!

Read on about Let's Drup Up The Week. Issue 13
Categorieën:

Wunderkraut blog: Weldir, a Wunderkraut Flavoured theme for Ægir

ma, 2013/12/30 - 1:26pm

We have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.

Here at Wunderkraut Benelux, we love Ægir. We use to manage some aspects of our development, staging and production environments.

Since we often provide access, documentation, etc to our internal and external clients, we have created an Eldir sub-theme that adds a Wunderkraut flavour and some other tweaks which make the Ægir UI more friendly and tasty.

 

Weldir, as we've named the theme, builds on the Eldir theme and adds a few things we felt that were missing; buttoned pagers, a better footer position, some breathing room, and so on. Since we also document stuff in Ægir, we've added styling which can be used on links to create in-content buttons - call-to-actions if you will, to spruce up content and draw attention where needed. Simply add the button class to your link.

Weldir is available on GitHub. We hope it provides you with an alternative theme for this great tool.

Categorieën:

Janez Urevc: HHVM and Drupal (i.e. Drupal drinks some RedBull)

ma, 2013/12/30 - 12:27pm

I've been following HHVM (HipHop Virtual machine) for some time now. Project got a bit more of my attention about a year ago, after session at FOSDEM 2013 by Sara Golemon. PHP has been criticized for quite a lot of it's characteristics, performance definitely being one of those. HHVM seemed to be very promising about fixing it and that's why it got my attention in the first place. Immediately after last year's FOSDEM I tried it with Drupal, but my attempt unfortunately failed miserably. HHVM was simply not yet ready for that.

But first a bit of history...

HipHop was initially developed by Facebook (and they are still it's main contributor). Facebook was looking for something that would make their PHP code base perform faster while still retaining benefits that PHP brings (primarily ease of use for developers). Initially they created a compiler (HPHPc) that transformed a PHP script into a C++ program, which was then compiled into a binary. This approach showed dramatic increase in performance, but also had some problems. HPHPc did not fully support PHP language and was not a simple drop-in replacement for "standard" (Zend) PHP.

Facebook decided to deprecate HPHPc, start working on a bit different approach and HHVM was born. HHVM is a Just-in-time compiler (JIT) for PHP. It behaves very similar to standard interpreter when observed from the outside (which means it can be a drop-in replacement for it), but it works quite different internally. It will run a program as an interpreter at the beginning of execution, collect some statistics for optimization and eventually compile it to byte code on the fly. Compiled program will then run much faster than it's interpreted version. It is quite obvious that we get true performance gains with applications that run for a longer period of time (because of initial interpretation phase and on-the-fly compilation). A standard web (Drupal) application, which is deployed to production servers from time to time, is exactly what we're looking for.

Categorieën:

Cheppers blog: Global Sprint Weekend January 25 and 26 2014

zo, 2013/12/29 - 6:40pm

Global Sprint Weekend is a worldwide event you can participate in. Small local sprints in lots of locations, over the same time period: Saturday and Sunday January 25 and 26, 2014. These sprints will usually be 2-15 people in one location, together, working to make Drupal better.

You can make your own locations if no location is near you! Currently people have announced locations in Sevilla Spain; Berlin, Mannheim and Schwerin Germany; Ghent Belgium; Budapest Hungary (hosted at Cheppers and led by Gábor Hojtsy); Manchester UK; Vancouver, London (Ontario) and Montréal Canada; Oak Park, Chicago, Milwaukee, Boston, Minneapolis and Austin USA.

Categorieën:

BryceAdamFisher.com: Considerations for Multisite Drupal

za, 2013/12/28 - 5:40pm

At my day job, we've been using the Domain Access module with Drupal 6 for 5 years. Recently, we've decided it's time to rethink our approach to Drupal multisite. In this article, I'll share some of ideal use cases and pitfalls for the Domain module and some alternatives for you to consider.

Categorieën:

Tyler Frankenstein: Drupal - Get a View's Export Code Programmatically from CTools

vr, 2013/12/27 - 6:17pm

With Drupal and Views, we are able to configure a View's settings and import/export them across Drupal sites. This allows us to create backup copies of our View's settings and/or move a View between Drupal sites with relative ease.

Typically this is a manual process by using the Views UI to copy the "export" code string from one site:

http://dev.example.com/admin/structure/views/view/frontpage/export

..and then paste the string into the "import" form on another site:

Categorieën:

Drupalize.Me: Careful With That Debug Syntax

vr, 2013/12/27 - 2:53pm

A funny thing happened last week. On Wednesday, we performed our weekly code deployment and released a handful of new features/bug fixes to the site. And then, about an hour later, someone on the team found this:

Notice the extra "asdf fdsa" in there? It's okay if you didn't, because neither did we. How did this happen? Don't you guys have a review process? I would have never let this happen on my project.

Related Topics: debugging, Development
Categorieën:

Chris Hertzog: Introducing Pinger and PingCheck.in

vr, 2013/12/27 - 12:59pm

As the owner of a small development shop, I deal one on one with all of my clients. Most of the time these are happy/pleasant exchanges. But then on occasion, (usually when I'm on vacation, in the middle of an 8 hour meeting, or somewhere that my access to the internet is severely hindered), I get an email/text/call from a client whose site is down. No matter which form of communication, these exchanges are always written with caps lock.

Any website developer can give you a laundry list of why a site may be down or is not responding. Traffic spikes, server malfunctions, power outages, hacking attempts, etc. But most website owners don't care why the site isn't responding. They just want it fixed. An hour ago.

So in an effort to minimize these unpleasant events, I looked for some website monitoring tools. There are many out there with lots of options. But none really fit my use case. Plus, none were built in Drupal :).

I have a client dashboard system where my clients manage their account. They can view site analytics, submit support tickets, pay invoices, etc. I wanted to be able to track website downtime and have it available to them. Not only would it be a plus for them, but it could help me identify if issues were isolated to their site, or affecting our entire infrastructure.

Step In Pinger

Pinger is a simple module that leverages the Drupal Queue API, Cron, and drupal_http_request. In a nutshell, you tell pinger to monitor a handful of urls, and it will check each url when cron runs. Over and over again.

Elysia Cron is recommended to help manage cron settings, so you can have pinger_cron() running more frequently than other modules (plus it helps run the Queue).

Pinger saves each response as an entity (so the entity API can be leveraged). It records the http status code, the duration of the request, and the timestamp. Additionally, the information is exposed to views, so you can generate reports of outages, slow responses, etc.

PingCheck.in

I decided to launch PingCheck.in as a hosted version of Pinger. The service will check your website (perform a HTTP GET request) every 5 or 10 minutes (depending on subscription), and send a message to up to 5 different email addresses when it received something other than a 200 OK status.

We have different size plans for different needs. The personal website plan is free. Forever. Additionally, we are offering a 6 month free trial of any paid plan with coupon code "drupal6".

Please test out and review the module yourselves, or signup for the service. Comments and feedback on both are greatly appreciated.

CategoryDrupal PlanetComments Add new comment Your name Comment* About text formatsPlain text
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <h4> <h5> <h6>
Supported tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <h4> <h5> <h6> Leave this field blank
Categorieën:

Paul Rowell: The darker side of Drupal; Field collections and revisioning/moderation

vr, 2013/12/27 - 2:16am

Field collections are awesome, we all know that. When it comes to revisioning it starts to turn sour, go deeper and include workflow moderation and it really turns dark.

Categorieën:

Randy Fay: Remote Command-Line debugging with PHPStorm for PHP/Drupal (including drush)

do, 2013/12/26 - 11:05pm
debuggingPlanet DrupalIntroduction

XDebug with PHPStorm can do step-debugging on remote sessions started from the command line on a remote machine. You just have to set up a couple of environment variables, map the remote code to the local code that PHPStorm has at its disposal, and tunnel the xdebug connection to your workstation.

Note: If you just want to debug a PHP script (or drush command) on the local machine, that's much easier. Just enter PHPStorm's Run/Debug configuration and create a new "PHP Script" configuration.

Overview of Setup
  • We'll create a PHPStorm project that contains all the code we want to debug on the remote machine. This can be done via source control with matching code, by mounting the remote directory to your local machine, or any way you want.
  • Create a mapping from server side directories to PHPStorm-side code (A "Server" configuration in PHPStorm)
  • Use environment variables on the remote machine to tell xdebug what to do with the debugging session
  • Tunnel the Xdebug TCP connection if necessary.
  • Make PHPStorm listen for a connection
  • Create a breakpoint somewhere early in the execution path
  • Run the command-line tool on the remote server.
Step-by-Step
  1. On the remote server install xdebug and set xdebug.remote_enable=1 In your xdebug.ini (or php.ini). For complete details see Remote Drupal/PHP Debugging with Xdebug and PHPStorm.
  2. Open your project/directory in PHPStorm; it must have exactly the same code as is deployed on the remote server. (You can optionally mount the remote source locally and open it in PHPStorm using sshfs or any other technique you want, see notes below.)
  3. If you're debugging drush, you probably need to copy it into your project (you don't have to add it to source control). PHPStorm is quite insistent that executing code must be found in the project.
  4. Create a debug configuration and a "Server" configuration in your project. The Server configuration is used to map code locations from the server to your PHPStorm code. Run->Edit Configurations, Create PHP Web App, Create a server, give the server a name. Click "Use path mappings" and configure the mappings from your project to the remote server's code. (See )
  5. If your remote server cannot directly create a tcp connection to your workstation, you'll have to tunnel port 9000 to your local machine. ssh -R 9000:localhost:9000 your_account@remote_server.example.com - For more details and debugging, see
  6. Click the "Listen for PHP Debug Connections" button in PHPStorm. I call this the "unconditional listen" button, because it makes PHPStorm listen on port 9000 and accept any incoming connection, no matter what the IDE key. See Remote Drupal/PHP Debugging with Xdebug and PHPStorm
  7. In PHPStorm, set a breakpoint somewhere that your PHP script is guaranteed to hit early in its execution. For example, if you're debugging most drush actions, you could put a breakpoint on the first line of drupal_bootstrap() in includes/bootstrap.inc.
  8. If the computer is not reachable from the server, you will need to tunnel the connection from the server to your workstation. ssh -R 9000:localhost:9000 some_user_account@www.example.com For more details and debugging, Remote Drupal/PHP Debugging with Xdebug and PHPStorm
  9. In your command-line shell session on the remote server set the environment variable XDEBUG_CONFIG. For example, export XDEBUG_CONFIG="idekey=PHPSTORM remote_host=172.16.1.1 remote_port=9000" (Note that port 9000 is the default both for xdebug and for PHPStorm.) If you're tunneling the connection then remote_host must be 127.0.0.1. If you're not tunneling, it must be the reachable IP address of the machine where PHPStorm is listening.
  10. export PHP_IDE_CONFIG="serverName=yourservername" - the serverName is the name of the "server" you configured in PHPStorm above, which does the mapping of remote to local paths.
  11. On the command line run the command you want to run. For example drush cc all or php /root/drush/drush.php status
  12. If all goes well you'll stop at the breakpoint. You can step-debug to your heart's content and see variables, etc.
Drush+Drupal-Specific Hints
  • I've had the best luck actually copying drush into my codebase so that its mappings and Drupal's mappings can be in the same directory.
  • Once you have the environment variables set you can either use the "drush" command (which must be in your path) or use "php /path/to/drush/drush.php" with your drush options. Make sure you're using the drush that's mapped as a part of your project.
Notes and resources
  • We set the xdebug.remote_host in the XDEBUG_CONFIG environment variable; it could also have been configured in the xdebug.ini as xdebug.remote_host=myworkstation.example.com. (Note that the default is "localhost", so if you're tunneling the connection you don't actually have to set it.)
  • Full details about remote debugging on xdebug.org
  • Debugging: Make sure that only PHPStorm is listening on port 9000. If something else (most notoriously php-fpm) is listening there, you'll have to sort it out. PHPStorm is happy to listen on another port, see the preferences, and you'll need to change your environment variable to something like export XDEBUG_CONFIG="idekey=PHPSTORM remote_host=172.16.1.1 remote_port=9999
  • You may want to use sshfs or some other technique to mount the remote code to your local machine. sshfs your_account@server.example.com:~/drush /tmp/drush would mount the contents of drush in the remote home directory to /tmp/drush (which must already exist) on your local machine. It must be writeable for PHPStorm to work with it as a project, so you'll have to work that out.
  • The article that taught me everything I know about this is Command-line xdebug on a remote server. Thanks!
Categorieën:

Mediacurrent: Webinar: Code-per-Node

do, 2013/12/26 - 10:44pm

Drupal has many well documented best practices, many of which we've covered here previously. From using Features to export all site configuration, to applying updates on a copy of the site instead of production, to using a modern responsive base theme, there is usually a tried & trusted process for most scenarios that can help keep sites stable, and editorial teams & visitors happy.

Categorieën:

Greater Los Angeles Drupal (GLAD): Greater Los Angeles Drupal's 2013 Year in Review: Part 2

do, 2013/12/26 - 10:06pm

2013 has been a big year and there's so much to share that this is Part 2 in our ongoing series of highlights. (Did you miss Part 1? Read that first.)

This post is a long one, so grab your favorite beverage (or a shawarma) and join us when you're ready.

Highlights from 2013

Drupal Job Fair & Employers Summit
In January, 2013, Droplabs held another Drupal job fair but this time also had its first Drupal Employers Summit. All the companies in the area who had ever hosted a Drupal meetup or other Drupal-related event, had sponsored any of the previous job fairs, or simply asked to attend, were invited.

Half a dozen companies were represented, including CivicActions, Exaltation of Larks, Filter Digital, Princess Cruises, Sensis Agency and Stauffer and they talked into the night about hiring strategies and challenges, the desired skills that candidates should have for various roles, and ideas on how to grow Drupal talent.

Relaunched as Greater Los Angeles Drupal
At our open governance meeting in April, 2013, we voted to rename our group from "Downtown Los Angeles Drupal" to "Greater Los Angeles Drupal" (or just "GLAD", for short). This made sense since our organizers now endeavor to serve the 5 counties in the Greater Los Angeles Area and not only the Downtown Los Angeles region, but the name change led to some debate and vexation from members of a nearby group.

Governance policy enacted after a year of work
GLAD is founded on the values of teamwork, transparency, accountability, and the sharing of assets and resources. Work began on a formal governance policy just 6 days after the group was approved on Drupal Groups, and grew to include definitions of roles, our own code of conduct and a procedure for how to manage and resolve conflicts.

As far as I know, GLAD is the first Drupal user group to draft and implement a governance policy like this that's separate from the Drupal Code of Conduct. Hopefully, this governance policy can serve as an example and help other groups decide whether if a similar policy would be a good fit for them.

GLADCamp 2013 postponed :(
As with the change of name to Greater Los Angeles Drupal, not all of our highlights from 2013 went smoothly. Originally planned as a 3-day megaconference for all things Drupal, our 2013 conference was supposed to be a successor to Drupal Design Camp LA but it fell through when contracts with the venue didn't materialize. This was terribly disappointing, but provided bittersweet lessons for our organizing team.

Module Develoment Boot Camp at Droplabs
In the summer, Droplabs started its free, community-led Module Development Boot Camp. With 12 weeks of drills, exercises and exams, all aimed at training PHP and Drupal programmers the skills they need to write Drupal modules, this is the first event of its kind as far as I know.

Droplabs named world’s “Top Drupal location”
With 62 events dedicated to Drupal, Droplabs was recognized by Drupical as the world's "top Drupal location" between the months of July, 2012, and July, 2013.

Drupal Watchdog magazines for everyone
Are you an an organizer of an open source group or event in Southern California? Would you like a box of Drupal Watchdog magazines to give to your members and attendees? Droplabs announced that it had a very large surplus of Watchdog magazines and that they're just giving them away. They're already making their way as far as San Diego for the upcoming SANDcamp conference.

OneDayCareer.org wins at Stanford
What started out as a barn raising to help attendees of the Module Development Boot Camp get hands-on experience with custom module development, Git, Features and team-based collaboration, the OneDayCareer.org team went on to win at the Technology Entrepreneurship Demo Day at Stanford University, beating out 20,000 other students!

Again, there is simply too much to cover in one post. See you next time in the last part of our series!

Tags: Planet DrupalYear in Review
Categorieën:

Worchestra: FaceShift - A reporting tool on top of Drupal to fetch any Facebook page's posts' insights

do, 2013/12/26 - 7:07pm

Any Facebook page admin will care to see how their posts are doing, what engagement is it driving and how much did it score from likes, comments, and shares.

If you have been using Facebook Insights heavily you would know that there are is a huge limit when you export Post Level Data (Maximum of 500), so if you use your page heavily you would have more than 500 posts a month.

FaceShift is a tool extract post level report (Post title, link, number of likes, comments, and shares) for each post for a selected month, for any given Facebook page whether it was yours or for a competitor, you simply select the date and the facebook page, and the report will be emailed to you (most likely to your spam folder) in an Excel downlable link.

Give it a try and leave me your feedback

http://faceshift.worchestra.com

Categorieën:

Worchestra: Drupal to Drupal - Content Migration

do, 2013/12/26 - 4:19pm

At some point you will feel the need for a new cleaner website, so you build your new Drupal site with cleaner content types, and you want to migrate your old content to the new website.
Migrate module is the module for that, however, by itself you will not be able to do your migration, you have to build your migration classes on top of that module, so below are the migration steps.

We start with creating a new module that will depend on Migrate module.
Create worchestra_legacy.info

name = "Worchestra Legacy" description = "" core = "7.x" package = "Worchestra"   files[] = migrate/base.inc files[] = migrate/articles.inc
Categorieën:

Drupalize.Me: Contributing Time to Drupal 8

do, 2013/12/26 - 2:39pm

Drupal 8 is coming in 2014. There is a lot of work to do and a lot to learn. We've decided to dedicate a minimum of five hours per week towards Drupal 8 for each person on the Drupalize.Me team. We are now a hefty group of eight people, and everyone will be diving in for a total of 40 hours per week dedicated to Drupal 8. (At least until Drupal 8 launches, and hopefully even beyond that.) Everyone is picking their own projects and ways to get involved. We just started dedicating this time in December, and folks have been spending time sorting out where things are and where to jump in.

Related Topics: community, Drupal 8
Categorieën:

Yuriy Gerasimov: Custom user name from profile

do, 2013/12/26 - 9:54am

Current project I am working on has user profiles using profile2 module. So it is pretty common task to replace all links/references on the site with user's proper name from Profile instead of his drupal username.

This is really easy to achieve using hook_username_alter()

<?php /** * Implements hook_username_alter(). */ function mymodule_username_alter(&$name, $account) { $contact_profile = profile2_load_by_user($account, MYMODULE_PROFILE_CONTACT_TYPE); if (isset($contact_profile->field_name[LANGUAGE_NONE][0]['value'])) { $name = $contact_profile->field_name[LANGUAGE_NONE][0]['value']; } } ?>

And if you will want somewhere in the code display user's name do this using function format_username().

Tags: drupal planet
Categorieën:

Pagina's