Loading Instagram posts on your website – using Powershell with cURL Last updated:28 April 2022

Spent some time yesterday including Instagram posts on one of my websites (this one if you’re interested). In order to get this going you need to use cURL, run from a command line, which was new to me. Windows 10 and later allows you to do this from Powershell, but I had to mess around a bit before it works, so here goes if anyone else needs this.

To start off you need to create an Instagram App. The Instagram instructions here are fine, so I won’t go through that.

My trouble started at Step 5 – ‘Exchange the Code for a Token’. Instagram gives this example code:

curl -X POST \
  http://api.instagram.com/oauth/access_token \
  -F client_id=684477648739411 \
  -F client_secret=eb8c7... \
  -F grant_type=authorization_code \
  -F redirect_uri=http://yoursite.com/auth/ \
  -F code=AQDp3TtBQQ...

…but this needs amending to use in Powershell, to:

curl.exe  '-X'  'POST' 'http://api.instagram.com/oauth/access_token' '-F' 'client_id=684477648739411' '-F' 'client_secret=eb8c713c492d1f9c19d7120e94ffcb205' '-F' 'grant_type=authorization_code' '-F' 'redirect_uri=http://www.yoursite.com/' '-F' 'code=AQDp3TtBQQh297S2as5YbDNAU9h3772mvryptCeWWT28z-Xadqq4YfA_YiGXui-cNnLjT7Wg_mrC0OAe0Q5l5x1RvdMarGvFIC1fv7I_kz32oGfKn-R1YlTEyLnPCKksGHeVgw7aJ3iLgXaS8QB9q-WNdG8PiWICz5Icwb4XULBNXs9DONlkIA1i94lNXoKsnkbLL13aMJLGpiiMksitRuZSRblwKrI1dEi7xqeHPcd9VJQ'

This took me about an hour to work out… Similarly, the request for a long-lived token needs to be formatted like this:

curl.exe '-i' '-X' 'GET' 'http://graph.instagram.com/access_token?grant_type=ig_exchange_token&client_secret=eb8c713c492d1f9c19d7120e94ffcb205&access_token=IGQVJYclF4WUllREZABbU9rWm1TS2F0am12cWRUVWxIbURLQXc2eXZAyaTVmNnU5a0ZAFTlU4bkFCOG5sd0JwWFMwZA0VYR0ZAFcnVBZAzZAoVFFwdVN5bmVaWmNGQm42X3VvSEJNc0ZAfWG1zbjB3OThFbm9SNk1wZAHZArOVJVQnQw'

Once you’ve got the access token then you’re off and running. I was using PHP to call the Instagram data from Opencart, so I created a custom module, stored the access token as an Opencart setting and included this code to call Instagram (in a model file, called by the module controller):

	public function getInstagramContents() {
		$fields = "media_type,media_url,permalink,thumbnail_url";//call the fields you want
		$token = $this->config->get('instagram_access_token');//get the stored token
		$limit = 4;//get the four most recent posts
		 
		$json_feed_url="http://graph.instagram.com/me/media?fields={$fields}&access_token={$token}&limit={$limit}";
		$json_feed = @file_get_contents($json_feed_url);
		$contents = json_decode($json_feed, true, 512, JSON_BIGINT_AS_STRING);
		
		return $contents;
	}

If you’ve got this far you’re probably OK with the restof it, but if the rest of the Opencart stuff is useful let me know in the contents below.

Opencart – ‘The Twig_Autoloader class is deprecated…’ error Last updated:4 May 2022

I was contacted by a client last week who was getting this error message on her site.

It appears on Opencart 3.x up to 3.0.3.5, and is caused by an older version of the Twig template engine not playing nicely with PHP 8. Thus the problem often occurs if your hosting company has upgraded your PHP version without telling you. Searching for the error mainly finds a number of sites with the same issue, plus a number of threads on the (sadly rather unhelpful and not uncommonly abusive) Opencart forums, none of which have what I think is a clear answer. So, for the benefit of others, here are your options if this happens to you:

Update your Opencart version

This is the best option. Upgrading from 3.x to a newer version is relatively straightforward and documented elsewhere.

Revert to an earlier version of PHP

This is good for a quick fix, and is generally done from your hosting Control Panel. If your hosting provides cPanel, then it’s accessed via MultiPHPManager. Find the affected domain, and change the PHP version from 8 to 7.4. Apply the change and your errors should have disappeared.

To restate, this is just a temporary fix as at some point in the future your hosting company may remove the option to run PHP7.

Manually update files on the server

At this point all the purists will be throwing their hands in the air and listing lots of reasons why this is bad idea. However, we live in the real world, and it may be you have multiple hard coded customisations on your install, and you really don’t want to take any risks. If this is the case, read on, this is what I did:

  1. Take whatever backups of your filesystem and database you need to sleep soundly
  2. Download a copy for the latest Opencart (3.0.3.8 at the time of writing) to your PC
  3. From your new download, upload the whole of the system folder on top of your current version.
  4. Similarly, upload the catalog/controller/event/theme.php file on top of your current version
  5. If you currently have your storage folder outside your Opencart directory, edit config.php and admin/config.php to set the storage folder back to ...system/storage withhin your Opencart directory

And that’s it. You’ll want to run your own checks of course, but that worked for me.

Opencart will prompt your to move your storage folder when you log in to admin.

If for whatever reason you haven’t uploaded the system folder on top of the existing one, but deleted the old one instead, then you will get a different error complaining about Openbay. This is because Openbay support was removed in OC3.0.3.6. Assuming you don’t need this then find this line in both catalog/controller/startup/startup.php and admin/controller/startup/startup.php:

registry->set(‘openbay’, new Openbay($this->registry));

and delete it or comment it out.

Opencart unable to access admin after updating Last updated:13 June 2018

Spent this morning updating a client’s site to Opencart 1.5.6.4. All went well until I tried to log in to admin, when the admin login screen just refreshed, no error message, nothing in error log. After some digging, I identified that although the site was ussing SSL, the form was being submitted to a non-SSL URL. So it failed. The solution was to edit the admin config.php file to set the HTTP_SERVER constant to use https.

define('HTTP_SERVER', 'http://yourdomain.com/admin/');

There are lots of mutterings on various boards about this, but didn’t see this as a solution…Hope it helps.

Page Builder data lost after migration Last updated:18 August 2016

I’ve spent a lot of time this morning looking into an issue with a client site migration where Page Builder data was lost after the migration.

I have migrated many many WordPress sites by exporting the database, replacing the old URL with the new URL in the exported SQL and re-importing. Never had an issue. But in this case I did, and it’s related to how Page Builder stores data. This data is serialized, and the serialization stores both the data and its length. So a snippet of stored data looks like this:

s:160:"<p><img class="alignleft size-full wp-image-2348" src="http://test.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Super…so if you run a global replace on the domain name you end up with this:

s:160:"<p><img loading="lazy" class="alignleft size-full wp-image-2348" src="http://production.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Which looks fine, but it isn’t because the serialization is now incorrect as the length of the serialized string has changed from 160 characters to 166 characters. Result: lost Page Builder data.

The correct update should be:

s:166:"<p><img loading="lazy" class="alignleft size-full wp-image-2348" src="http://production.co.uk/wp-content/uploads/2014/05/Tulips.jpg" alt="Tulips" width="200" height="150" /></p>"

Clearly doing this is impracticable and fortunately there’s a plugin that handles this which is WP Migrate DB.

imagejpeg issues with PHP 5.4 Last updated:27 November 2014

Came across an interesting little issue this afternoon while debugging an issue with a very old osCommerce installation. This particular site uses an on the fly product thumb generator (product_thumb.php) which worked fine with PHP 5.3 but failed with PHP 5.4.

After a bit of digging I tracked the issue to this line in the original code:

imagejpeg($src, '', 100);

In PHP 5.4 this fails, and needs to be replaced with:

imagejpeg($src, NULL, 100);

Perhaps this will save someone a bit of time. I didn’t find this problem noted elsewhere.