evolution / genesis-wordpress Goto Github PK

When connecting to a staging server that's behind a closed IP through VPN both 'cap staging genesis:provision' and 'cap staging deploy' fail due to authentication (requests for passwords).

For provisioning:

Run cap staging genesis:provision -S user=example -S password=example, scripts execute but fail at Apache init

executing "sudo /etc/init.d/apache2 graceful"
    servers: ["staging.example.com"]
    [staging.example.com] executing command
 ** [out :: staging.example.com] [sudo] password for ubuntu:

For deployment:

Run cap staging deploy on branch genesis-wordpress, scripts execute but fail on GH auth

 ** transaction: start
Password for 'https://[email protected]': 
 ** [staging.example.com :: out] Password for 'https://[email protected]':
Password: 
 ** [staging.example.com :: out]
 ** [staging.example.com :: out] fatal: Authentication failed
*** [deploy:update_code] rolling back
failed: "/bin/bash -c 'if [ -d /var/www/example.com/genesis-wordpress/shared/cached-copy ]; then cd /var/www/example.com/genesis-wordpress/shared/cached-copy && git fetch -q origin && git fetch --tags -q origin && git reset -q --hard COMMIT_ID && git clean -q -d -x -f; else git clone -q -b genesis-wordpress https://[email protected]/ORG/example.com.git /var/www/example.com/genesis-wordpress/shared/cached-copy && cd /var/www/example.com/genesis-wordpress/shared/cached-copy && git checkout -q -b deploy COMMIT_ID; fi'" on staging.example.com

user names, passwords, urls, organizations and commit ids have been altered to protect the innocent :)

http://docs.vagrantup.com/v2/networking/forwarded_ports.html

I think that perhaps some of the random ports are actually in use by system services, in which case we should have Vagrant auto-correct and use something else.

See this:

evolution/generator-wordpress#8

/cc @EvanK @ericrasch

It's neat, and it makes output pretty (when it works), but --verbose is useful. It's not too scary to have as the default, is it?

Leaving this here, as I'm using the wrong command invoke_command "sudo ..." instead of sudo "..."

*sidenote: I'm doing this at home. Doesn't seem to fail in the office. I swear I don't have some backwoods dialup internet, either.

 ~/Sites/cmn.dev/github/websiterepo.com  ⑂ genesis-wordpress    bower update
bower genesis-wordpress#~0.2.*  cached git://github.com/genesis/wordpress.git#0.2.25
bower genesis-wordpress#~0.2.*         validate 0.2.25 against git://github.com/genesis/wordpress.git#~0.2.*
bower genesis-wordpress#~0.2.*              new version for git://github.com/genesis/wordpress.git#~0.2.*
bower genesis-wordpress#~0.2.*          resolve git://github.com/genesis/wordpress.git#~0.2.*
bower genesis-wordpress#~0.2.*         download https://github.com/genesis/wordpress/archive/v0.2.26.tar.gz
bower genesis-wordpress#~0.2.*          extract archive.tar.gz
bower genesis-wordpress#~0.2.*         resolved git://github.com/genesis/wordpress.git#0.2.26
bower genesis-wordpress#~0.2.*          install genesis-wordpress#0.2.26

genesis-wordpress#0.2.26 bower_components/genesis-wordpress
 ~/Sites/cmn.dev/github/websiterepo.com  ⑂ genesis-wordpress    vagrant provision
[local] Running provisioner: hostmanager...
[local] Running provisioner: shell...
[local] Running: inline script
stdin: is not a tty
W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise/InRelease  

W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise-updates/InRelease  

W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/precise-backports/InRelease  

W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/precise-security/InRelease  

...yada yada yada

Just to make sure we don't have any problems with previously uploaded images & permissions...

Read the title, dummy!

deploy_to is necessary for a lot of shared hosts.

There are several plugins to do this now that can be researched:

• http://wordpress.org/plugins/assetsminify/
• http://wordpress.org/plugins/autoptimize/
• http://wordpress.org/plugins/wp-minify/

Notes:

• 3rd party plugins that auto-enqueue local scripts get the same benefit
• scripts enqueued in the header vs. footer should be respected (e.g. html5shiv, modernizr)
• is it right to enqueue a .coffee, .sass, .less file in WP? My gut says no...
• should the solution be a plugin that intercepts, or part of a build process?
• there should be distinction between either WP_DEBUG or WP_ENV

See:

evolution/generator-wordpress#6

• wp-config.php needs WP_CACHE boolean
• wp-config.php needs register_shutdown_function
• .htaccess needs no_robots.txt
• Vagrantfile
• Capfile
• config/ssh generation
• bin/provision generation/cleanup
• config/deploy generation
• .gitignore creation/modification
• README.md creation

I'm trying to deploy a newly generated WP site onto my staging server. Here's the command I ran:

cap staging genesis:provision -S user=myuser -S password=mypass --verbose

(with obvious user/pass substitutions). I've got capistrano, ruby, etc. installed. When I run the command, I can successfully ssh in and upload all the files. The process fails on:

Running provisioning script
  * executing "sudo -p 'sudo password: ' /tmp/antjanus-website.2013-10-16.000519/bin/provision"
    servers: ["staging.antjanus.com"]
    [staging.antjanus.com] executing command
 ** [out :: staging.antjanus.com] 
    command finished in 4544ms

     *** Unable to provision as "user"!
     *** Try running: $ cap staging provision -S user=... -S password=...

where staging.antjanus.com is the site/server name. Contents of /bin/provision

    #!/usr/bin/env bash

## Must be run as root...
if [[ $EUID -ne 0 ]]; then
    echo "This script must be run root:"
    echo "  \$ sudo $0"
    exit 1
fi

# Ansible dependencies
apt-get -qq -y update
apt-get -qq -y install python-software-properties
add-apt-repository -y ppa:rquillo/ansible &> /dev/null || exit 1
apt-get -qq -y update

# Ansible
apt-get -qq -y install ansible

# Run provisioning playbook
(cd "$( dirname "$0" )/../provisioning" && ansible-playbook -i localhost $@ provision.yml)

Any idea on why it would fail? I can try running and installing ansible manually as well as invoke the provisioning playbook.

EDIT

I'm not using the root user because of its lockdown so I have another user that's been added to the sudoers list so it can execute sudo. I've logged in with the user and have been successfully able to run sudo commands.

Vagrant's required to be running for genesis:down:db and genesis:up:db, so run vagrant up before this.

• Run bower list on the client machine to show what's in your repo
• Check a genesis version file to see what version #{stage} was provisioned at

This can be useful to ensure that, perhaps when deploying, all of the bug fixes are out.

In the wp-config.php, the database tables won't always have the prefix of wp_, so detecting and allowing this to change in the generator would help: $table_prefix = 'wp_';

Adding footer links is just stupid and makes merging changes with an existing README a PITA.

So this is not likely how I was supposed to do this, and now I need a way out.

I have the staging server on a VPS and was running bower_components 0.21. It is already provisioned and works fine.
I upgrade the local copy with bower update and went to 0.24
Wanted to see the varnish cache fix, so I cap staging genesis:provision. I imagine that was not the right thing (or is it?), since it begins to re-provision the packages as deploy user. But it gets to bower, and poops out. Something in the npm package compare? Log follows below (I snipped out a lot of file listings).

So to get staging to use the new genesis/wordpress bower components, do I issue a cap deploy? Even if no local changes? Or is there a cap task to 'bower update' the remote machine? Thanks!

$ cap staging genesis:provision
  * 2013-10-24 16:06:49 executing `production'
    triggering start callbacks for `genesis:provision'
  * 2013-10-24 16:06:49 executing `multistage:ensure'
  * 2013-10-24 16:06:49 executing `genesis:provision'
  * executing "mkdir -p /tmp/mysite.com.2013-10-24.160649 /tmp/mysite.com.2013-10-24.160649/bower_components/genesis-wordpress"
    servers: ["staging.mysite.com"]
    [staging.mysite.com] executing command
    command finished in 149ms
    servers: ["staging.mysite.com"]
 ** scp upload ./bin -> /tmp/mysite.com.2013-10-24.160649/bin
    [staging.mysite.com] ./bin/provision
  * scp upload complete
    servers: ["staging.mysite.com"]
 ** scp upload ./provisioning -> /tmp/mysite.com.2013-10-24.160649/provisioning
    [staging.mysite.com] ./provisioning/files/ssh/id_rsa
    [staging.mysite.com] ./provisioning/files/ssh/id_rsa.pub
    [staging.mysite.com] ./provisioning/group_vars/webservers
    [staging.mysite.com] ./provisioning/local
    [staging.mysite.com] ./provisioning/localhost
    [staging.mysite.com] ./provisioning/production
    [staging.mysite.com] ./provisioning/provision.yml
    [staging.mysite.com] ./provisioning/staging
  * scp upload complete
    servers: ["staging.mysite.com"]
 ** scp upload ./bower_components/genesis-wordpress/provisioning -> /tmp/mysite.com.2013-10-24.160649/bower_components/genesis-wordpress/provisioning
    [staging.mysite.com] ./bower_components/genesis-wordpress/provisioning/provision.yml
    [staging.mysite.com] ./bower_components/genesis-wordpress/provisioning/roles/common/tasks/main.yml

    LOTS OF BOWER_COMPONENTS COPYING OVER JUST FINE

    [staging.mysite.com] ./bower_components/genesis-wordpress/provisioning/roles/wordpress/templates/vhosts/003-production
    [staging.mysite.com] ./bower_components/genesis-wordpress/provisioning/roles/wordpress/vars/main.yml
  * scp upload complete
  * executing "sudo -p 'sudo password: ' /tmp/mysite.com.2013-10-24.160649/bin/provision"
    servers: ["staging.mysite.com"]
    [staging.mysite.com] executing command
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] PLAY [webservers] *************************************************************
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] TASK: [Add Node apt-repository] ***********************************************
 ** [out :: staging.mysite.com] ok: [127.0.0.1]
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] TASK: [Update apt repositories] ***********************************************
 ** [out :: staging.mysite.com] ok: [127.0.0.1]
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] TASK: [Install system packages] ***********************************************
 ** [out :: staging.mysite.com] ok: [127.0.0.1] => (item=build-essential,autoconf,re2c,curl,git-core,python-mysqldb,nodejs)
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] TASK: [Install bower] *********************************************************
 ** [out :: staging.mysite.com] failed: [127.0.0.1] => {"changed": true, "cmd": ["npm", "install", "-g", "bower"], "delta": "0:00:07.525819", "end": "2013-10-24 21:07:22.963039", "item": "", "rc": -9, "start": "2013-10-24 21:07:15.437220"}
 ** [out :: staging.mysite.com] stderr: npm http GET https://registry.npmjs.org/bower
 ** [out :: staging.mysite.com] npm http 304 https://registry.npmjs.org/bower
 ** [out :: staging.mysite.com] npm http GET https://registry.npmjs.org/archy/0.0.2
 ** [out :: staging.mysite.com] npm http GET https://registry.npmjs.org/bower-config

    LOTS OF NPM PACKAGES HERE

 ** [out :: staging.mysite.com] npm http 304 https://registry.npmjs.org/mute-stream
 ** [out :: staging.mysite.com] npm http 304 https://registry.npmjs.org/redeyed
 ** [out :: staging.mysite.com] npm http 304 https://registry.npmjs.org/ansicolors
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] FATAL: all hosts have already failed -- aborting
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] PLAY RECAP ********************************************************************
 ** [out :: staging.mysite.com] to retry, use: --limit @/home/deploy/provision.retry
 ** [out :: staging.mysite.com] 
 ** [out :: staging.mysite.com] 127.0.0.1                  : ok=3    changed=0    unreachable=0    failed=1
 ** [out :: staging.mysite.com] 
    command finished in 27121ms

*** Unable to provision as "deploy"!
*** Try running: $ cap staging genesis:provision -S user=... -S password=...

This should remove #{deploy_to}/#{application}

http://codex.wordpress.org/Version_3.7

The only problem I can foresee is the automatic background updates. Great for those on shared hosts, bad for versioned deployments.

WPEngine is disabling it (via a constant, iirc) since they have managed clients.

Either way, it may deserve to just be an option when generating the scaffolding...

The WordPress stuff is buggy at best.

We should also remove the "helpful" crap that makes Varnish complicated, and just leave the stuff that makes it useful.

Therefore, no more normalization, no more "if this URL do this, if not do this", none of that.

The only cookies that are ignorable are Urchin/GA/tracking cookies that all use the _ prefix.

bower install runs after deploy:update alongside genesis:permissions and a few other commands, but these should be ran after deploy:update_code and deploy:finalize_update, respectively.

The reason being, the site is live once deploy:create_symlink is ran, which means that we don't want any more changes made to the codebase after this happens.

 $ cap staging deploy
    triggering load callbacks
  * 2013-11-19 11:20:48 executing `staging'
    triggering start callbacks for `deploy'
  * 2013-11-19 11:20:48 executing `multistage:ensure'
  * 2013-11-19 11:20:48 executing `deploy'
  * 2013-11-19 11:20:48 executing `deploy:update'
    triggering before callbacks for `deploy:update'
  * 2013-11-19 11:20:48 executing `deploy:setup'
 ** transaction: start
  * 2013-11-19 11:21:03 executing `deploy:update_code'
  * 2013-11-19 11:23:10 executing `deploy:finalize_update'
  * 2013-11-19 11:23:11 executing `deploy:create_symlink'
 ** transaction: commit
    triggering after callbacks for `deploy:update'
  * 2013-11-19 11:23:20 executing `genesis:permissions'
  * 2013-11-19 11:23:37 executing `deploy:restart'
    triggering after callbacks for `deploy:restart'
  * 2013-11-19 11:23:37 executing `genesis:restart'
    triggering after callbacks for `deploy'

If a machine is created with a hostname already set (by rackspace, vcenter, etc.), it may have a name like new4.

Upon provisioning, it should have a name like staging.mysite.com, so the user knows which machine they're on.

When doing local content or settings changes then pushing to staging with

cap staging genesis:up  (or just :db)

The wp option wp-address and site-address (Settings > General) get changed to

local.mysite.com

which, of course, screws up links in the admin (and relative ones in the user site).

Should there be a way to save the root urls and re-publish them when replacing the database? Or is there something I'm missing that should be happening (that is not?)

Thanks, Mike

Scenario: Go either to the Updates section or the Plugins page, select more than one plugin to update (or just select all), and try to update.

Result: The maintenance file will be added to the project root, some files will be downloaded, but not all, and nothing will seemingly complete. In addition, the upgrade progress will not be displayed, and as a grande finale, you'll end up with a white screen of death when you try to click on any links.

• VirtualBox v4.2
• Capistrano v2.*
• Vagrant v1.3.5
• Node v0.10.12+
• NPM v1.2.32

When running genesis:up/down:files the only part we need is the uploads directory. Currently, if you have bower or node components (or anything else you're ignoring from git) in the local version of your theme, they'll be synced to the remote server.

I can't determine if there is a permissions issue or possibly a url rewrite issue?

Many plugins (for instance) fail to allow deletion from the web ui. At first I thought permissions issue so

cap staging genesis:permissions

On staging for instance

vagrant@staging:/var/www/mysite.com/master/current/web/wp-content/plugins
drwxrwxr-x 4 deploy www-data 4096 Oct 17 19:07 .
drwxrwxr-x 5 deploy www-data 4096 Oct 17 20:01 ..
drwxrwxrwx 2 deploy www-data 4096 Oct 17 19:04 hello-dolly
-rwxrwxr-x 1 deploy www-data   30 Oct 16 19:12 index.php

Trying to delete the hello dolly plugin from the wp ui, presents the Connection Information, implying the permissions are not allowed.

For kicks,

sudo chmod -R 0777 /var/www/mysite.com/master/current/web

then

vagrant@staging:/var/www/mysite.com/master/current/web/wp-content/plugins
drwxrwxrwx 4 deploy www-data 4096 Oct 17 19:07 .
drwxrwxrwx 5 deploy www-data 4096 Oct 17 20:01 ..
drwxrwxrwx 2 deploy www-data 4096 Oct 17 19:04 hello-dolly
-rwxrwxrwx 1 deploy www-data   30 Oct 16 19:12 index.php

I can delete hello dolly from the wp ui on 'local', but when I try to add plugins from the either the online plugin repo or even uploading, I get a blank screen and no errors on many (most) of the plugins.

I thought maybe url rewrites as well, because while some plugins work when installing from the wp ui, others do not. I cannot determine the criteria.

I have turned on all php errors in wp-config.php with

@ini_set( 'log_errors', 'Off' );
@ini_set( 'display_errors', 'On' );
@ini_set( 'error_reporting', E_ALL );
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', false );
define( 'WP_DEBUG_DISPLAY', true );

When trying to install wp-client-lite on 'local' gives a blank screen (even with all php error debugging on) and no errors reported in apache logs and the url is

http://local.mysite.com/wp-admin/update.php?action=install-plugin&plugin=wp-client-client-portals-file-upload-invoices-billing&_wpnonce=d1a0dc7dd0

Trying to instal WP Widget Preview on 'local' works fine with url

http://local.mysite.com/wp-admin/update.php?action=install-plugin&plugin=wp-widget-preview&_wpnonce=4b70a21e76

Maybe a missing php extension?

All this odd too because, of course, adding and deleting media works without issue (so far).

Thanks.

Mike

It would be great to be able to tweak the environments based on their use.

We are doing that slightly with the WP_DEBUG and WP_ENV vars within WP, but I would like a way to include more env-specific configs - both system and WP. Perhaps a file in WP called based on the WP_ENV result?

For the system, I'm specifically thinking of things like varnish. It doesn't seem that one would want to run varnish on a development box (local). It may run slower, but because I am changing all sorts of things, I don't want to worry about system-level caching. I've had the instance where I was tweaking css and the screen does not reflect those changes because of caching (I assume). So I have to manually restart varnish to see changes.

I'm not sure if this has to live in the vhost, or if we can just add a genesis file to /etc/apache2/conf.d

# ##############################################################################
# # SECURITY                                                                   #
# ##############################################################################

# ------------------------------------------------------------------------------
# | File access                                                                |
# ------------------------------------------------------------------------------

# Block access to directories without a default document.
# Usually you should leave this uncommented because you shouldn't allow anyone
# to surf through every directory on your server (which may includes rather
# private places like the CMS's directories).

<IfModule mod_autoindex.c>
    Options -Indexes
</IfModule>

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Block access to hidden files and directories.
# This includes directories used by version control systems such as Git and SVN.

<IfModule mod_rewrite.c>
    RewriteCond %{SCRIPT_FILENAME} -d [OR]
    RewriteCond %{SCRIPT_FILENAME} -f
    RewriteRule "(^|/)\." - [F]
</IfModule>

# - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

# Block access to backup and source files.
# These files may be left by some text editors and can pose a great security
# danger when anyone has access to them.

<FilesMatch "(^#.*#|\.(bak|config|dist|fla|inc|ini|log|psd|sh|sql|sw[op])|~)$">
    Order allow,deny
    Deny from all
    Satisfy All
</FilesMatch>

# protect wpconfig.php
<files wp-config.php>
    Order deny,allow
    deny from all
</files>



# #################################################################################
# # WEB PERFORMANCE                                                               #
# # Source: https://github.com/h5bp/html5-boilerplate/blob/master/.htaccess#L364  #
# #################################################################################

# ------------------------------------------------------------------------------
# | Compression                                                                |
# ------------------------------------------------------------------------------

<IfModule mod_deflate.c>

    # Force compression for mangled headers.
    # http://developer.yahoo.com/blogs/ydn/posts/2010/12/pushing-beyond-gzipping
    <IfModule mod_setenvif.c>
        <IfModule mod_headers.c>
            SetEnvIfNoCase ^(Accept-EncodXng|X-cept-Encoding|X{15}|~{15}|-{15})$ ^((gzip|deflate)\s*,?\s*)+|[X~-]{4,13}$ HAVE_Accept-Encoding
            RequestHeader append Accept-Encoding "gzip,deflate" env=HAVE_Accept-Encoding
        </IfModule>
    </IfModule>

    # Compress all output labeled with one of the following MIME-types
    # (for Apache versions below 2.3.7, you don't need to enable `mod_filter`
    #  and can remove the `<IfModule mod_filter.c>` and `</IfModule>` lines
    #  as `AddOutputFilterByType` is still in the core directives).
    <IfModule mod_filter.c>
        AddOutputFilterByType DEFLATE application/atom+xml \
                                      application/javascript \
                                      application/json \
                                      application/rss+xml \
                                      application/vnd.ms-fontobject \
                                      application/x-font-ttf \
                                      application/x-web-app-manifest+json \
                                      application/xhtml+xml \
                                      application/xml \
                                      font/opentype \
                                      image/svg+xml \
                                      image/x-icon \
                                      text/css \
                                      text/html \
                                      text/plain \
                                      text/x-component \
                                      text/xml
    </IfModule>

</IfModule>

# ------------------------------------------------------------------------------
# | ETag removal                                                               |
# ------------------------------------------------------------------------------

# Since we're sending far-future expires headers (see below), ETags can
# be removed: http://developer.yahoo.com/performance/rules.html#etags.

# `FileETag None` is not enough for every server.
<IfModule mod_headers.c>
    Header unset ETag
</IfModule>

FileETag None

# ---------------------------------------------------------------------------------
# | Expires headers (for better cache control)                                    |
# | Source: https://github.com/h5bp/html5-boilerplate/blob/master/.htaccess#L434  |
# ---------------------------------------------------------------------------------

# The following expires headers are set pretty far in the future. If you don't
# control versioning with filename-based cache busting, consider lowering the
# cache time for resources like CSS and JS to something like 1 week.

<IfModule mod_headers.c>
  <FilesMatch "\.(js|css|xml|gz)$">
    Header append Vary Accept-Encoding
  </FilesMatch>
</IfModule>

<IfModule mod_expires.c>

    ExpiresActive on
    ExpiresDefault                                      "access plus 1 month"

  # CSS
    ExpiresByType text/css                              "access plus 1 year"

  # Data interchange
    ExpiresByType application/json                      "access plus 0 seconds"
    ExpiresByType application/xml                       "access plus 0 seconds"
    ExpiresByType text/xml                              "access plus 0 seconds"

  # Favicon (cannot be renamed!)
    ExpiresByType image/x-icon                          "access plus 1 year"

  # HTML components (HTCs)
    ExpiresByType text/x-component                      "access plus 1 month"

  # HTML
    ExpiresByType text/html                             "access plus 0 seconds"

  # JavaScript
    ExpiresByType application/javascript                "access plus 1 year"
    ExpiresByType application/x-javascript              "access plus 1 year"
    ExpiresByType text/javascript                       "access plus 1 year"

  # Manifest files
    ExpiresByType application/x-web-app-manifest+json   "access plus 0 seconds"
    ExpiresByType text/cache-manifest                   "access plus 0 seconds"

  # Media
    ExpiresByType audio/ogg                             "access plus 1 month"
    ExpiresByType image/gif                             "access plus 1 month"
    ExpiresByType image/jpeg                            "access plus 1 month"
    ExpiresByType image/jpg                             "access plus 1 month"
    ExpiresByType image/jpg                             "access plus 1 month"
    ExpiresByType image/png                             "access plus 1 month"
    ExpiresByType video/mp4                             "access plus 1 month"
    ExpiresByType video/ogg                             "access plus 1 month"
    ExpiresByType video/webm                            "access plus 1 month"
    ExpiresByType image/icon                            "access plus 1 year"
    ExpiresByType application/x-ico                     "access plus 1 year"
    ExpiresByType application/ico                       "access plus 1 year"

  # Web feeds
    ExpiresByType application/atom+xml                  "access plus 1 hour"
    ExpiresByType application/rss+xml                   "access plus 1 hour"

  # Web fonts
    ExpiresByType application/font-woff                 "access plus 1 month"
    ExpiresByType application/vnd.ms-fontobject         "access plus 1 month"
    ExpiresByType application/x-font-ttf                "access plus 1 month"
    ExpiresByType font/opentype                         "access plus 1 month"
    ExpiresByType image/svg+xml                         "access plus 1 month"

</IfModule>

We should ship with an iptables configuration tuned for hardened web apps.

I figure, for all but the local stage, we can lock down all ports except 22 (ssh), 80 (http), and 443 (ssl). We can use the iptables-persistent package to simplify loading & persisting

We used to not have this problem, but apparently wp-content/uploads needs to be 775 instead of 755.

Their relationship should be bi-directional (giggity).

Then maybe we can tone back permissions to 644 and 755 for directories & files, respectively.

I just updated the generator, decided to start on a new site, so I ran the generator in a new folder, installed WP3.6.1, and did the whole bower update, vagrant up, and everything got installed as it should have. I loaded up the local site and was able to view all the pages except when I tried to login, I had some issues.

When logging in, wordpress would redirect me back to the login page. No password message or anything. When I try the wrong password, I get redirected but get the correct error message (so correct behavior).

Any ideas? This was a clean install from scratch so I wasn't porting over anything.

Here's what I tried so far:

• various number of vagrant reload and vagrant provision in hopes of things magically working
• removing .htaccess rules in case of problems
• checked /etc/hosts but everything was in right order
• checked for accidental caching of login page, no caching was done.
• traced the redirects: wp-login.php gets found redirects to wp-admin/ which then redirects to wp-login.php for some reason.

Could this be some cookie issue?

Though I don't know yet how we'll implement this, we'd like to — as part of the provisioning process — calculate a php memory_limit and several apache directives, based on the server's total RAM capacity.

Our target machine for a genesis install would have 2GB or more, while the local vagrant machine currently is allocated 1GB.

Note: I'm assuming #53 would mean Vagrant's memory usage would be negligible and roll into the overall system reserved memory.

First, we should calculate memory set aside for specific non-apache uses. I'm thinking the following:

• System reserved memory: 512M for a machine with 2G or more, otherwise 1/4 of total system memory
• MySQL reserved memory: 512M for a machine with 2G or more, otherwise 320M
• PHP memory_limit: 256M for a machine with 2G or more, otherwise 128M

And apache-specific settings:

• StartServers: 5 for a machine with 2G or more, otherwise 2
• MinSpareServers: 5 for a machine with 2G or more, otherwise 2
• MaxSpareServers: 10 for a machine with 2G or more, otherwise 3
• MaxRequestsPerChild: Pulling a figure out of thin air, but I'm thinking 5000 should work?
• MaxClients: the greater of these two:
  • ($TotalMemory - $ReservedSystemMemory - $ReservedMysqlMemory) / $PhpMemoryLimit
  • The number of vcpus the machine has

Thoughts?

When working with genesis:wp on a staging site, I quickly got out of sync between deployments and pushing files to the staging site.

Since, for instance, the wp-content/themes directory is both in the repo and gets sync'd with deploy staging genesis:up, I find that if I do not commit the changes to the themes directory to the repo, after copying theme files over, the next deployment (of course) removes the theme because the themes directory is not shared between releases.

So what happens is that I try a new theme on local, complete some settings, want to see it on staging. I cap staging genesis:up and look at it on staging. Then I make a code change on local, commit the change, then deploy on staging. At this point, staging has "lost" the theme copied over and the database points to an unknown theme.

My question is then, should the themes directory/files (and others like it, e.g. plugins)

• still be part of the file sync,
• be a shared directory (between releases),
• always be repo committed before attempting to deploy/sync other changes

Thanks! Mike

This is enough, right?

https://twitter.com/auroraeosrose/status/396304595451781120

We have no opcode caches running because of major issues.

Regarding plugin compatibility, I read that > 94% of plugins are using PDO instead of MySQL, so we should be fine...

It seems the .html page isn't cached on local, but all other assets are (such as js, css, etc.)

This could be because of the return (hit_or_pass) performed right after unsetting cookies from static assets in production.vcl, so that should probably go anyway. (PHP is the slow down, not static files , right?)

It's set to 1GB, as is varnish, so machines with 2gb will likely have issues.

can you add htop to the deployment , this tool is useful to view processes , memory usage, etc
thanks

33d99a5#commitcomment-4394702

1. Visit home page (GOOD)
2. Log in to /wp-admin (GOOD)
3. Visit home page and notice the WP Admin Toolbar doesn't appear (BAD)

Yet another useful package to add to the Genesis project!

See:

• PHP Agent
• Server Monitoring

Also, another useful package to add to the project :)

https://developers.google.com/speed/pagespeed/module

This was a decent option ~3 years ago when I last reviewed it, but is probably significantly more useful now.

If anything, the automatic compilation/minification of localized assets & reduction of images would be extremely useful for performance. Doing it anywhere else would not be nearly as performant.

curl https://raw.github.com/mitchellh/vagrant/master/keys/vagrant.pub >> ~/.ssh/authorized_keys

We have to be able to notify users of password changes via WordPress, so make sure mail(...) in PHP works...