I've got a wordpress site working by disabling the multisite feature.

Previously it showed an infinite redirect loop with http://wpadmin.[mydomain]/wp-signup.php?new=wpadmin.[mydomain] redirecting to itself.

re-enabling multisite in puppet breaks the site again, and disabling it again fixes it (once puppet runs of course.)

Any suggestions?

I'm new to wordpress - probably doing something that seems silly to someone in the know.

Hello,

I'm trying to put two wordpress on the same node, but I have problems with a redeclaration:
Error 400 on SERVER: Duplicate declaration: Class[Wordpress] is already declared in file

I'm just starting with puppet and I don't know if is a module problem or I can't find the correct configuration.

Is the module can be used it to more than one site?

Thank you

The documentation on installing the database on a different server is light. My impression is that it's only intended that this module supports the web machine, not that it also run on the db machine?

I've been looking in class wordpress::db (I realise that's not documented in README.md, so perhaps I should not consider it to be part of the external API?)

wordpress::db is simple enough, so I thought I'd just call it on the db server, but then I realised that the way 'db_host' is used for the mysql_user and mysql_grant resources, it actually refers to the IP of the client system, not the host that the db is on. That surprised me, but by providing the name of the web host there, it looks like it would still work. However, the module 'require's wordpress::app, which clearly means it can't be used on the db host in it's current form.

It appears that I'm looking beyond the usage that's been contemplated to date, so consider this a feature request.

Database and user creation works well when root password is not set, but i don't see how to make it work when root password is not empty.

PR #63 made the sensible change of defaulting to mode 0640. Unfortunately, now that means that out of the box on most distros this will no longer work, as the webserver user is not root.

This should either be reverted, or (better) the module should be updated with a params class to figure out a better owner.

Can we move this to voxpopuli so we can get some of these PRs merged and issues closed?

instance app has

Configure wordpress

concat { "${install_dir}/wp-config.php":
owner => $wp_owner,
group => $wp_group,
mode => '0755',
require => Exec["Extract wordpress ${install_dir}"],
}

I don't understand why mode 0755 was choosen rather than 0644 (or even 0640 with group being www-data/httpd/apache)

I use W3 Total Cache and the key that this plugin inserts in wp-config.php get overwritten by puppet.

Any workaround?

EDIT: I ended up using parameter wp_additional_config

this module uses wget to download the software from http://wordpress.org/, but Now the site redirect to ssl version url https://wordpress.org/ and wget needs --no-check-certificate in ./manifests/instance/app.pp +68

This dependency is causing puppet to fail:

dependency 'puppetlabs/concat', '>= 1.0.0'

==> default: Error executing puppet module install. Check that this command succeeds:
==> default: puppet module install --version 2.0.1 --target-dir /etc/puppet/.tmp/librarian/cache/source/puppet/forge/forgeapi_puppetlabs_com/puppetlabs-concat/2.0.1 --module_repository https://forgeapi.puppetlabs.com --modulepath /etc/puppet/.tmp/librarian/cache/source/puppet/forge/forgeapi_puppetlabs_com/puppetlabs-concat/2.0.1 --module_working_dir /etc/puppet/.tmp/librarian/cache/source/puppet/forge/forgeapi_puppetlabs_com/puppetlabs-concat/2.0.1 --ignore-dependencies puppetlabs-concat
==> default: Error:
==> default: Warning: Setting templatedir is deprecated. See http://links.puppetlabs.com/env-settings-deprecations
==> default:    (at /usr/lib/ruby/vendor_ruby/puppet/settings.rb:1139:in `issue_deprecation_warning')
==> default: Error: Could not install 'puppetlabs-concat' (v2.0.1)
==> default:   No releases matching '2.0.1' are available from https://forgeapi.puppetlabs.com

The problem is that puppetlabs-concat reverted to a 1.x.x build and deleted the 2.x.x builds, but pulling from the forge still tries to grab the 2.0.1 build.

Multisite support is incomplete as it only supports the subdomain based multisite configuration and not the subdirectory based configuration. There's already a pull request put in by someone else for this:

#60

Hi,
I notice that when I have an existing wordpress deployment, and I want to use the wordpress module to downgrade the deployment, that it does not work. It looks like downloads the specified version, but does not extract the zip file. It looks like this is due to the extract having a creates parameter that prevents extraction of the ${install_dir}/index.php file exists.

I can delete this file in an earlier provisioning step (using shell) but I am wondering if there is better way to achieve this.

Thanks,
John Schank

Change classes as defined types so we can have multiple wordpress instances on same node

That would be great :)

The permissions set up by this module work fine if everything is owned and edited by the user and group of the web server process. That's typical for many shared web hosts, but I wouldn't have thought that's where puppet would be used.

On our server we have group based access for editing (requiring chmod g+w, and directories chmod g+s). we make appropriate directories group owned by www-data, and editors are also in that group. Of course other permissions modules are also likely.

Is it within the likely scope of this module to cater to alternative permissions modules, or should I be looking at forking the module?

I'm also concerned by puppet checking permissions on every run. This is a slow operation. Perhaps this should only happen on the initial installation. Besides running faster, that would also make the module more flexible for subsequently modifying the permissions scheme.

With automatic parameter lookup you don't need to create a puppet recipe to install wordpress using this module any longer, because if you add the required parameters to hiera, the agent will launch the class with the values loaded from hiera.

But in this scenario, you cannot use the wp_additional_config parameter as you don't have a module with the template, so if you need to add additional config to wordpress, you have to write your recipe.

In this situation, a new parameter called wp_additional_inline_config would be helpful, so you could avoid writting the recipe, loading the additional config into hiera.

Related: #24

on a 2 instance install in AWS, (db/web) when using
db_host => 'my_remote_db',
create_db => true,
create_db_user => true,
Puppet will fail, as regardless of the $dbhost parameter will still try to connect locally.

Workaround:

Create the DB in the db manifest first using the mysql puppet module
mysql::db {'wordpress':
user => 'wordpress',
password => 'mypass',
host => 'wphost',
ensure => 'present',
require => File['/root/.my.cnf'],
}

You must also then use Vagrant Hostmaster plugin to update hoses file so web and db can communicate.

I never found the RC of why the db_host was ignored, but having read through the code, and the documentation being somewhat 'light' on this subject, i opted to workaround the issue.

I download de module and when i try to exec "sudo puppet agent --test" i get the following error:
Expected parameter 'path' of 'Concat[/opt/wordpress/wp-config.php' to have type stdlib::Absolutepath, got String at /etc/puppet/modules/wordpress/manifests/instance/app.pp:94

Thanks

Hi, I use the module with default everything to install wordpress. Just for demonstration. But I meet that error. Besides, the errors display:

Error: Could not find a suitable provider for mysql_user
Error: Could not find a suitable provider for mysql_database

Could you help me to verify it ?

Hi All,

I've been using Puppet for a little while now and came across this which (I believe) seems to be related to this module. Maybe it's just the way I've set things up, so perhaps someone can point out some areas for improvement. I've put together a quick little class that looks like the following:
class my_wp {
package { 'php':
ensure => latest,
}
class { 'wordpress':
install_dir => '/var/www/html/wordpress',
require => [ Package['php'], Class['::mysql::server'] ],
}

include mysql::server
class { '::mysql::bindings':
php_enable => true,
}

class { 'apache':
mpm_module => 'prefork',
}
include apache::mod::php
apache::vhost { 'localhost':
port => '80',
docroot => '/var/www/html/wordpress',
}
}

Now, the instance seems to come up just fine. I'm able to create the administrator account, etc. I'm even able to post. HOWEVER, when I get to the part where I need to add a picture or attachment, i get the following error:

I get that it may be due to the default root user installation method, but should this be resolved in this module? Or am I doing something wrong?

wp_lang parameter is checked on string value and default value is "".
But puppet 4 uses new parser which resolve
if ${wp_lant} as true with default value.

Following fix resolve the problem:
manifests/instance/app.pp:
67:- if $wp_lang {
67:+ if $wp_lang and $wp_lang != '' {

Now that wordpress 4.0 is out i've a new issue, caused by an incorrect certificate at wordpress.org

Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: --2014-09-22 13:11:40-- http://wordpress.org/wordpress-4.0.tar.gz
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Resolving wordpress.org... 66.155.40.249, 66.155.40.250
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Connecting to wordpress.org|66.155.40.249|:80... connected.
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: HTTP request sent, awaiting response... 302 Moved Temporarily
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Location: https://wordpress.org/wordpress-4.0.tar.gz [following]
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: --2014-09-22 13:11:40-- https://wordpress.org/wordpress-4.0.tar.gz
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: Connecting to wordpress.org|66.155.40.249|:443... connected.
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: ERROR: certificate common name "*.wordpress.org" doesn't match requested host name "wordpress.org".
Notice: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: To connect to wordpress.org insecurely, use '--no-check-certificate'.
Error: wget http://wordpress.org/wordpress-4.0.tar.gz returned 5 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Exec[Download wordpress]/returns: change from notrun to 0 failed: wget http://wordpress.org/wordpress-4.0.tar.gz returned 5 instead of one of [0]
Notice: /Stage[main]/Wordpress::App/Exec[Extract wordpress]: Dependency Exec[Download wordpress] has failures: true

Althougth it's not a puppet error (it's a wordpress.org configuration error which should be solved) this could be easily avoided adding '--no-check-certificate' to the wget call (in app.pp):

command => "wget --no-check-certificate ${install_url}/wordpress-${version}.tar.gz",

At our site we traditionally install Wordpress from an RPM, packaged in the EPEL repo. Would it be possible to allow your module to handle this?

Basically I think it would just need a parameter to tell your module simply to use a package{} resource in Puppet instead of grabbing the tarball from the web and untarring it.

Cheers,
Jonathan

I'm new to puppet and I get this error trying to install it

Notice: /Stage[main]/Wordpress::App/Concat[/var/www/wordpress/wp-config.php]/Exec[concat_/var/www/wordpress/wp-config.php]/returns: sh: 1: /var/lib/puppet/concat/bin/concatfragments.sh: Permission denied
Error: /var/lib/puppet/concat/bin/concatfragments.sh -o "/var/lib/puppet/concat/_var_www_wordpress_wp-config.php/fragments.concat.out" -d "/var/lib/puppet/concat/_var_www_wordpress_wp-config.php" returned 126 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/wordpress/wp-config.php]/Exec[concat_/var/www/wordpress/wp-config.php]/returns: change from notrun to 0 failed: /var/lib/puppet/concat/bin/concatfragments.sh -o "/var/lib/puppet/concat/_var_www_wordpress_wp-config.php/fragments.concat.out" -d "/var/lib/puppet/concat/_var_www_wordpress_wp-config.php" returned 126 instead of one of [0]

here my puppet file

user { 'wordpress':
  ensure           => 'present',
  groups           => ['www-data'],
  home             => '/home/wp',

  # http://serverfault.com/questions/330069/how-to-create-an-sha-512-hashed-password-for-shadow
  password         => '$6$',
  password_max_age => '99999',
  password_min_age => '0',
  shell            => '/bin/sh',
  managehome       => true,
}

group { "wordpress":
    ensure => "present",
}

class { '::mysql::server':
  root_password    => 'xxxxx',
  override_options => { 'mysqld' => { 'max_connections' => '1024' } }
}

mysql::db { 'wordpressdb':
  user     => 'wordpress',
  password => 'xxxxxx',
  host     => 'localhost',
}

class { 'wordpress':
  wp_owner    => 'wordpress',
  wp_group    => 'www-data',
  db_user     => 'wordpress',
  db_password => xxxx',
  wp_multisite   => true,
  wp_site_domain => 'new.xxxx.net',
  wp_lang     => 'it',
  create_db      => true,
  create_db_user => false,
  db_host     => 'localhost',
  install_dir => '/var/www/wordpress',
  install_url => 'https://wordpress.org/',
}

Pleas any help would be much appreciated.

When using this module, the random generation in the keysalt template can result in characters like backslash being inserted. It happened that a backslash was at the end of the salt string, which resulted in a syntax error.

Hi
when using the
wp_owner
wp_group
variables in the class definition the following error occurs with concat module intergration

## Configure wordpress
  class { 'wordpress':
    install_dir => '/var/www/wordpress',
    db_name     => 'wordpress',
    db_host     => 'localhost',
    db_user     => 'wordpress',
    db_password => 'wordpress',
    wp_owner    => 'wordpress',
    wp_group    => 'wordpress',
  }

Error: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]/returns: change from notrun to 0 failed: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]: Failed to call refresh: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0]
Error: /Stage[main]/Wordpress::App/Concat[/var/www/html/wp-config.php]/Exec[concat_/var/www/html/wp-config.php]: /var/opt/lib/pe-puppet/concat/bin/concatfragments.sh -o /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php/fragments.concat.out -d /var/opt/lib/pe-puppet/concat/_var_www_html_wp-config.php returned 1 instead of one of [0] 

removing the 2 wp_ vars works around the issue..

I am on Centos 6.6 and installing to a non default location (instead of /opt/wordpress or /var/www/html installing to something like /apps/web/www/html)

Everything installs fine but when it checks/changes permissions for the install folder, wp_config.php, and wp-keysalts.php it resets the selinux rights, and apache can no longer view the directory or files. You get a 403 forbidden. For apache to be able to view directory and contents you either have to disable selinux (which I can do, but would rather not) or add httpd_sys_content_t to the rights.

Here is the output from the run, it does this everytime puppet runs if i change the selinux perms.

Notice: Scope(Wordpress::Instance::App[/apps/web/www/html]): Warning: cannot manage the permissions of /apps/web/www/html, as another resource (perhaps apache::vhost?) is managing it.

Notice: /File[/apps/web/www/html]/seltype: seltype changed 'httpd_sys_content_t' to 'default_t'
Notice: /File[/apps/web/www/html/wp-keysalts.php]/seltype: seltype changed 'httpd_sys_content_t' to 'default_t'
Notice: /File[/apps/web/www/html/wp-config.php]/seltype: seltype changed 'httpd_sys_content_t' to 'default_t'

This is probably something im doing wrong on my end but for the life of me cant see what it is.

The documentation on installing the database on a different server is light. My impression is that it's only intended that this module supports the web machine, not that it also run on the db machine?

I've been looking in class wordpress::db (I realise that's not documented in README.md, so perhaps I should not consider it to be part of the external API?)

wordpress::db is simple enough, so I thought I'd just call it on the db server, but then I realised that the way 'db_host' is used for the mysql_user and mysql_grant resources, it actually refers to the IP of the client system, not the host that the db is on, which surprised me. Also requir'ing wordpress::app clearly means it can't be used on the db host in it's current form.

So, it appears that I'm looking beyond the usage that's been contemplated to date. consider this a feature request.

The existing install_url parameter actually functions as the base of the URL where the wordpress tarball should be downloaded from. If I the wordpress package that I want to download is at http://example.com/my-wordpress.tar.gz, there's no way for me to specify that. I would expect that I could set install_url = http://example.com/my-wordpress.tar.gz and have that used. Instead, the install_url is actually used like:

${install_url}/wordpress-${version}.tar.gz

It's an API-breaking change, so will have to wait until your next major release, but the install_url parameter should be changed to install_url_base and another parameter should be added called install_url that allows a full URL to a tarball to be specified.

I'd be happy to submit a pull request for this, but it should probably wait until you're ready to tag a new major release.

Loading a .sql file at database creation is already part of puppet-mysql . Would you be accepting of a PR that implements this here?

Overview

If wget is missing, users receive the confusing message:

Error: /Stage[main]/Wordpress/Wordpress::Instance[/opt/wordpress]/Wordpress::Instance::App[/opt/wordpress]/Concat[/opt/wordpress/wp-config.php]/Concat_file[/opt/wordpress/wp-config.php]: Failed to generate additional resources using 'eval_generate': undefined method `join' for "/opt/wordpress/wp-keysalts.php":String

Workaround

Install wget :)

long-term improvement

It would be a nice improvement to silence the noise from running puppet by protecting the call to join that is causing the above error. This will then leave users with less error messages to sift through