jeffreylicht

The bug in redirect handling was fixed in version 1.4.2 (released March 15, 2016).

Both of these bugs were fixed in version 1.4.2 (released March 15, 2016).

Regarding the post that you took down: Amber doesn’t check the status of links on a page each time the page is loaded. Instead, it checks in the background no more than once a day, and updates the status appropriately. (To be precise, as long as the status of a link doesn’t change, the interval between checks will gradually increase until the link is only being checked once a month).

Regarding the tweet: We found a bug in redirect handling which was preventing some tweets from being preserved, which will be fixed in the next release. That being said, the pages on twitter.com have some javascript which has the effect of preventing them from being displayed outside of twitter.com. So, even if you do preserve the tweet, you will probably only be able to view it if you turn off Javascript to view it.

Thanks for the feedback!

Thanks for trying out Amber, and for your helpful feedback!

We’re in the process of fixing a few bugs that you’ve encountered, and will be releasing a new version shortly. Specifically:

– There was a bug that prevented the Amber Dashboard from displaying the reason why links weren’t preserved, which is being fixed.

– There’s a configurable limit on the size of snapshots that Amber creates, to prevent any single snapshot from using up excessive amounts of disk space. The default is 1MB, which isn’t sufficient for many sites once you include assets such as images, javascript, etc. We’re going to increase the default, but in the meantime you can change it on the Amber Settings page ( the field is “Maximum file size (kB)”). It’s likely that this is the reason that many of your links are not being preserved. It might also account for the perceived randomness around where links are saved – if a link is over the size limit it would be saved on the Internet Archive and Perma, but not on the local server.

Regarding access to locally saved archives: if the archive was saved successfully you will see a “View” link under the Site Name when you hover over a row in the dashboard. Clicking on this will display the locally saved archive.

Regarding the creation of the local folder: could you share some details of the permissions problems you encountered, and the environment on which you’re running WordPress? We haven’t seen this problem before – creation of the folder should be completely automatic.

Thanks again!

Thanks for trying out Amber!

You’ve found a few bugs and a poorly chosen default configuration setting, all of which will be fixed in our next release. Specifically:

– Amber has a configurable limit on the size of an individual snapshot. This includes the HTML for the page being preserved as well as associated assets (images, javascript, etc.). The default is set to 1MB, which turns out to be less than the 1.5MB size of the amberlink.org home page. That’s why the AmberLink.org home page wasn’t being preserved. We will increase the default limit, since 1MB is clearly too small.

– That brings us to the first bug, which was that the message explaining WHY amberlink.org wasn’t preserved was not being displayed on the dashboard. When fixed, you will see a message (“File size of document + assets too large”) in the Notes column for affected snapshots

– The second bug relates to Twitter – we weren’t properly following HTTP redirects that used the 307/308 HTTP status codes, so the tweet wasn’t being cached properly.

These bugs will be fixed in the next release, and I’ll follow up here when it’s available.

You can actually scan and preserve all links in bulk, rather than going through each post individually:

Go to Tools -> Amber Dashboard
Click “Scan content for links to preserve”.
Once all content has been scanned, click “Snapshot all new links”.

Amber checks to see if you’re using Permalinks by calling the WordPress function using_mod_rewrite_permalinks(). It looks like the ‘index.php’ in the your Custom Structure is confusing that function.

You can ignore the warning – your URL structure should not cause any problems.

(Separately, you should upgrade to version 1.4.1, which we released this morning, and fixes a problem displaying snapshots).

I’m completely on board with ensuring that all plugins are compatible with with older versions of PHP. My actual concern is that the advice being given in the most “official” word on the subject is not consistent with the rules that are being enforced by the Subversion validation.

From https://make.www.ads-software.com/plugins/2015/06/05/policy-on-php-versions/ :

Sometimes though, you need more complicated checks. Let’s say your plugin uses PHP namespaces. Those are not supported in PHP 5.2, and will cause a syntax error just from having them in the file, before any of your code runs.

So, your main plugin file needs to not have namespaces and basically only be a shiv to load the rest of the plugin from another file if the requirements are met:

if ( version_compare( PHP_VERSION, '5.3', '<' ) ) {
    add_action( 'admin_notices', create_function( '', "echo '<div class=\"error\"><p>".__('Plugin Name requires PHP 5.3 to function properly. Please upgrade PHP or deactivate Plugin Name.', 'plugin-name') ."</p></div>';" ) );
    return;
} else {
    include 'rest-of-plugin.php';
}

Here, the plugin does not load the files that can cause errors unless the requirements are met.

The recommendation in that blog post is to conditionally load PHP files containing code which is not syntactically valid in older versions of PHP. The implication is that those files can be included in the plugin, as long as they aren’t loaded when they wouldn’t be valid. However, the Subversion pre-commit hook is validating every file, whether or not there is logic to prevent it from being loaded on older versions of PHP.

I’ve worked around the immediate problem by using v2 of the AWS library – thanks Ipstenu! – but still think there’s an issue here to be addressed, either by updating the documentation or changing the validation behavior.