Giter Site home page Giter Site logo

drupal-boilerplate's Introduction

#Drupal Boilerplate#

Drupal boilerplate is not a module. Instead it just serves as a directory structure for starting a new drupal site. The idea behind Drupal boilerplate came from working on so many different sites which each follow their own development practice, directory structure, deployment guidelines, etc...

Drupal boilerplate tries to simplify starting a new site by having the most common directory structures and files already included and set up.

##Getting started## You can start by downloading this project. Once you download it you will find that every folder contains a readme.md file. This readme.md file has been extensively documented to explain what belongs in that specific directory.

Here's a breakdown for what each directory/file is used for. If you want to know more please read the readme inside the specific directory.

  • docroot
  • Where your drupal root should start.
  • drush
  • Contains project specific drush commands, aliases, and configurations.
  • results
  • This directory is just used to export test results to. A good example of this is when running drush test-run with the --xml option. You can export the xml to this directory for parsing by external tools.
  • scripts
  • A directory for project-specific scripts.
  • test
  • A directory for external tests. This is great for non drupal specific tests such as selenium, qunit, casperjs.
  • .gitignore
  • Contains the a list of the most common excluded files.

Built by Robots™

drupal-boilerplate's People

Contributors

blakehall avatar brockboland avatar damienmckenna avatar davereid avatar eojthebrave avatar ericduran avatar juampynr avatar justafish avatar karschsp avatar mordonez avatar q0rban avatar sirkitree avatar tormi avatar vadbars avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

drupal-boilerplate's Issues

Document intent of Patches directory to avoid confusion

This may be what I'm used to, but when all the patches are provided in the patches directory, when I go to actually update modules, themes, or core, I find that it takes me longer to figure out if a patch was applied or not.

What i'm used to:

  • Place patch in the root directory of the project being patched (for core, patches go in /docroot, for modules, patches go in the module directory i.e. /docroot/sites/all/modules/contrib/mymodule).
  • When I do a drush dl mymodule to download the new update, I can clearly see in the /docroot/sites/all/modules/contrib/mymodule directory that a patch file has gone missing and that I likely need to re-apply it.

I propose getting rid of the /patches directory.

Moving casperjs functionality to a drupal contrib module

Hi! Are there any plans to move casperjs to a drupal module?

Meanwhile I have forked this current code on my github adapting it to a simple drupal module.
(https://github.com/jorgetutor/casperjs.git)

Minor changes:

  • Moving the includes option before the --pre and --post parameters:
    This way I can override settings like casper.boilerUser on an include file without touching the current files.
  • Adding the minimal drupal module files.

I volunteer to assist in this integration!

Drush policy "prod"

Drush policy is doing a preg_match() on /prod/ but we don't have "prod" in our examples aliases. Should we change that to match "live"? Or am I totally misunderstanding the command?

cc: @juampy72

Devify is awesome

It seems like something that should be hosted outside of drupal-boilerplate and have it's own project. But it should keep being including with drupal-boilerplate. I just think development should happen separate.

I wrote a sandbox project that does the same thing a long time ago -> http://drupal.org/sandbox/ericduran/1154642

We should combine it and so other people could start using it. The advantage my project has is it allows site specific or user specific settings.

It's also touches a lot less stuff, so it doesn't sanitize your DB by default :)

Either way I love the addition. We should do more with it.

cc @juampy72

Fatal errors with drush build command when display suite module is enabled

When running the drush build command with a site with the Display Suite module enabled, you get the following error:

drush: You need to set a name for your layout. Type "drush help ds-build" for help.
Drush command terminated abnormally due to an unrecoverable error.

This is due to the fact that the Display Suite drush integration's ds.drush.inc file has a function named drush_ds_build:

/**
 * Create a basic template and configuration file for a new Display Suite layout.
 */
function drush_ds_build($name = NULL) {
  // Determine the layout name.
  if (!isset($name)) {
    $name = drush_get_option('name');
  }
  if (!$name) {
    drush_die(dt('You need to set a name for your layout. Type "drush help ds-build" for help.'));
  }

The drush --debug output, with an added backtrace in drush_ds_build():

Returned from hook _drush_build [12.22 sec, 44.43 MB]                                                                                                                                                                           [debug]
Calling hook drush_ds_build [12.22 sec, 44.44 MB]                                                                                                                                                                               [debug]
#0  drush_ds_build()
#1  call_user_func_array(drush_ds_build, Array ()) called at [/home/davereid/Sync/opt/drush/includes/command.inc:362]
#2  _drush_invoke_hooks(Array ([description] => Runs database updates, reverts features and clears caches.,[callback] => drush_command,[bootstrap] => 5,[command] => build,[command-hook] => build,[invoke hooks] => 1,[callback arguments] => Array (),[commandfile] => build,[path] => /home/davereid/Sync/lullabot/projects/Publisher7_bravo/drush/commands,[engines] => Array (),[primary function] => _drush_build,[sections] => Array ([examples] => Examples,[arguments] => Arguments,[options] => Options),[arguments] => Array (),[required-arguments] => ,[options] => Array (),[sub-options] => Array (),[allow-additional-options] => ,[examples] => Array (),[aliases] => Array (),[core] => Array (),[scope] => site,[drupal dependencies] => Array (),[drush dependencies] => Array (),[handle-remote-commands] => ,[strict-option-handling] => ,[bootstrap_errors] => Array (),[topics] => Array (),[hidden] => ,[category] => build,[argument-description] => Array ()), Array ()) called at [/home/davereid/Sync/opt/drush/includes/command.inc:214]
#3  drush_command()
#4  call_user_func_array(drush_command, Array ()) called at [/home/davereid/Sync/opt/drush/includes/command.inc:182]
#5  drush_dispatch(Array ([description] => Runs database updates, reverts features and clears caches.,[callback] => drush_command,[bootstrap] => 5,[command] => build,[command-hook] => build,[invoke hooks] => 1,[callback arguments] => Array (),[commandfile] => build,[path] => /home/davereid/Sync/lullabot/projects/Publisher7_bravo/drush/commands,[engines] => Array (),[primary function] => _drush_build,[sections] => Array ([examples] => Examples,[arguments] => Arguments,[options] => Options),[arguments] => Array (),[required-arguments] => ,[options] => Array (),[sub-options] => Array (),[allow-additional-options] => ,[examples] => Array (),[aliases] => Array (),[core] => Array (),[scope] => site,[drupal dependencies] => Array (),[drush dependencies] => Array (),[handle-remote-commands] => ,[strict-option-handling] => ,[bootstrap_errors] => Array (),[topics] => Array (),[hidden] => ,[category] => build,[argument-description] => Array ())) called at [/home/davereid/Sync/opt/drush/drush.php:92]
#6  _drush_bootstrap_and_dispatch() called at [/home/davereid/Sync/opt/drush/drush.php:61]
#7  drush_main() called at [/home/davereid/Sync/opt/drush/drush.php:16]

drushrc.php modification to load from Git repo root doesn't work with Drush aliases

I have a local system alias that points to a drupal-boilerplate site's docroot. This site also has it's own drush configuration file located at /var/www/mysite.com/drush/drushrc.php.

// ~/drush/local.drush.aliases.drushrc.php
$aliases['mysite'] = array(
  'root' => '/var/www/mysite.com/docroot',
  'uri' => 'http://mysite.com/',
);

If I were to run the drush @local.mysite status config command from my home directory (and not anything from inside the mysite.com directory), this is what I get for my drush output:

drush @local.lullabot status config
 PHP configuration     :  /etc/php5/cli/php.ini                  
 Drush configuration   :  /home/davereid/.drush/drushrc.php 

This is the bug. It should be including the file from /var/www/mysite.com/drush/drushrc.php. This is the expected output:

drush @local.lullabot status config
 PHP configuration     :  /etc/php5/cli/php.ini                                                
 Drush configuration   :  /var/www/mysite.com/drush/drushrc.php 
                          /home/davereid/.drush/drushrc.php

Replace devify command with Drush Rebuild

It's close to devify except it abstracts things. Currently with devify you could only have one group of settings.

With Drush Environments you can only have multiple environments which each have different settings.

Or we could just could have them both available.

Thoughts?

cc @juampy72 Also it'll be nice to merge and make it a full project somewhere since they're both pretty useful.

Install profile

Typically on our projects we've been coming up with an install profile using profiler. It's pretty great for resetting your environment quickly and easily (sometimes combined with a quick bash script to run drush commands).

Opening this up for discussion to see if others think it would be good to have in place for the boilerplate.

Deployment process using Drupal VM

I need to clone locally a project based on your drupal-boilerplate and build it based on a makefile located in /docroot directory.

Could you assist me on how to do it using Vagrant and Drupal VM?

fix the history

There was a bad commit that push a drupal site to the actual docroot directory. I reverted the commit nut its still in the history.

We should completely remove that from the history.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.