Local like a local (webroot) - the dot in the middle ./vendor/bin/sspak save . ./test.sspak The sniffer script started to fail with: https://github.com/silverstripe/silverstripe-framework/commit/e08bf1cdd96ea2930b2a41162eaad384404c1672

if DatabaseAdapterRegistry::autoconfigure($databaseConfig); is commented out, it runs trough https://github.com/silverstripe/silverstripe-framework/blob/4/src/Core/CoreKernel.php#L372 otherwise it has a hard time getting the cache https://github.com/silverstripe/silverstripe-framework/blob/4/src/Dev/Install/DatabaseAdapterRegistry.php#L184

@emteknetnz - I have difficulties understanding how it fails. May you can shed some light on it?

ACs

• We preserve the fix that was put in earlier to cache the glob
• You can run sspak /dev/build without flush on a brand new site without error
• Confirm or deny if the $_GET['flush] on the code on earlier fix (see comment below) is required, and if CLI dev/build (with and without flush) stuff flushes the cache. Either update code or write a comment explaining usage of $_GET['flush] (possible that it's there so that things flush in a particuar order)
• Confirm or deny if there's a wider issues where there's a difference between /dev/build and /dev/build?flush, and if so, raise a new issue

Make travis publish our releases on successful merge.

Things that need doing:

1. Turning on travis (make sure you only test pushes and not PRs)
2. Adding an encrypted environment variable GH_TOKEN to allow travis to push to the gh-pages branch

When I run the following command

$> sspak save --db /var/www/html/mysite local-test2.sspak

then return the following Can't process database type 'MySQLPDODatabase'

This fixes an issue where a sql dump has a USE or CREATE statement.

sspak won't handle that well and will end up creating a new DB instead of importing into the target DB.

This change strips out lines starting with USE or CREATE to ensure that the intended DB is used.

The install script needs a few tweaks:

• It should run composer install if checked out from git.
• It should check out the specific sha if the sha is different from the branch.
• It should run dev/build, using the sudo user.

The install script in self-extracting archives should also assume that the first argument is the current script, and limit actions to load and install.

I deploy a capistrano style with deployer php, which symlinks assets in each release.

Using sspak load my.sspak /path/to/current destroys the assets symlink in current and generates an assets directory with the new content - which is lost in the next release.

See https://github.com/silverstripe/sspak/blob/d697d767758d713952a4e0b21c0cd3b1088462e2/src/Webroot.php#L138-L157 where that happens.

• Adds a new bin location for composer so we can use sspak still as the bin filename
• Rejigged readme to use # for titles, and added installation example with composer
• Tweaked a couple of constant values to ensure composer-compatible sspak works with B/C over original

Resolves #21

Trying to save from a remote server with sspak save USER@SERVER:/home/[username]/public_html site.sspak, but getting this:

Could not parse sspak-sniffer content:

Notice: Undefined index: REQUEST_URI in /home/[username]/public_html/framework/control/Director.php on line 892
<p>Redirecting to <a href="" title="Click this link if your browser does not redirect you">...</a></p>
<meta http-equiv="refresh" content="1; url=" />
<script type="text/javascript">setTimeout(function(){
    window.location.href = "";
}, 50);</script>";

For example:

sspak install my.sspak /sites/mysite/releases/123 --symlink=/sites/mysite/www

This would install to /sites/mysite/releases/123, run the post-installation script, and then create /sites/mysite/www as a symlink pointing to /sites/mysite/releases/123.

Getting an error when running sspak with MySQL 5.7.

Couldn't execute 'SELECT COLUMN_NAME, JSON_EXTRACT(HISTOGRAM, '$."number-of-buckets-specified"')
FROM information_schema.COLUMN_STATISTICS WHERE SCHEMA_NAME = 'xxxxxxx' AND
TABLE_NAME = 'Answer';': Unknown table 'COLUMN_STATISTICS' in information_schema (1109)

Might be a specific db setting, but passing in --column-statistics=0 to mysqldump fixes the issue. Will provide a PR.

Performing a simple sspak save --db user@remote:/home/site database.sspak command seems to open and close a total of 5 SSH connections.

I work with a host who limit the maximum number of SSH connections from the same IP within 1 minute to just 4, so the sspak save command causes this limit to be hit and a short block applied.

Not sure exactly why it requires 5 connections to download the database, is this an area that could be optimised?

Simply running sspak you'll see this at the top if you're on php8.1<

PHP Deprecated:  strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in phar:///usr/local/bin/sspak/bin/sspak on line 37

Deprecated: strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in phar:///usr/local/bin/sspak/bin/sspak on line 37

There are supposed to be multiple ways to install sspak: a) composer.json b) composer global require silverstripe/sspak c) installation script - curl -sS http://silverstripe.github.io/sspak/install | php -- /usr/local/bin d) direct download - sudo mv sspak.phar /usr/local/bin/sspak

a) works to the best of my knowledge, though this should be confirmed

b) requires suffixing :dev-master i.e. composer global require silverstripe/sspak:dev-master. You also need to have ~/.config/composer/vendor/bin in your $PATH for it work seamlessly e.g. sspak <commands>

Some time ago, the binary in bin/sspak stopped being updated, presumably because a github token was revoked. That binary is now out of date, therefore c) and d) do not function as expected. This is very bad, since it means people may be installing an out of date version.

My personal recommendation is that we should remove options c) and d) and force the use of composer, which is the standard way to install all things php. This is my view simply because I do not want this silently breaking again. Others may have a different view though.

Acceptance criteria

• [ ] Audit the 4 installation methods to see if they function properly
• [ ] Release 1.0.0 so that the :dev-master suffix isn't required for b)
• [ ] Investigate if Silverstripe Ltd platform uses sspak at all for extracting sspak files, and if so if it relies on either c) or d)
• [ ] Investigate the amount of work required to get the sspak to regularly update via github actions on the tag github event (OR simply decide that we wish to only use composer) - if it's non-trivial then strongly recommended we just drop functionality
• [ ] Remove the github pages - all documentation should be in the README.md instead
• [ ] Update documentation to reflect the recommended ways to install sspak

Issue https://github.com/silverstripeltd/product-issues/issues/570

CI for this PR is run on the creative-commoners org: https://github.com/creative-commoners/sspak/actions

I have a number of docker containers running with a volume bound to the public/assets directory, when using sspak load it tries to move the assets to assets-old but since the directory is a volume it fails. I've had success by commenting out

https://github.com/silverstripe/sspak/blob/1d1ffff9af48b4ebd6d133830c325244e201695d/src/Webroot.php#L159

but it's a manual step I have to do every time as sspak is baked into the image and the containers are frequently rebuilt.

After reinstalling sspak on my iMac, it would fail with an error about being unable to create the temp folder:

$ sspak save --db user@host db.sspak

Command: ssh -t 'user@host' 'mkdir '\''/var/folders/_m/9n7ryp613nz33y5bs9mqs9vc0000gn/T/sspak-680110'\'''
Execution failed: returned 1.
Output:
mkdir: cannot create directory ‘/var/folders/_m/9n7ryp613nz33y5bs9mqs9vc0000gn/T/sspak-680110’: No such file or directory

After trying many things to resolve it (such as testing that PHP could actually create a dir in the above location - it could), I copied the version of sspak from my laptop (into /usr/local/bin) and it works fine. So it seems the issue has been introduced into the current release at some point.

Maybe this PR is related: https://github.com/silverstripe/sspak/pull/75 However I did try installing the latest version and adding TMPDIR="/tmp" to the command to see if it was the change in default temp directory that was causing it, but I still received the error.