I have tried several articles to disable the page and template cache in Drupal 8. I am not using drush and find it very annoying I have to manually clear the cache after every change.
sites/default/default.services.yaml
List item
debug: true
cache: false
auto_reload: true
create sites/settings.php & sites/settings.local.php
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$settings['cache']['bins']['page'] = 'cache.backend.null';
in development.services.yml add the following
1. twig.config:
debug: true
auto_reload: true
cache: false
Rebuild the cache
http://yoursite/core/rebuild.php or drush cr
Disable cache in configuration -> performance
Be sure to disable dev tools cache
If I make an adjustment to page.html.twig nothing happens til I clear the cache, any other ideas would be great. This would be the latest version of Drupal 8
Good day!
Try to add in you yml file:
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
Hope it will help you!
With all the steps above I forgot to do one thing
Move the settings.local.php inside sites/default
Uncomment the following in settings.php
if (file_exists(DIR . '/settings.local.php')) {
include DIR . '/settings.local.php';
}
You can install the Mix module to disable caches without editing settings*.php and *services.yml files. Just go to /admin/config/mix page and use the "Enable development mode" checkbox to switch between Dev/Prod modes. Here is a screenshot about Dev mode vs. Prod mode
Related
I moved from using Docksal to Acquia ADS (Lando) which automatically upgraded my Drush from 8 to 9. My local site works fine but I can't get Drush 9 to "see" my Drupal 8 site. The aliases seem to have been created and added to the drush/sites folder and running drush site:alias does show them. However running drush status shows my Drupal root as /app. My Drupal root is /app/docroot. My alias files do have this as their root (for local). I'm not sure why Drush doesn't use the alias files it knows about. I've tried:
drush #self(or #local) list and I get some commands and this statement at the end:
[NOTE] Drupal root not found. Pass --root or a #siteAlias in order to see Drupal-specific commands.
Doing drush #local(or #self) cr returns:
In BootstrapHook.php line 32: Bootstrap failed. Run your command
with -vvv for more information.
With -vvv:
Exception trace: at
/app/vendor/drush/drush/src/Boot/BootstrapHook.php:32
Drush\Boot\BootstrapHook->initialize() at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:34
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->callInitializeHook()
at
/app/vendor/consolidation/annotated-command/src/Hooks/Dispatchers/InitializeHookDispatcher.php:27
Consolidation\AnnotatedCommand\Hooks\Dispatchers\InitializeHookDispatcher->initialize()
at
/app/vendor/consolidation/annotated-command/src/CommandProcessor.php:145
Consolidation\AnnotatedCommand\CommandProcessor->initializeHook() at
/app/vendor/consolidation/annotated-command/src/AnnotatedCommand.php:289
Consolidation\AnnotatedCommand\AnnotatedCommand->initialize() at
/app/vendor/symfony/console/Command/Command.php:221
Symfony\Component\Console\Command\Command->run() at
/app/vendor/symfony/console/Application.php:1005
Symfony\Component\Console\Application->doRunCommand() at
/app/vendor/symfony/console/Application.php:255
Symfony\Component\Console\Application->doRun() at
/app/vendor/symfony/console/Application.php:148
Symfony\Component\Console\Application->run() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:118
Drush\Runtime\Runtime->doRun() at
/app/vendor/drush/drush/src/Runtime/Runtime.php:49
Drush\Runtime\Runtime->run() at /app/vendor/drush/drush/drush.php:72
require() at /app/vendor/drush/drush/drush:4
drush status:
PHP binary : /usr/local/bin/php
PHP config :
PHP OS : Linux
Drush script : /app/vendor/drush/drush/drush
Drush version : 10.2.2 <-- Had 9.0.0 but currently trying 10, same issue
Drush temp : /tmp
Drush configs : /root/.drush/drush.yml
/app/vendor/drush/drush/drush.yml
/app/drush/drush.yml
Drupal root : /app
self.site.yml:
local:
root: /app/docroot
uri: example.lndo.site
Can someone please point me in the right direction?
Figured it out. No matter how many ways you try to tell Drush where to look to find your Drupal root, none of it will matter until you edit your composer.json file. Turns out the key to making Drush 9+ work is changing the name in composer.
My composer.json file name went from:
"name": "drupal/drupal",
to:
"name": "drupal-composer/drupal-project",
I don't think this feature was documented anywhere so I'm posting it here in response to my own question in case this helps anyone else.
I realize that this is an older question, however with Drupal 8 recently reaching end of life, and the high probability of many people (like myself) scrambling to upgrade now that clients have realized the risks of using EOL software, I want to take a moment to explain why #r00t's answer works.
r00t is correct that changing the "name" value in composer.json fixed the issue, however, the value that is set is not limited to drupal-composer/drupal-project. This seems to stem from the package webflo/drupal-finder and the way it works.
webflow/drupal-finder is a requirement of drush/drush, so it's going to be included even if you haven't added it manually. It's also a requirement of a couple of others that you may or may not have installed, like palantirnet/drupal-rector (which as a side note, is really helpful for this upgrade).
Within the code for drupal-finder is a method that looks for the install path of Drupal core based on a few items within your composer.json file.
Here is the code from DrupalFinder::isValidRoot()
foreach ($json['extra']['installer-paths'] as $install_path => $items) {
if (in_array('type:drupal-core', $items) ||
in_array('drupal/core', $items) ||
in_array('drupal/drupal', $items)) {
$this->composerRoot = $path;
// #todo: Remove this magic and detect the major version instead.
if (($install_path == 'core') || ((isset($json['name'])) && ($json['name'] == 'drupal/drupal'))) {
$install_path = '';
} elseif (substr($install_path, -5) == '/core') {
$install_path = substr($install_path, 0, -5);
}
....
Which is telling drupal-finder that if the "name" value is drupal/drupal then the install path of the site is at the base of the project, however if it is not drupal/drupal then use a value from extra.installer-paths to find the site install.
I'm still not aware if this is documented anywhere on either webflo/drupal-finder or in drush/drush, but understanding why it was an issue helped me out tremendously.
TL;DR:
If your site's docroot lives next to your vendor folder, change the name in composer.json to anything that isn't drupal/drupal. If your vendor folder lives inside your docroot, drupal/drupal will work for you.
I am trying for quite some time now to disable the profiler in the test-environment. The only way it works is manually setting APP_ENV=test in file .env but I want to do this through the command line, not by editing a file.
Here's everything I tried:
I tried editing bin/console like described in Chris Brown's answer in this thread: Load different .env file with a Symfony 4 command (I also added the file .env.test, and according to xdebug it loads the appropriate file and runs through the appropriate code and also the variables $env and $debug get the appropriate value when I run the server with --env=test --no-debug)
I tried setting profiler: enabled: false like described in flu's answer in this thread: How to disable profiler in Symfony2 in production? (in config/packages/test/framework.yaml)
I tried setting the profiler line in bundles.php to
Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true],
and to
Symfony\Bundle\WebProfilerBundle\WebProfilerBundle::class => ['dev' => true, 'test' => false, 'test_cached' => false],
I tried those solutions separately and also all together, still the profiler keeps popping up. Does anybody have an idea?
EDIT:
After applying Alister Bulman's answer the command gives me this:
#php bin/console -e test debug:config framework profiler
Current configuration for "framework.profiler"
==============================================
enabled: true
collect: false
only_exceptions: false
only_master_requests: false
dsn: 'file:%kernel.cache_dir%/profiler'
EDIT 2:
Thanks to Jared Farrish I just found out the browser is receiving the website in "dev" mode although the server is started in test environment on cli. Obviously editing bin/console and public/index.php is not enough, they're not called when the server receives a request from the browser.
EDIT 3:
So I found out the http request goes first to public/index.php, but whatever I do, I cannot seem to make anything available there which was defined in bin/console although the whole server is started there in the first place. Anyone an idea how this can be done?
The profile can be enabled, or disabled in the framework configuration.
> bin/console -e dev debug:config framework profiler
Current configuration for "framework.profiler"
==============================================
only_exceptions: false
enabled: true
collect: true
only_master_requests: false
dsn: 'file:%kernel.cache_dir%/profiler'
In a newly generated project, these are best set (for the test environment) in the config/packages/test/framework.yaml file.
framework:
profiler:
enabled: false
collect: false
# optionally others
Documentation for the framework config (profiler, and the rest) is at https://symfony.com/doc/current/reference/configuration/framework.html#profiler
I found it myself. What I did was use a functionality of php.ini which is called "auto_prepend_file" where you can specify a PHP file which gets executed automatically before the actual PHP content is executed. So in there I put a path to a file with following content:
<?php
$_ENV['APP_ENV'] = 'test';
$_ENV['APP_DEBUG'] = 0;
I'm trying to get my head around this: I don't know why the twig debug isn't working:
Drupal version 8.2.6
Folder structure
.
Folder permissions
Settings.php
$settings['hash_salt'] = 'DEVELOPMENT_SALT';
$settings['update_free_access'] = FALSE;
$settings['file_public_base_url'] = 'http://localhost/files';
$settings['file_public_path'] = 'sites/default/files';
$settings['file_private_path'] = 'sites/default/private';
$settings['file_scan_ignore_directories'] = [
'node_modules',
'bower_components',
];
if (file_exists(__DIR__ . '/../development/settings.development.php')) {
include __DIR__ . '/../development/settings.development.php';
}
/../development/settings.development.php
assert_options(ASSERT_ACTIVE, TRUE);
\Drupal\Component\Assertion\Handle::register();
/**
* Enable local development services.
*/
$settings['container_yamls'][] = __DIR__ . '/development.services.yml';
$databases['default']['default'] = array(
'database' => 'dbname',
'username' => 'dbusername',
'password' => 'pw',
'prefix' => '',
'host' => '127.0.0.1',
'port' => '3306',
'namespace' => 'Drupal\\Core\\Database\\Driver\\mysql',
'driver' => 'mysql',
);
$settings['hash_salt'] = 'DEVELOPMENT';
$config['system.logging']['error_level'] = 'verbose';
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$settings['extension_discovery_scan_tests'] = TRUE;
$settings['rebuild_access'] = TRUE;
$settings['skip_permissions_hardening'] = TRUE;
development.services.yml
parameters:
http.response.debug_cacheability_headers: true
twig.config:
debug: true
auto_reload: true
cache: false
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
Things I have checked/done:
Checked if all these files are loaded -> They are.
Checked the indentation of the development.services.yml -> Checks out.
Cleared all the different caches, rebuild them, ...
If I change a template, it changes, but no twig debugging.
What is odd:
sites/default/files AND sites/default/private are not used by Drupal.
I'd recommend against renaming the development.services.yml file to services.yml because that would cause all of your development code/config/settings to apply and run on production environments. Instead, use the development files as designed.
Here's our standard setup:
/sites/default/settings.php (in version control) contains the following at the very bottom so that we only load development stuff on instances that should have it. e.g. NOT production:
/**
* Load local development override configuration, if available.
*
* Keep this code block at the end of this file to take full effect.
*/
if (file_exists(__DIR__ . '/settings.local.php')) {
include __DIR__ . '/settings.local.php';
}
Our /sites/default/settings.local.php (not in version control) contains at least the following:
<?php
/**
* Disable css and js preprocessing.
*/
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
/**
* Disable Render Cache and Dynamic Page Cache.
*/
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
/**
* Enable local development services.
*/
$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
/**
* Enable access to rebuild.php.
*/
$settings['rebuild_access'] = TRUE;
And finally, our /sites/development.services.yml (in version control) file contains this:
# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
http.response.debug_cacheability_headers: true
twig.config:
debug: true
auto_reload: true
cache: false
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
This has worked really well for us.
To enable Twig debug, you need to copy("default.services.yml") and rename it to "services.yml". And set "debug: false" to true.
E.g: services.yml
parameters:
session.storage.options:
# Default ini options for sessions.
#
# Some distributions of Linux (most notably Debian) ship their PHP
# installations with garbage collection (gc) disabled. Since Drupal depends
# on PHP's garbage collection for clearing sessions, ensure that garbage
# collection occurs by using the most common settings.
# #default 1
gc_probability: 1
# #default 100
gc_divisor: 100
#
# Set session lifetime (in seconds), i.e. the time from the user's last
# visit to the active session may be deleted by the session garbage
# collector. When a session is deleted, authenticated users are logged out,
# and the contents of the user's $_SESSION variable is discarded.
# #default 200000
gc_maxlifetime: 200000
#
# Set session cookie lifetime (in seconds), i.e. the time from the session
# is created to the cookie expires, i.e. when the browser is expected to
# discard the cookie. The value 0 means "until the browser is closed".
# #default 2000000
cookie_lifetime: 2000000
#
# Drupal automatically generates a unique session cookie name based on the
# full domain name used to access the site. This mechanism is sufficient
# for most use-cases, including multi-site deployments. However, if it is
# desired that a session can be reused across different subdomains, the
# cookie domain needs to be set to the shared base domain. Doing so assures
# that users remain logged in as they cross between various subdomains.
# To maximize compatibility and normalize the behavior across user agents,
# the cookie domain should start with a dot.
#
# #default none
# cookie_domain: '.example.com'
#
twig.config:
# Twig debugging:
#
# When debugging is enabled:
# - The markup of each Twig template is surrounded by HTML comments that
# contain theming information, such as template file name suggestions.
# - Note that this debugging markup will cause automated tests that directly
# check rendered HTML to fail. When running automated tests, 'debug'
# should be set to FALSE.
# - The dump() function can be used in Twig templates to output information
# about template variables.
# - Twig templates are automatically recompiled whenever the source code
# changes (see auto_reload below).
#
# For more information about debugging Twig templates, see
# https://www.drupal.org/node/1906392.
#
# Not recommended in production environments
# #default false
debug: true
# Twig auto-reload:
#
# Automatically recompile Twig templates whenever the source code changes.
# If you don't provide a value for auto_reload, it will be determined
# based on the value of debug.
#
# Not recommended in production environments
# #default null
auto_reload: null
# Twig cache:
#
# By default, Twig templates will be compiled and stored in the filesystem
# to increase performance. Disabling the Twig cache will recompile the
# templates from source each time they are used. In most cases the
# auto_reload setting above should be enabled rather than disabling the
# Twig cache.
#
# Not recommended in production environments
# #default true
cache: true
renderer.config:
# Renderer required cache contexts:
#
# The Renderer will automatically associate these cache contexts with every
# render array, hence varying every render array by these cache contexts.
#
# #default ['languages:language_interface', 'theme', 'user.permissions']
required_cache_contexts: ['languages:language_interface', 'theme', 'user.permissions']
# Renderer automatic placeholdering conditions:
#
# Drupal allows portions of the page to be automatically deferred when
# rendering to improve cache performance. That is especially helpful for
# cache contexts that vary widely, such as the active user. On some sites
# those may be different, however, such as sites with only a handful of
# users. If you know what the high-cardinality cache contexts are for your
# site, specify those here. If you're not sure, the defaults are fairly safe
# in general.
#
# For more information about rendering optimizations see
# https://www.drupal.org/developing/api/8/render/arrays/cacheability#optimizing
auto_placeholder_conditions:
# Max-age at or below which caching is not considered worthwhile.
#
# Disable by setting to -1.
#
# #default 0
max-age: 0
# Cache contexts with a high cardinality.
#
# Disable by setting to [].
#
# #default ['session', 'user']
contexts: ['session', 'user']
# Tags with a high invalidation frequency.
#
# Disable by setting to [].
#
# #default []
tags: []
# Cacheability debugging:
#
# Responses with cacheability metadata (CacheableResponseInterface instances)
# get X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers.
#
# For more information about debugging cacheable responses, see
# https://www.drupal.org/developing/api/8/response/cacheable-response-interface
#
# Not recommended in production environments
# #default false
http.response.debug_cacheability_headers: false
factory.keyvalue:
{}
# Default key/value storage service to use.
# #default keyvalue.database
# default: keyvalue.database
# Collection-specific overrides.
# state: keyvalue.database
factory.keyvalue.expirable:
{}
# Default key/value expirable storage service to use.
# #default keyvalue.database.expirable
# default: keyvalue.database.expirable
# Allowed protocols for URL generation.
filter_protocols:
- http
- https
- ftp
- news
- nntp
- tel
- telnet
- mailto
- irc
- ssh
- sftp
- webcal
- rtsp
# Configure Cross-Site HTTP requests (CORS).
# Read https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
# for more information about the topic in general.
# Note: By default the configuration is disabled.
cors.config:
enabled: false
# Specify allowed headers, like 'x-allowed-header'.
allowedHeaders: []
# Specify allowed request methods, specify ['*'] to allow all possible ones.
allowedMethods: []
# Configure requests allowed from specific origins.
allowedOrigins: ['*']
# Sets the Access-Control-Expose-Headers header.
exposedHeaders: false
# Sets the Access-Control-Max-Age header.
maxAge: false
# Sets the Access-Control-Allow-Credentials header.
supportsCredentials: false
Twig Debuggin wasn't working as expected, I did all the thing you did and it didn't work. So I searched for debug:false in all the site and found this file: core/core.services.xml
I changed the values there and it worked!
It's not a good way to do this because we are modifying the core, but It will help someone with this problem!
Just duplicate default.services.yml to services.yml. So, core.services.xml will be overwritten.
You need to set the cache option to true on your development.services.yml file.
Something like this:
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
parameters:
twig.config:
debug: true
auto_reload: true
cache: true
After you clear your cache and open some pages that you want to debug you will see that in files/php/twig some .php files will be created, like the bellow image:
on these pages will debug normally as you debug a .php file.
There is an article on the Acquia blog that help you make this configuration and debug using Xdebug and the PhpStorm IDE that you can on the link Debugging TWIG templates in Drupal 8 with PhpStorm and XDebug
For most of you, including this line at the bottom of your settings.php file will do the work:
$settings['container_yamls'][] = DRUPAL_ROOT . '/sites/development.services.yml';
More details
If you already set debug for Twig and nothing works, you are modifying the wrong file.
First, ensure that Drupal is parsing the services file you are modifying. One easy way of doing this is by adding bad YML formatting to the services file you are working with, then try to clear caches, and Drupal should complain like "Unable to parse".
If Drupal doesn't complain despite adding bad YML formatting, it means that the file is not being parsed; hence, it doesn't matter if you change it.
Appending the line I mentioned to your settings.php ensures you are adding the development services configuration, which most of the time has the following contents:
# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
http.response.debug_cacheability_headers: true
twig.config:
# #default false
debug: true
# #default null
auto_reload: true
# #default true
cache: false
services:
cache.backend.null:
class: Drupal\Core\Cache\NullBackendFactory
Recently I've been working on improveing my vagrant enviroment and I've stumbled upon Running the Symfony application on Vagrant without NFS below 100ms blog post.
I've moved the vendor dir outside the VM shared directory, as suggested, by createing /tmp/app/vendor dir inside the VM and setting
export COMPOSER_VENDOR_DIR=/tmp/app/vendor
export COMPOSER_BIN_DIR=/tmp/app/bin
export SF2_ENV=vagrant
enviroment variables before running composer install.
Now, with vendors correctly installed to another path, I've modified the app/autoload.php file to detect if the app is running inside the VM by looking for the SF2_ENV enviroment variable:
if (array_key_exists('SF2_ENV', $_SERVER) && $_SERVER['SF2_ENV'] === 'vagrant') {
// vagrant enviroment detected
$loader = require sys_get_temp_dir().'/app/vendor/autoload.php';
} else {
// default
$loader = require __DIR__.'/../vendor/autoload.php';
}
This worked fine for one project, however on another project I kept getting the
PHP Fatal error: Cannot redeclare class Gedmo\Loggable\Entity\MappedSuperclass\AbstractLogEntry in /var/www/public_html/vendor/gedmo/doctrine-extensions/lib/Gedmo/Loggable/Entity/MappedSuperclass/AbstractLogEntry.php on line 13
error when trying to initialize the app cache php app/console cache:clear -e=prod.
Why was this happening?
Note: I've anwsered myself, as this is a Q&A style question (a note to my future self).
I am posting this as a reminder to my future self or anyone else interested. The problem was becouse in the second project I used Gedmo library and in my config.yml I defined:
doctrine:
orm:
entity_managers:
default:
filters:
softdeleteable:
class: Gedmo\SoftDeleteable\Filter\SoftDeleteableFilter
enabled: true
mappings:
gedmo_translatable:
type: annotation
prefix: Gedmo\Translatable\Entity
dir: "%kernel.root_dir%/../vendor/gedmo/doctrine-extensions/lib/Gedmo/Translatable/Entity"
alias: GedmoTranslatable
is_bundle: false
So, the problem was clearly the %kernel.root_dir% part, which was hardcoded.
Solution
I've simply changed it to %vendor_dir% and defined this parameter in my parameters.yml - for production as vendor_dir: '%kernel.root_dir%/../vendor' and for local (dev) as vendor_dir: /tmp/app/vendor.
I already have problem with symfony2 project on Vagrant. But I resolve this without change location of /vendor directory.
Just disable the nfs share and locate your projects directly on /var/www
you can use this on vagrantFile :
config.vm.synced_folder '.', '/vagrant', disabled: true
Work with your Vagrant as like you work with a remote server...
What happening when you deploying in production environment your autoload.php file ? it's not very useful to change this only for dev environment (I don't speak only for this file but general idea).
I am using Berkshelf, Chef and Vagrant and I am trying to configure a custom site running on nginx. I am using the opscode nginx recipe and then writing my own recipe for the custom site. When I run vagrant up I get the an error about not disabling the default nginx site. I've found several different suggestions but nothing seems to be working.
The error:
STDOUT:
STDERR: nginx: [emerg] a duplicate default server for 0.0.0.0:80 in /etc/nginx/sites- enabled/kyleboon.me:2
nginx: configuration file /etc/nginx/nginx.conf test failed
My Berksfile:
site :opscode
metadata
cookbook 'nginx'
The 'roles/web.json' role I defined:
{
"name": "web",
"chef_type": "role",
"json_class": "Chef::Role",
"description": "The base role for systems that serve HTTP traffic",
"default_attributes": {
"nginx": {
"default_site_enabled": false
},
"app": {
"name": "kyleboon.me",
"web_dir": "/var/data/www/kyleboon.me"
},
"user":{
"name": "vagrant"
}
},
"run_list": [
"recipe[nginx]",
"recipe[kyleboon.me]"
]
}
Here is the recipes/default/default.rb for the nginx site I am adding:
nginx_site 'default' do
action :disable
end
%w(public logs).each do |dir|
directory "#{node.app.web_dir}/#{dir}" do
owner node.user.name
mode "0755"
recursive true
end
end
template "#{node.nginx.dir}/sites-available/kyleboon.me" do
source "site.erb"
mode 0777
owner node.nginx.user
group node.nginx.user
end
nginx_site "kyleboon.me"
cookbook_file "#{node.app.web_dir}/public/index.html" do
source "index.html"
mode 0755
owner node.user.name
end
(P.S. I know the file permissions need to be changed, I've just been fiddling with lots of things, I'll update those once I get everything else working)
And here is attributes/default.rb:
override['nginx']['enable_default_site'] = false
You can see I have tried to disable the default site in the web.json, the attributes and the recipe itself but none of them stick.
I don't have a node or solo node defined and I'm not sure if that's an issue. My main problem with vagrant so far has been the endless possibilities for how to do things. No two examples are done in the same way and I'm not sure what is considered the 'best' or 'right' way to go.
You can disable any nginx site by name using the nginx_site and its name. The problem you are having is because the nginx_site definition is actually looking for the enable parameter to be set to true or false not the action parameter set to :disabled.
To disable the default site add to your recipe:
nginx_site 'default' do
enable false
end
This is working for me as of version 1.7.1 of the nginx opscode cookbook. I dont know if this will work with the version provided by community as it appears to be several months old.
To get the latest version add to your Berksfile:
cookbook 'nginx', git: 'https://github.com/opscode-cookbooks/nginx'
Hope that helps :)
I'm getting the same error, but I don't have the default site enabled. Instead, it's coming from /etc/nginx/conf.d/default.conf! I had to resort to
file "/etc/nginx/conf.d/default.conf" do
action :delete
end
This is coming from the RHEL package that the nginx cookbook is installing on my box.