Git Product home page Git Product logo

wordpress's Introduction

Seravo.com

Seravo WordPress project template

Brought to you by Seravo.com.

A WordPress project layout for use with Git, Composer and Nginx. It also includes a config a Vagrant box and Docker image for local development.

This same project layout is used by default on all Seravo.com instances for easy deployment workflow. Contents of this repository equals to what you would have on the server in the directory /data/wordpress/.

Documentation

Please see our documentation at https://seravo.com/docs/ on general information about git workflow with this project template.

Installation

Please see our documentation at https://seravo.com/docs/development/how-to-install/ on how to install Vagrant and its dependencies.

Features

  • Includes Nginx, MariaDB, PHP7, PHP8, Redis and Git for running WordPress in modern stack.
  • Git hooks to test your code to make sure that only high quality code is committed into git
  • Advanced WordPress acceptance tests with Codeception and headless Chrome
  • PHP Codesniffer code style and quality analyzer
  • Includes self-signed certs (and trust them automatically in OS X) to test https:// locally
  • Xdebug and Webgrind for debugging and profiling your application
  • Mailcatcher to imitate as SMTP server to debug mails
  • Adminer for a graphical interface to manage your database
  • BrowserSync as automatic testing middleware for WordPress

Credentials for vagrant

WordPress:

user:     vagrant
password: vagrant

MariaDB (MySQL):

user:     root
password: root

Development

The layout of this repo is designed in a way which allows storing the site in version control without exposing any confidential data. By default all sensitive data is ignored by git.

All plugins are handled by Composer so they are ignored by git. If you create custom plugins, force add them to git so that they are tracked or add new lines into .gitignore to not ignore.

Example of not ignore line in .gitignore:

!htdocs/wp-content/plugins/your-plugin/

If you create custom themes, they are automatically tracked in git.

Best way to develop custom plugins and themes is to add them into their own repositories and install them by composer. You can do this by adding composer.json for your plugin/theme and then requiring them in your project like:

"repositories": [
  {
      "type": "vcs",
      "url": "https://github.com/your-name/custom-plugin.git"
  }
],
"require": {
    "your-name/custom-plugin": "*"
}

Updates

Vagrant will let you know as soon as a new version of the Vagrant box is available. However, site environment will not be updated automatically to newer one.

To download and update your Vagrant box to use the newest image run:

vagrant box update
vagrant destroy
vagrant up

Configuration

config.yml

Change name in config.yml to change your site name. This is used in quite some places in development environment.

Add production => domain and production => ssh_port to sync with your production instance.

Add new domains under development => domains before first vagrant up to have extra domains.

See config-sample.yml for more.

The Layout

The root of this repository equals the contents of the directory /data/wordpress in the Seravo.com instance.

├── config.yml # Project name, domains and other configuration
├── composer.json # Composer definition, used to pull in WordPress and plugins
├── composer.lock # Composer lock file. This is safe to delete and ignore as detailed dependency control is not relevant in WordPress.
├── gulpfile.js # Gulp example with correct paths
├── Vagrantfile # Vagrantfile for Seravo/WordPress Vagrant box
│
├── nginx # Custom modifications to Nginx which are also used in production
│   └── examples.conf # Some examples to get started
│   └── anything.conf # Your own config files can be named anything *.conf
│
├── scripts
│   ├── hooks # Git hooks for your project
│   │   ├── pre-commit # Run after every git commit
│   │   └── post-receive # Run after every git pull/push
│   │
│   ├── WordPress
│   │   └── Installer.php # Composer helper for WordPress installation
│   │
│   └── run-tests # Bash script as an interface for your tests in Seravo's production and development environments
│
├── vendor # Composer packages go here
└── htdocs # The web root of your site
    ├── wp-content # Directory moved out of WordPress core for git compatibility
    │   ├── mu-plugins
    │   ├── plugins
    │   ├── themes
    │   └── languages
    ├── wp-config.php
    ├── wp-load.php
    ├── index.php
    └── wordpress # WordPress core
        ├── wp-admin
        ├── index.php
        └── ...

Credits

  • Directory layout heavily inspired by roots/bedrock
  • Development stack inspired by VVV

Copyright Seravo Oy, 2015–2023 and contributors. Available under the GPLv3 license.

wordpress's People

Contributors

frimro avatar joosuakoskinen avatar k1sul1 avatar luuptekman avatar onnimonni avatar ottok avatar pekkakortelainen avatar runomarsista avatar samikeijonen avatar sjaks avatar spktklr avatar ssaarikangas avatar tnottu avatar ypcs avatar zarubaru 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

wordpress's Issues

composer broken inside box

Box version 20161129.13.3300

vagrant up
vagrant ssh
composer

Gives this:

[Thu Dec 22 16:57:41 2016] [hphp] [2966:7f85a6639a00:0:000001] [] 
Fatal error: unexpected St13runtime_error: locale::facet::_S_create_c_locale name not valid

Run e2e tests in pre-push hook by default

Let's face it. The rspec tests are slow, and doing subsequent commits one after another and forgetting to skip them is a bit painful, especially because we can't abort the tests. ^C or ^D will stop the git commit, but the tests will keep running in the background and flood stdout with the test output.

Wouldn't running them in pre-push make more sense? Syntax error checks and other quick operations could still be ran in pre-commit, but I personally move everything into pre-push, because I can always alter the history until I push my changes.

Vagrant box static IP doesn't work if it ends in ".1"

The vagrantfile generates a private.ip file on install, with a random static IP address. I just happened to get an IP which ended in .1 and on boot Vagrant warns in the console:

==> wordpress-box: You assigned a static IP ending in ".1" to this machine.
==> wordpress-box: This is very often used by the router and can cause the
==> wordpress-box: network to not work properly. If the network doesn't work
==> wordpress-box: properly, try changing this IP.

Indeed, I couldn't connect to the WP install from the browser. Deleting the private.ip file and rebooting the box fixed the problem.

This is an edge case really, but perhaps the random IP generator should make a reroll if the IP ends .1?

RSpec tests: PhantomJS client died

Any idea why PhantomJS keeps crashing during some rspec-tests?

For example wp-admin login test (after 9 successful tests with same kind of login tests):

describe "Login to wp-admin and test checkout-page link" do
      before do
        visit WP.siteurl('/wp-admin')
      end

      it "Log in to WordPress wp-admin" do
        within("#loginform") do
          fill_in 'log', :with => SOMELOGIN
          fill_in 'pwd', :with => SOMEPASS
        end
        click_button 'wp-submit'
        expect(page).to have_id "wp-admin-bar-pro-site"
      end
    end

And error:

Failure/Error: click_button 'wp-submit'

     Capybara::Poltergeist::DeadClient:
       PhantomJS client died while processing {"id":"796d6ac1-3767-482d-b797-ac959407cb0e","name":"click","args":[2,3]}
     # /var/lib/gems/2.2.0/gems/poltergeist-1.9.0/lib/capybara/poltergeist/server.rb:38:in `send'
     # /var/lib/gems/2.2.0/gems/poltergeist-1.9.0/lib/capybara/poltergeist/browser.rb:344:in `command'
     # /var/lib/gems/2.2.0/gems/poltergeist-1.9.0/lib/capybara/poltergeist/browser.rb:180:in `click'
     # /var/lib/gems/2.2.0/gems/poltergeist-1.9.0/lib/capybara/poltergeist/node.rb:17:in `command'
     # /var/lib/gems/2.2.0/gems/poltergeist-1.9.0/lib/capybara/poltergeist/node.rb:131:in `click'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/node/element.rb:134:in `block in click'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/node/base.rb:84:in `synchronize'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/node/element.rb:134:in `click'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/node/actions.rb:39:in `click_button'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/session.rb:686:in `block (2 levels) in <class:Session>'
     # /var/lib/gems/2.2.0/gems/capybara-2.6.2/lib/capybara/dsl.rb:51:in `block (2 levels) in <module:DSL>'
     # ./tests/rspec/merge-dev_site_onboarding_tests.rb:294:in `block (4 levels) in <top (required)>'
     # /var/lib/gems/2.2.0/gems/rspec-retry-0.4.5/lib/rspec/retry.rb:98:in `block in run'
     # /var/lib/gems/2.2.0/gems/rspec-retry-0.4.5/lib/rspec/retry.rb:88:in `loop'
     # /var/lib/gems/2.2.0/gems/rspec-retry-0.4.5/lib/rspec/retry.rb:88:in `run'
     # /var/lib/gems/2.2.0/gems/rspec-retry-0.4.5/lib/rspec_ext/rspec_ext.rb:12:in `run_with_retry'
     # /var/lib/gems/2.2.0/gems/rspec-retry-0.4.5/lib/rspec/retry.rb:22:in `block (2 levels) in setup'

I get same error also with tests like these:

describe 'Kaanon site tests' do

    before do
     visit WP.siteurl("/kaanon")
    end

    it "There's 'Kaanon | Pitkän tekstin ystävälle'-title" do
      expect(page.status_code).to be(200)
      expect(page).to have_title 'Kaanon | Pitkän tekstin ystävälle'
    end

 end

And error:

Failure/Error: visit WP.siteurl("/kaanon")

     Capybara::Poltergeist::DeadClient:
       PhantomJS client died while processing {"id":"9cd02d81-7812-4151-8108-f26e20ff9a16","name":"visit","args":["http://kehittamo.dev/kaanon",60]}
...

Support drop-ins for this repository

Using a drop-in Composer package seems to be the most convenient way of customizing Vagrant and the files in this repository. See Vincit/wordpress and kehittamo/kehittamo-seravo-addons for examples.

However, that currently requires manual modification of composer.json.

"dropin-paths": {
      "htdocs/wp-content/languages/": ["vendor:koodimonni-language"],
      "htdocs/wp-content/languages/plugins/": ["vendor:koodimonni-plugin-language"],
      "htdocs/wp-content/languages/themes/": ["vendor:koodimonni-theme-language"]
  },

=>

"dropin-paths": {
      "htdocs/wp-content/languages/": ["vendor:koodimonni-language"],
      "htdocs/wp-content/languages/plugins/": ["vendor:koodimonni-plugin-language"],
      "htdocs/wp-content/languages/themes/": ["vendor:koodimonni-theme-language"],
      ".": ["type:seravo-wordpress-dropin"]
  },

Then we can just clone this repository and run composer require vendor/customizations --dev to include our customizations. The package type is simply "seravo-wordpress-dropin".

#62 is related to this in a way.

I'll gladly send a PR (:grin:) but I think you might have something to say on the name part. So what should we call "seravo-wordpress-dropin"?

How to achieve high performance in WordPress?

Item Tool Speedup
Infrastructure CPU, disk, web server, PHP and DNS Overall performance
In-memory object cache Redis, Memcached, APCu options, post, post meta etc.
Server-side functionality plugins
(backup, db cleanup)
Use WP-CLI instead Degrades performance
Theme and plugins Cache-aware ones using object cache or transients
Translations tiny-translation-cache .mo file parsing
Navigation menus tiny-nav-menu-cache wp_nav_menu()
Post content tiny-cache the_content()
Widgets widget-output-cache plugin dynamic_sidebar()

You run already on UpCloud - which is the best cheap enterprise-grade provider - and using Redis.
https://github.com/szepeviktor/wordpress-speedtest

Please consider testing the Tiny cache family: https://github.com/szepeviktor/tiny-cache

Deployment instructions

Please extend the deployment documentation in the README file. There is some discussion about deployment strategies, but what we really need is idiot-proof copy-pasteable deployment commands so that anybody who has this Vagrant running and knows the ssh/sftp credentials to a WP-palvelu.fi instance can run a deploy.

Two packages cannot share the same directory! (location of @johnpbloch/wordpress changed March 18th, 2017)

Users running composer update in existing (old) projects are seeing this error message:
screenshot from 2017-03-23 13 46 03

This is because a rename done in https://github.com/johnpbloch/wordpress

The solution is to update composer.json to include johnpbloch/wordpress-core instead of johnpbloch/wordpress and then running composer update twice. The first run will delete WordPress core files and the second will re-install them. Your plugins, uploads etc remain unaffected.

The issue does not affect new installs done after commit 9326c6c

Do not close this bug report, but keep it open as information for all users who might bump into this bug with their existing projects.*

http://localhost is hard-coded in test.rb

After setting a custom url in config.yml and doing a git commit, the tests fail, even though the command line output suggests that the tests are being run with the correct url. The culprit seems to be on lines 90 and 108 of test.rb:

On line 90:
visit 'http://localhost/'

On line 108:
visit "http://localhost/wp-login.php"

Custom provisioning script

Currently it seems that there's no way to run custom provisioning scripts (adding features such as local backups, maybe changing some settings etc) without modifying Vagrantfile directly.

I'm proposing a new feature to the Vagrantfile: check if a custom provisioning script (customize_vagrant.sh?) exists in the directory, and if it does, run it.

It should be fairly straightforward, add a few lines, including something like this
config.vm.provision "shell", path: "customize_vagrant.sh"
to this block of code.

Trusting self-signed cert command fails on macOS if there are spaces in the filepath

Spaces in the ssl_cert_path variable are not escaped when passed to the sudo security add-trusted-cert ... command in Vagrantfile on line 175. As a result the command fails.

Whether it's a good idea to have spaces in directory names is another discussion, but this should be simple to fix: escape spaces with a backslash, e.g. /Local Sites --> /Local\ Sites

Enable WP_DEBUG by default in Vagrant

WP_DEBUG isn't on by default in Vagrant. Shouldn't it?

This is what I typically add to wp-config:

define('WP_ENV', getenv('WP_ENV') ?? 'production');

if (WP_ENV === 'development') {
  define('WP_DEBUG', true);
  define('WP_DEBUG_DISPLAY', true);
  define('SCRIPT_DEBUG', true);
} else {
  define('WP_DEBUG', false);
  define('WP_DEBUG_DISPLAY', false);
  define('SCRIPT_DEBUG', false);
}

Since $WP_ENV inside Vagrant is set to development by default, this should work out of the box.

Precompiled box not found

Hi there. This is what I get when trying to run vagrant up:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'seravo/wordpress' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Loading metadata for box 'seravo/wordpress'
    default: URL: https://vagrantcloud.com/seravo/wordpress
==> default: Adding box 'seravo/wordpress' (v0.8.3) for provider: virtualbox
    default: Downloading: https://vagrantcloud.com/seravo/boxes/wordpress/versions/0.8.3/providers/virtualbox.box
An error occurred while downloading the remote file. The error
message, if any, is reproduced below. Please fix this error and try
again.

The requested URL returned error: 404 Not Found

And then it exits. Is the box online?

Too many plugins!

If this is meant to be a general purpose WordPress stack, it's unreasonable to ask the user to install all the plugins listed right now in the composer.json

No finnish locales in vagrant

Running

setlocale(LC_TIME, "fi_FI");
echo strftime(" in Finnish is %A,");

in the vagrant machine fails, it simply prints the english version. This is due to the fi_FI locale missing:

vagrant@box:/data/log$ locale -a
C
C.UTF-8
en_AG
en_AG.utf8
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_IN.utf8
en_NG
en_NG.utf8
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZM
en_ZM.utf8
en_ZW.utf8
POSIX

Fix:

sudo locale-gen fi_FI
sudo locale-gen fi_FI.UTF-8
sudo update-locale
sudo service php7-fpm restart

Funny directory permissions

While browsing inside the image (with 'vagrant ssh') I noticed that most of the file permissions in /data look weird:

vagrant@wordpress-wp-dev:/data/wordpress$ ll
total 112
drwxrwxrw- 1 vagrant vagrant  4096 May 26 18:39 ./
drwxr-sr-x 7 vagrant vagrant  4096 May 13 13:47 ../
drwxrwxrw- 1 vagrant vagrant  4096 May 26 18:39 .git/
-rwxrwxr-x 1 vagrant vagrant  1367 May 26 09:42 .gitignore*
-rwxrwxr-x 1 vagrant vagrant   127 May 18 13:08 .gitmodules*
drwxrwxrw- 1 vagrant vagrant  4096 May 26 11:01 .vagrant/
-rwxrwxr-x 1 vagrant vagrant  1048 May 18 13:08 LICENSE.md*
-rwxrwxr-x 1 vagrant vagrant  4199 May 26 11:20 README.md*
-rwxrwxr-x 1 vagrant vagrant  8319 May 18 13:08 Vagrantfile*
-rwxrwxr-x 1 vagrant vagrant  2448 May 23 14:16 composer.json*
-rwxrwxr-x 1 vagrant vagrant 25671 May 23 14:16 composer.lock*
-rwxrwxr-x 1 vagrant vagrant   436 May 19 19:21 config-sample.yml*
-rwxrwxr-x 1 vagrant vagrant   409 May 26 10:42 config.yml*
-rwxrwxr-x 1 vagrant vagrant  1754 May 18 13:08 gulpfile.js*
drwxrwxrw- 1 vagrant vagrant  4096 May 26 18:35 htdocs/
drwxrwxrw- 1 vagrant vagrant  4096 May 18 13:08 nginx/
drwxrwxrw- 1 vagrant vagrant  4096 May 18 07:46 scripts/
drwxrwxrw- 1 vagrant vagrant  4096 May 18 07:46 tests/
drwxrwxrw- 1 vagrant vagrant  4096 May 26 11:01 vendor/

What and where are these permissions set anyway? On the host computer the actual file permissions are fine and not like above.

Prompt to use object cache instead of turning it on by default

Story: I started a new project on friday, and today when I came to work, Vagrant wouldn't start normally. I ran vagrant destroy followed by a vagrant up and got it back up and running. For whatever reason, I didn't have a shutdown dump, so I was presented with the default display of Twenty Sixteen. Luckily I store additional backups of the development database, so I restored last known good backup:

wp db reset
wp db import local_database_backups/1480886101.sql

This didn't seem to work, I was still stuck looking at the default theme and of my data was "missing", so I ran wp db reset again to nuke the database, and to my surprise, /wp-admin continued working normally.

I went to confirm that the database is indeed empty:

vagrant@wordpress:~$ wp db cli
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 124
Server version: 10.1.19-MariaDB-1~trusty mariadb.org binary distribution

Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [vagrant]> show tables;
Empty set (0.00 sec)

MariaDB [vagrant]> Ctrl-C -- exit!

I finally figured out that this was happening due to object cache, and after running sudo service redis-server restart I was presented with the lovely "install WordPress" screen and I was able to successfully import the backup database and get back to work.

I as an user didn't know that I was using object cache, because it wasn't on by default last time. This should be made more clear to the user, and clearing the object cache should be easier. It's fairly easy in production but on development not so much.

Suggestion: add an additional prompt to first vagrant up, asking if the user would like to enable object cache, and add a wp-purge-cache command to the local environment. That would allow users to easily get rid of any remnants left by a previous installation.

Log files are not writable or readable

Running the latest version of this repository and Vagrant box, log files are not readable by vagrant-user, or writable by PHP.

I added

error_reporting(-1); 
throw new Exception('FATALITY');

to the default theme, which naturally killed the site. Commence debugging:

vagrant@wordpress:~$ tail -f /data/log/php-error.log
tail: cannot open ‘/data/log/php-error.log’ for reading: Permission denied

The log file is also empty:

vagrant@wordpress:~$ sudo cat /data/log/php-error.log
vagrant@wordpress:~$

Further inspection points to the cause:

vagrant@wordpress:~$ ls -lah /data/log/
total 16K
drwxrwsrwx 2 vagrant vagrant 4.0K Mar  9 13:45 .
drwxr-sr-x 7 vagrant vagrant 4.0K Feb  1 15:23 ..
-rw-r--r-- 1 root    vagrant    0 Feb  1 16:47 error.log
-rw-r--r-- 1 root    vagrant    0 Feb  1 16:47 nginx-access.log
-rw-r--r-- 1 root    vagrant    0 Mar  9 13:45 nginx-error.log
-rw------- 1 root    vagrant    0 Feb  1 16:46 php-error.log
-rw-rw---- 1 redis   vagrant 6.1K Mar  9 13:45 redis.log

Running sudo chown -R vagrant:vagrant /data/log/ will fix this.

After:

vagrant@wordpress:~$ sudo cat /data/log/php-error.log
[09-Mar-2017 13:56:35 UTC] PHP Fatal error:  Uncaught Exception: FATALITY in /data/wordpress/htdocs/wp-content/themes/twentysixteen/functions.php:36
Stack trace:
#0 /data/wordpress/htdocs/wordpress/wp-settings.php(425): include()
#1 /data/wordpress/htdocs/wp-config.php(123): require_once('/data/wordpress...')
#2 /data/wordpress/htdocs/wordpress/wp-load.php(42): require_once('/data/wordpress...')
#3 /data/wordpress/htdocs/wordpress/wp-blog-header.php(13): require_once('/data/wordpress...')
#4 /data/wordpress/htdocs/index.php(6): require('/data/wordpress...')
#5 {main}
  thrown in /data/wordpress/htdocs/wp-content/themes/twentysixteen/functions.php on line 36

Version 2.x of phpdotenv

We're currently using version 1.0.9 of phpdotenv. The new version has apparently changed its API slightly.

The trouble with this is that because composer libs are global, and some plugins using the composer autoloader might want to use a different version of dotenv, which wont work between 1.x and 2.x.

We should maybe start supporting the 2.x version of phpdotenv, if it turns out lots of plugins are using the newest version.

Subsite URL not accessible from inside vagrant box

I was trying to write tests for a fairly complex multisite installation. As @ottok suggested to me, I could use wp-cli commands within the test script to get the correct URL for a specific subsite ID. This works, but then I discovered the subsites URL's are not accessible from within the vagrant box. Is there a trick to this or have I discovered a bug?

Cannot halt the vagrant VM

You have to SSH in to the box to be able to shut down the VM.

$ vagrant halt --force
==> default: Running triggers before halt...
==> trigger: dumping the database into: .vagrant/vagrant-dump.sql
==> default: Executing command "wp core is-installed && wp db export /data/wordpress/.vagrant/vagrant-dump.sql"...
==> default: Error: This does not seem to be a WordPress install.
==> default: Pass --path='path/to/wordpress' or run 'wp core download'.
==> default: Command execution finished.
The command "wp core is-installed && wp db export /data/wordpress/.vagrant/vagrant-dump.sql" returned a failed exit code. The
error output is shown below:

Error: This does not seem to be a WordPress install.
Pass --path='path/to/wordpress' or run 'wp core download'.

$ vagrant status
Current machine states:

default                   running (virtualbox)

The VM is running. To stop this VM, you can run 'vagrant halt' to
shut it down forcefully, or you can run 'vagrant suspend' to simply
suspend the virtual machine. In either case, to restart it again,
simply run 'vagrant up'.

Composer install/update fails on leftover Akismet files (after Akismet new release in May 2017)

Many users have reported the running composer install or composer update failed with an error message like:

  - Installing koodimonni-plugin-language/woocommerce-sv_se (3.0.7): Downloading (100%)         
  - Installing koodimonni-plugin-language/bbpress-sv_se (2.5.12): Downloading (100%)         
  - Installing koodimonni-plugin-language/akismet-sv_se (3.3.2): Downloading (100%)         
  - Installing koodimonni-language/sv_se (4.7.5): Downloading (100%)         
  - Installing seravo/seravo-plugin (1.5.1): Downloading (100%)         
  - Installing wpackagist-plugin/auto-post-thumbnail (3.4.1): Downloading (100%)         
  - Installing wpackagist-plugin/google-analytics-dashboard-for-wp (5.0): Downloading (100%)         
  - Installing wpackagist-plugin/wp-native-dashboard (1.3.12): Downloading (100%)         
  - Installing wpackagist-theme/twentysixteen (1.3): Downloading (100%)         
  - Installing wpackagist-theme/twentyfifteen (1.7): Downloading (100%)         
Writing lock file
Generating autoload files
> WordPress\Installer::symlinkWPContent
Script WordPress\Installer::symlinkWPContent handling the post-update-cmd event terminated with an exception

                                                                                           
  [ErrorException]                                                                         
  rmdir(/data/wordpress/htdocs/wordpress/wp-content/plugins/akismet): Directory not empty  
                                                                                           

install [--prefer-source] [--prefer-dist] [--dry-run] [--dev] [--no-dev] [--no-custom-installers] [--no-autoloader] [--no-scripts] [--no-progress] [--no-suggest] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--ignore-platform-reqs] [--] [<packages>]...

Indeed, a directory for akismet exists:

$ ll /data/wordpress/htdocs/wordpress/wp-content/plugins/akismet
total 20
drwxrwxrw- 1 vagrant vagrant 4096 touko 22 19:17 ./
drwxrwxrw- 1 vagrant vagrant 4096 touko 22 19:15 ../
-rwxrwxr-x 1 vagrant vagrant  629 touko 22 19:15 .htaccess*

The workaround is to simply delete it manually: rm -rf /data/wordpress/htdocs/wordpress/wp-content/plugins/akismet

Missing directory for shutdown-dump.sql

I updated the vagrant box to newest version and now the shutdown dump (or startup import) doesn't seem to work.

I get the following message:

==> my-awesome-wp-box: Running triggers before halt...
==> trigger: dumping the database into: .vagrant/shutdown-dump.sql
==> my-awesome-wp-box: Executing remote command "wp-vagrant-dump-db"...
==> my-awesome-wp-box: /usr/local/bin/wp-vagrant-dump-db: line 16: /.vagrant/shutdown-dump.sql: No such file or directory
==> my-awesome-wp-box: Error: Database couldn't be dump :( 

Perhaps the $WP_PROJECT variable in /usr/local/bin/wp-vagrant-dump-db doesn't get set correctly? How do I fix this in an existing project?

$WP_ENV is not set by default in Vagrant

Running echo $WP_ENV; on a production instance of wp-palvelu.fi prints production, but on a fresh Vagrant instance it prints nothing.

Since it's Vagrant, wouldn't a sane default be development?

wp-use-asset-proxy sometimes fails

For whatever reason, the asset proxy doesn't always work, and I end up with 404s on my local setup. I suspect it might have something to do with relative urls, because this fails to load:

<img src="/wp-content/uploads/2017/03/[email protected]">

That image is coming from an ACF image field with a return type set to object, and it only has root relative urls in it. Assuming the issue is caused by relative urls, any status on #47? Can we disable them on existing installs without breaking everything?

To work around this issue, I simply synced those missing media files using rsync. I was sure that there used to be a wp-pull-production-assets installed on the Vagrant box, but apparently no such thing exists.

The self-signed cert stopped working

Earlier today I was able to browse the https://wordpress.dev/wp-admin/ site fine via the self-signed certificate. Now when I reloaded the Vargrant image however https stopped working. See curl output for a somewhat verbose output (Chromium is not even this verbose):

 curl -L -i https://wordpress.dev/wp-admin -vvvv
* About to connect() to wordpress.dev port 443 (#0)
*   Trying 192.168.236.127... connected
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to wordpress.dev:443 
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to wordpress.dev:443

vagrant up/reload just keeps adding new entries to /etc/hosts

Hello!

Every time I run 'vagrant up' or 'vagrant reload' or similar commands, the IP address of the Vagrant box changes (in fact a new Virtualbox network interface is created every time). My /etc/hosts gets populated with ever new lines. As only the first line matches, it means that in effect my browser never finds the Vagrant server unless I manually keep cleaning up the /etc/hosts file over and over again.

This is extremely annoying an probably impossible to debug to those who don't know where to look.

Stop using relative URLs by default

We often disable from wp-config.php the line:
define('WP_CONTENT_URL', CONTENT_DIR);

Many plugins don't work well with it, including big and famous ones like WooCommerce digital downloads. We should stop using relative urls here as we don't need much relative urls anymore for the same reasons https-domain-alias is no longer needed on normal single install sites.

Pulling production database on first vagrant up fails

I've the following config.yml:

###
# Configuration for Vagrant
###
name: redacted
production:
  # This is used to automatically fetch data from a staging/production environment
  domain: redacted.seravo.fi
  ssh_port: 10350
  url: https://redacted.seravo.fi
development:
  # Domains are automatically mapped to Vagrant with /etc/hosts modifications
  domains:
    - redacted.local
  # If you want to use zeroconf (.local domains) in your network you can use this.
  #avahi: true

After cloning the project or destroying the Vagrant machine, trying to pull database from production results in failure, with this output:

Bringing machine 'redacted-box' up with 'virtualbox' provider...
==> redacted-box: Importing base box 'seravo/wordpress'...
==> redacted-box: Matching MAC address for NAT networking...
==> redacted-box: Checking if box 'seravo/wordpress' is up to date...
==> redacted-box: Setting the name of the VM: redacted_redacted-box_1493710778163_61855
==> redacted-box: Fixed port collision for 22 => 2222. Now on port 2202.
==> redacted-box: Clearing any previously set network interfaces...
==> redacted-box: Preparing network interfaces based on configuration...
    redacted-box: Adapter 1: nat
    redacted-box: Adapter 2: hostonly
==> redacted-box: Forwarding ports...
    redacted-box: 22 (guest) => 2202 (host) (adapter 1)
==> redacted-box: Running 'pre-boot' VM customizations...
==> redacted-box: Booting VM...
==> redacted-box: Waiting for machine to boot. This may take a few minutes...
    redacted-box: SSH address: 127.0.0.1:2202
    redacted-box: SSH username: vagrant
    redacted-box: SSH auth method: private key
==> redacted-box: Machine booted and ready!
==> redacted-box: Checking for guest additions in VM...
    redacted-box: The guest additions on this VM do not match the installed version of
    redacted-box: VirtualBox! In most cases this is fine, but in rare cases it can
    redacted-box: prevent things such as shared folders from working properly. If you see
    redacted-box: shared folder errors, please make sure the guest additions within the
    redacted-box: virtual machine match the version of VirtualBox you have installed on
    redacted-box: your host and reload your VM.
    redacted-box:
    redacted-box: Guest Additions Version: 4.3.36
    redacted-box: VirtualBox Version: 5.1
==> redacted-box: [vagrant-hostsupdater] Checking for host entries
==> redacted-box: [vagrant-hostsupdater] Writing the following entries to (/etc/hosts)
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  redacted  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  www.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  webgrind.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  adminer.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  mailcatcher.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  browsersync.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater]   192.168.53.210  info.redacted.local  # VAGRANT: dee86b3e07d41f5276d7b6dee0420ef8 (redacted-box) / 76259e76-17e9-4eef-863d-80a2ea3cbef2
==> redacted-box: [vagrant-hostsupdater] This operation requires administrative access. You may skip it by manually adding equivalent entries to the hosts file.
==> redacted-box: Setting hostname...
==> redacted-box: Configuring and enabling network interfaces...
==> redacted-box: Mounting shared folders...
    redacted-box: /data/wordpress => /Users/k1sul1/Projects/wordpress-sites/redacted
==> redacted-box: Running provisioner: shell...
    redacted-box: Running: inline script
==> redacted-box: Running provisioner: shell...
    redacted-box: Running: inline script
==> redacted-box:  * Restarting nginx nginx
==> redacted-box:    ...done.
==> redacted-box: avahi-daemon stop/waiting
==> redacted-box: avahi-daemon start/running, process 2223
==> redacted-box: Setting custom domains in /etc/hosts/...
==> redacted-box: Generating ssh configs...
==> redacted-box: Running provisioner: shell...
    redacted-box: Running: /var/folders/k0/lsmj8qqj5hg81b8kzvm_stym0000gn/T/vagrant-shell20170502-5395-1hw792b.sh
==> redacted-box: no crontab for root
==> redacted-box: Running triggers after up...
checking for composer... yes
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating autoload files
> WordPress\Installer::symlinkWPContent
    redacted-box: Pull database from production? (no): y
==> redacted-box: Executing remote command "wp core install --url=https://redacted.local --title=Redacted         [email protected] --admin_user=vagrant --admin_password=vagrant"...
==> redacted-box:
==> redacted-box:
==> redacted-box: Success: WordPress installed successfully.
==> redacted-box: Remote command execution finished.
==> redacted-box: Executing remote command "wp-pull-production-db"...
==> redacted-box:
==> redacted-box:
==> redacted-box: Saving backup of current development database in /data/db/pre-production-pull-backup.sql...
==> redacted-box: Success: Exported to 'pre-production-pull-backup-1493710805.sql'.
==> redacted-box: Define new and old siteurl for later search-replacing...
==> redacted-box: /usr/lib/ruby/vendor_ruby/highline.rb:862:in `get_line'
==> redacted-box: :
==> redacted-box: The input stream is exhausted.
==> redacted-box:  (
==> redacted-box: EOFError
==> redacted-box: )
==> redacted-box: 	from /usr/lib/ruby/vendor_ruby/highline.rb:885:in `get_response'
==> redacted-box: 	from /usr/lib/ruby/vendor_ruby/highline.rb:260:in `ask'
==> redacted-box: 	from /usr/lib/ruby/vendor_ruby/highline.rb:223:in `agree'
==> redacted-box: 	from /usr/local/bin/wp-pull-production-db:48:in `<main>'
==> redacted-box: ==> Production site URL:
==> redacted-box: ==> Development site URL: https://redacted.local
==> redacted-box: ==> This is a normal WordPress single install.
==> redacted-box: Is the information above correct (yes/no)?
==> redacted-box: Please enter "yes" or "no".
==> redacted-box: Is the information above correct (yes/no)?
==> redacted-box: Remote command execution finished.
The remote command "wp-pull-production-db" returned a failed exit
code or an exception. The error output is shown below:

/usr/lib/ruby/vendor_ruby/highline.rb:862:in `get_line': The input stream is exhausted. (EOFError)
	from /usr/lib/ruby/vendor_ruby/highline.rb:885:in `get_response'
	from /usr/lib/ruby/vendor_ruby/highline.rb:260:in `ask'
	from /usr/lib/ruby/vendor_ruby/highline.rb:223:in `agree'

If I don't pull the database, I can just vagrant ssh into the machine, and run wp-pull-production-db without issues.

PHP7 by default?

Should we enable php7 by default in this repo configuration? This would take effect for both vagrant and wp-palvelu environments.

I feel like php7 is starting to be stable enough to be the default for all new projects.

The user can always fall back easily to 5.6, or just use HHVM if they wish using our nginx custom.conf.

https://docs.wp-palvelu.fi/configuration/php7-hhvm/

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.