Attached an example file that demonstrates the same. In the example module the ajax call is using drupal menu callback triggered using event in jquery.
Drush is probably one of the most useful tools a Drupal Developer has in his/her arsenal. Drush is a command line shell for Drupal and it can save you a lot of time when isntalling or updating Drupal instancenses with many modules. I was surprized to find out that there are lots of developers who don't yet use Drush full power and I can tell them one thing - you are missing big time, guys. In my post I will try to cover a few basic topics and, hopefully, will help you get started with Drush.Table of contents
- Drush out-of-box commands
- Drush contrib commands
- Drush Aliases
- Improve your workflow with drush
Now, let's dig in...Drush out-of-box commands
You can find all these commands here. But I will cover only a part of them, which I’ve used at least once and which can be useful to you as well.
Commands which you MUST know about:
- cc - clear cache. Drupal core provides a round of cache types: default, bootstrap, field, menu, token etc. I hope you understand the purpose :) Because on large site calling drush cc all - is not a good way to achieve flushing agregated css or make new menu item appear. Use drush cc css+js.
- dl - downloads given contrib module and put it into sites/all/modules/contrib by default. You can specify release version by adding -7.x-1.x ( drush dl entity-7.x-2.12 If you start to contribute (I hope so) you will need module repo instead of just module’s file, so you can change download handler with “--package-handler=git_drupalorg”. Then drush dl --package-handler=git_drupalorg draggableviews will make git clone of this project to your contrib directory (You can create own short command for it drush dlgit PROJECT_NAME for example).
- uli - Get onetime login link for given user name or uid or uid=1 by default. Example drush uli m1r1k will try to find user with username 'm1r1k' and build url with onetime link - http://default/user/reset/1/1385380689/tqunn-cZ4YcSTke9kUWRCin3eiqiQNv12...
- upwd - Update given user's password
- sql-sync - lots of ways to make and restores mysql dump (details below). I think it is the fastest way to import production DB into your local one. Example: drush sql-sync @my_project.prod --create-db will make a dump on production server side, then rsync it to you machine, then drop you current db (--create-db key does it, because db merging usually brings lots of problems...) and run sql import. With second param you can even specify target drupal installation - drush sql-sync @my_project.prod @my_project.stage --create-db
- rsync - shortcut of default linux rsync command (details below). Example drush rsync @my_project.prod:%files sites/default/files will rsync whole sites/default/files directory from production server to your local.
- en, dis, pml, pm-uninstall - I guess everyone knows these commands, they don’t have interesting options.
- make - build sites from make file without bash coding.
- updb - invoke update.php from command line. This method doesn’t required authentication and has less steps.
- vget, vset - work with variables also through the drush, becase you don’t need to serialize or unserialize it, like with database.
- image-flush [image-style-name] - Flushes all generated presets.
- eval - Invokes string with php code after drupal’s fully bootsraped, like from you .module file, but without creating new function and poluting your code. Have you ever tried to get dump of core function from core? To full field definition foe example? Or get phpinfo's grepped value? Now you can run drush eval "var_dump(user_load(1));" on production site and got user object without devel enabled and even from your local machine (using drush aliases).
I strongly believe that we MUST replace every same UI operation with these Drush commands in our workflow!Drush contrib comands
Every big contrib module has its own Drush commands, which help invoke all the common tasks that are using Drush. All these commands you can find in the PROJECT_NAME.drush.inc file. Modules implement hook_drush_command(). Here are some examples of useful drush commands:
- devel-reinstall (dre) - Disables, Uninstalls, and Installs a list of projects in one command.
- fn-hook - gets the list of implementation of given hook - drush fn-hook menu_alter.
- Apache Solr
- solr-index, solr-mark-all, sorl-delete-index - much more faster and easier than the UI alternative.
- migrate-import - performs the import task ( I will prepare a presentation about Migrate later).
- Registry Rebuild
- rr - Rebuild Registry of drupal bootstrap process.
- Metatag (including this patch)
- metatag-import-mtq - migrates from Metatags Quick module to Metatag.
Every development process includes multiple Drupal environments, small list of them: local, stage and prodaction server. Remember your working flow (except coding).
Here's an example of my workflow before I met Drush aliases:
- Get recent dump of DB and restore it to your local db (I had some bash aliases per project, sometimes I was using MySQL Client App and ssh connection);
- Sometimes you want to grab recent files from prod/stage (pure rsync with all ssh credentials);
- Code (unfortunately Drush can’t help here..) and push to origin repo;
- Connect to stage server;
- Make git pull;
- Then lots of different drush actions: clear cache, features, enable/disable/reinstall modules, reindex, whatever;
- Run tests
- If everything went fine on stage we repeat 4-7 steps for Prod deployment;
I think we’re making too much extra steps and lost too much time to routine tasks. Drush can help you here via Drush aliases. Here is an example:
<?php // FILE: ./sites/all/drush/project_name.aliases.drushrc.php // Site propeople, environment local $aliases['local'] = array( 'uri' => 'local.site.com', 'root' => '/path/to/drupal/root', 'databases' => array ( 'default' => array ( 'default' => array ( 'driver' => 'mysql', 'database' => database, 'username' => 'root', 'password' => password, 'host' => 'host', 'prefix' => '', ), ), ), ); // Site propeople, environment prod $aliases['prod'] = array( 'uri' => 'prod.site.com', 'root' => '/prod-path/to/drupal/root', 'databases' => array ( 'default' => array ( 'default' => array ( 'driver' => 'mysql', 'database' => database, 'username' => 'root', 'password' => password, 'host' => 'host', 'prefix' => '', ), ), ), 'remote-host' => '22.214.171.124', 'remote-user' => 'root', 'ssh-options' => ' -i /path/to/key/file', 'path-aliases' => array( '%files' => 'sites/default/files', ), );
$aliases['stage'] = array( 'uri' => 'stage.site.com', 'root' => '/stage-path/to/drupal/root', 'databases' => array ( 'default' => array ( 'default' => array ( 'driver' => 'mysql', 'database' => database, 'username' => 'root', 'password' => password, 'host' => 'host', 'prefix' => '', ), ), ), 'remote-host' => '321.321.321.321', 'remote-user' => 'root', 'ssh-options' => ' -i /path/to/key/file', 'path-aliases' => array( '%files' => 'sites/default/files', ), );
Now my local drush knows everything about stage and prod environments and allows me use it localy in context of any other server. For example:
- drush @project_name.prod cc all - Clear cache on prodaction server from my local
- drush @project_name.stage uli - gives me link to login as admin on stage server
- drush sql-sync @project_name.prod @project_name.stage --create-db - Truncate my local db, make dump of prod db, download it and restore it to my local db
- drush rsync @project_name.prod:sites/all/files @project_name.stage:sites/all/files - rsync al files from prod to stage server
- drush @project_name.prod ssh - connect to Prod server via ssh
The fastest way to get aliase definition is run such command in drupal directory context - drush site-alias @self --with-db --show-passwords and add remote host information for external environmentsImprove your workflow with Drush
Try using Drush wherever it’s possible and you will save your time!
Also don’t forget that Drush is command line tool, it doesn’t need any UI, it doesn’t need any page on your site, it isn’t afraid of php memory or time limits but it still uses Drupal bootstrap initialization. It brings lots of benefits for you! Have you ever made kind of scrub script for mysql to replace something in every node? Have you ever wanted to delete ALL node of particular tabs? Have you ever wated to create for example child nodes for particucal nodes with some conditions? Or whatever? drush brings power of linux biult-in batch to you and your PHP scripts!
Try it out!Language English Tags: DrupalCheck this option to include this post in Planet Drupal aggregator: planet
The 8th issue of the weekly Drupal news roundup is out! In the issue: new versions of Drupal 6, 7 and 8, performance tips, recruiting tips, drupal snippets, tutorials and award winning music video for the dessert. Enjoy and let's drup up the week!Read on about Let's Drup Up The Week. Issue 8
Nearly 50 organizations around the planet held free or reduced cost introductory Drupal classes on November 15. Blink alone registered nearly 100 people for its class in Manhattan.
Webform Scheduler is a cool module that allows you to schedule the opening and closing of a given webform. It works similarly to the Scheduler module except it does not publish/unpublish the node but simply opens/closes the webform on the node.
I have come across this module only recently due to a request that was made for webforms to be automatically closed at a specified date. Needless to say, this module worked like a charm for me so I decided to show you.
To get it going real quick, install like usual. With Drush if you go like drush dl webform_scheduler and drush en webform_scheduler -y, you are good to go. Make sure you have the Webform module installed though as it depends on it (drush dl webform && drush en webform -y will take care of that).
To use the webform scheduling functionality, edit the form settings of the webform you want (found at node/[node-id]/webform/configure) and below the Submission Access group you’ll find a new one called Scheduler:
There you can specify at what date the form should be open and at what date it should be closed. And you can rest assured that if you decide to manually close the form, this will take precedence over any scheduling. And you can also choose what happens when the form does get closed due to the scheduling: deny access to the whole page or just the webform itself or even show the webform but hide its components. Now this is some nice features to have.
And you have to admit the module is pretty powerful if you are dealing with a big website that needs to run many forms at the same time with various degree of overlap between their open times.
There is one thing however I needed and the module does not provide. I dread the default Webform drupal_set_message()-like message that appears at the top of the page when you are on a closed webform node. What I needed was a similar message appearing in the same place where the actual form was when it was open. So with some custom code I got rid of the top message (thaank god) and altered the node view to display my message instead of the webform when the latter is closed. Can you think of a better alternative? Drop a line in the comments if you can. Cheers!
Hope this helps.In Cool Modules | Drupal
Drupal 8 Alpha 6 is out and it has a migrate module in there! It even has a few complete migrations: variables to the configuration files owned by system module. Since the last report the configuration of process has changed significantly, this is now documented in the handbook. We have two patches in the core queue, one potpourri of small fixes and one to split migrate into migrate and migrate_drupal, the latter holding the Drupal 6->Drupal 8 and Drupal 7->Drupal 8 migration. I have a third almost ready, this will be our first config entity migration, namely filter formats. This is actually working but the test is currently not doing much and the documentation is lacking -- once these easy problems are fixed, I will submit this as well. There's quite a lot of documentation to be written because this patch will introduce most generic process plugins we planned to write. A lot of code has been written for a fourth, this will be all the variables to configuration files. There's rapid progress, Mike Ryan now participates on a daily basis which means a lot of domain knowledge has been added to the team. marvil07 is working on porting the CCK fields code from migrate_d2d -- yes, the battle plan is that you will be able to migrate CCK fielded nodes to Drupal 8 straight. bdone and Mike is working on expanding the test coverage on two big classes which were straight ported from Drupal 7. YesCT is fixing our doxygen (I worked on this as well because the terminology was very confusing, hopefully now it's less so). My next task is to go over the existing hook_update_6xxx functions and see whether there's special logic that won't be covered by simple entity-to-entity migrations and create issues for them. fastangel have written the bulk of the fourth patch, I fully expect he will pick a lot of these issues, with the rest of the team piling on them once their work is done. With a little luck and perseverance the Drupal 6 -> Drupal 8 migration will be done by the Drupal birthday (January 15).
In the longer term, we will need to do Drupal 7 to Drupal 8 and I will need extra helping hands with multilingual issues. Ryan Weal already voluntereed to help, but I am sure we can use a few more so if you know i18n+migrate both, please don't hesitate to contact me.
Integrating XDebug into your IDE opens up a world of powerful debugging fu, but there's more to XDebug than that. There is an API you can leverage for alternate ways of peering into what's going on during that page load.
In this post I'll demonstrate some basic function tracing and related configurations.