1. First (proper) language: Algol W 2. Had difficulties: Simula 3. Most used: Pascal 4. Totally hate: LISP 5. Loved: Pascal 6. For beginners: n/a
43 years ago, at the tender age of 16 years and 11 months, I entered the IT industry. My salary was £1690 per annum; £65 a fortnight.
A few months ago, having resolved to internationalize, localize and test my WordPress plugins, I started busily beavering away at a solution that will enable me to automatically deliver UK English versions of my plugins.
Now that Global WordPress Translation Day #3 is fast approaching it seems timely to write up an outline of my approach.
The solution involves a number of fairly well defined processes, and a lot of repetition.
Today I updated the version of PHP I use in my development environment, from PHP 7.0.7 to PHP 7.1.1.
If you’re developing a Genesis child theme and making quite a few changes to your
style.css file you may want a quick and easy method of ensuring the style file is reloaded every time it gets changed.
One way is to ensure that the
ver parameter on the stylesheet definition changes each time you update the file.
This post documents my experiences of getting started with
React.js. Note: this is a work in progress.
This is a work in progress post, cloned rather prematurely from my development machine so I can refer to from my iPad when my development machine is not available.
For every new release of WordPress, plugin and theme developers are expected to test that their products are compatible with the new version, and to update their “Compatible up to” status. But if you have lots and lots of plugins, how do you test them all? WordPress uses a tool called PHPUnit. Plugins and themes can do the same. This post discusses the solution that I’ve been developing to PHPUnit test my WordPress plugins in situ.
Sometime on the 12th my site started to produce a series of PHP Fatal errors saying “Allowed memory size of 41943040 bytes exhausted.”. This was a bit of a surprise. It means that my memory limit was 40M, a lot lower than the expected value of 256M.
Other times the response was
[13-Jul-2016 02:54:59 UTC] PHP Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0
To recover from this problem I used ftp to rename Jetpack to Jetpack-f.
I was then able to access the site.
- The site was migrated from one host to another.
- The PHP version on the new host was 5.4.45.
- The memory_limit was set to
- For PHP 5.3, 5.5 and 5.6 the memory_limit would have been
256M; a much nicer number.
- By the time WordPress started up the memory limit became
- It’s WordPress that sets this limit, depending on the site. For WPMS it’s
I’ve yet to track down the specific plugin/module combination that causes WP to exceed the 4OM limit.
- My oik-bwtrace plugin reports the memory limit on its admin page.
- This is 256M, since WordPress sets it higher in admin pages. Using admin_memory_limit in wp-admin/admin.php.
- I’ve changed my [wp] shortcode to display the memory limit on the front-end.
- For this site the memory_limit has already been set by the hosting company to a high value.
WordPress 5.3.2. PHP: 7.3.7. Memory limit: 768M
- I’m also experimenting with code that displays the current memory_limit in trace records produced by oik-bwtrace. They already optionally display current and peak memory usage, so adding the current memory limit is no big deal.
I’ve been porting a site from Drupal to WordPress recently but it wasn’t until I loaded it onto hosting with 1&1 that I noticed some problems with my [bw_show_googlemap] shortcode.
I’ve fixed the problem in oik v3.0.2. The new solution requires you to obtain a Google Maps API key, and enter it in oik options.