Opened 4 years ago

Closed 21 months ago

#9855 closed Task/To do item (fixed)

add wp-cli to all moshes

Reported by: https://id.mayfirst.org/jamie Owned by: https://id.mayfirst.org/gregl
Priority: Urgent Component: Tech
Keywords: wp-cli Cc: https://id.mayfirst.org/dkg
Sensitive: no

Description

See #1608 for the details - specifically the last couple comments. Here's a link to already created deb packages:

https://github.com/wp-cli/builds

There's an ITP to package it in Debian, but not a lot of progress.

In the meantime, this is the blocker for getting wordpress support in our control panel.

Change History (13)

comment:1 Changed 4 years ago by https://id.mayfirst.org/jamie

  • Cc https://id.mayfirst.org/dkg added
  • Owner set to https://id.mayfirst.org/gregl
  • Status changed from new to assigned

I'm assigning to greg and cc:ing dkg since you are the only two people (I think) who can add packages to our repository. If either of you could make this happen it would be great.

comment:2 Changed 4 years ago by https://id.mayfirst.org/dkg

wow, the .deb for 0.16.0 on the builds page is so horribly against debian policy that i don't even know where to begin, but i'll try:

  • no source package available
  • no debian/changelog or debian/copyright information
  • package installs a single file /usr/bin/wp, which appears to be some sort of 1.2MiB compiled/aggregaged php + bundle of certificates and symfony classes and god-only-knows what else.

In short, it looks like an unmaintainable mess. If we're going to use symfony or other php subclasses, or certificate lists, we should be relying on maintained versions of them, not a big opaque bundle. i would be sad if we were to try to use this thing directly on MF/PL infrastructure without closer vetting, decomposition, and review.

the ITP seems like a bit more work has been done toward sane packaging practices, but i don't have the time (or PHP details) to push it further myself right now.

If we want this to be well done, someone should pick up the ITP and try to complete it.

comment:3 Changed 4 years ago by https://id.mayfirst.org/jamie

It doesn't look like that ITP is going to move anytime soon, and unfortunately this is blocking #1608, a really old ticket that a lot of work has already gone into.

I'd like to suggest that we keep this ticket open so if wp-cli finally does get into Debian, we can switch to the Debian version.

But in the meantime, we manually provide our own version in a way similar to the way we maintain our own version of Drupal (with simple scripts that download the package over the web). wp-cli has a command that checks for updates - so we could also setup a cron job that runs that command daily and creates a nagios alert when a new version is available.

The only other option I can think to get #1608 going (aside from completing the ITP or the one I suggest in the paragraph above) is to write and maintain our own custom WordPress installer that uses the minimal code possible to get the work done. However, that will require maintenance and it means our users won't have the benefit of using wp-cli to help keep their web sites up to date.

Given the security trade-off of "giant packages mess of libraries that might have security holes" vs. "difficulty keeping wordpress sites up to date" - I think we will be better off getting wp-cli on our moshes even in a less than ideal way.

comment:4 Changed 4 years ago by https://id.mayfirst.org/dkg

Presumably the wp-cli "giant mess of libaries" are being generated from some source. It would be great to find that source, and see if some sense can be made of it.

I don't think the tradeoff is between just the two options you mentioned -- the third option is to understand where the 1.2MiB comes from and prune them sanely. then you get wp-cli and security support for its components. This does require someone who is comfortable working in php, though.

comment:5 Changed 4 years ago by https://id.mayfirst.org/ross

So it appears that only one of the libraries being used for the wp_cli code have debian packages that might work and that is symfony. The rhumsaa library is being used explicitly for array_column() which is available in php5.5, but not in 5.4. So that one will eventually be removable. The rest of the required libraries do not seem to exist in debian packaging.

We could adjust the code to take advantage of symfony and leave the other libraries as is until we upgrade our systems to php5.5.

comment:6 Changed 4 years ago by https://id.mayfirst.org/dkg

is there a list of the other required libraries? how is that list maintained? do those libraries receive security support?

comment:7 follow-up: Changed 4 years ago by https://id.mayfirst.org/ross

Ah yes, sorry, I'm looking at this file for the libraries.

comment:8 in reply to: ↑ 7 Changed 4 years ago by https://id.mayfirst.org/dkg

Replying to https://id.mayfirst.org/ross:

Ah yes, sorry, I'm looking at this file for the libraries.

hm, confusing. what does mustache have to do with wp-cli? i don't know how to read composer files, but i think the only thing that shows is a -dev dependency (maybe that just means at build/package time instead of runtime?) on phpunit, which is certainly in debian.

still puzzled,

--dkg

comment:9 Changed 4 years ago by https://id.mayfirst.org/jamie

Hm - I think the link that Ross pasted is the dependencies for the php mustache package, which is just one of wp-cli's dependencies. I think we want the full the list of wp-cli dependencies.

I just tried to test whether wp-cli can run without the symfany provided by the package as long as the debian package php-symfony-yaml is installed.

As a non-privileged user I first had to download composer:

curl -sS https://getcomposer.org/installer | php -- --install-dir=/tmp/wpcli/via-composer/bin

Then, I pulled in wp-cli:

composer create-project wp-cli/wp-cli --no-dev

Then, I deleted the symfany directory from vendor directory.

Then, I installed php-symfony-yaml. And created a database.

Then:

mkdir wordpress
cd wordpress
php ../bin/wp-cli/bin/wp core download
php ../bin/wp-cli/bin/wp core config --dbname=wp --dbuser=wp --dbpass=wp
php ../bin/cp-cli/bin/wp core install --url=wp.piglet --title=test --admin_user=admin --admin_email=jamie@animal.town --admin_password=admin

Before I let myself feel good about this, I ran apt-get purge php-symfony-yaml and then was able to repeat the procedure without errors.

Sigh.

Not really sure what that means about the symfany dependency.

comment:10 Changed 3 years ago by https://id.mayfirst.org/jamie

See related issue with drupal: #10624

Last edited 3 years ago by https://id.mayfirst.org/jamie (previous) (diff)

comment:11 Changed 3 years ago by https://id.mayfirst.org/jaimev

I don't think that was the ticket you meant to link to jamie.

comment:12 Changed 3 years ago by https://id.mayfirst.org/jamie

Oops... edited to correct ticket. Thanks Jaime.

comment:13 Changed 21 months ago by https://id.mayfirst.org/jamie

  • Resolution set to fixed
  • Status changed from assigned to closed
  • Summary changed from add wp-cli debian package to the apt.mayfirst.org repo to add wp-cli to all moshes

I've finally abandoned all hope of wp-cli ending up in Debian (or of being able to figure out how to get it into debian) and have added it to our puppet repo.

I'm now following http://wp-cli.org/blog/ so I can be alerted to updates.

And I've downloaded a copy of wp-cli via curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar to our puppet repository and will maintain it via puppet.

Now, wp is currently installed on julia for testing and will be copied to all other moshes on the next signed release.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.