php

stripslashes / wp_unslash with multibyte / mbstring support

by

One truly annoying thing with WordPress is that it doesn’t use the mbstring extensions at its core. I fully realize how big of a task a re-write is in this regard, but considering there are utility functions for just about everything you want to do as a WordPress plugin and/or theme developer, I think this needs to be addressed. Oh, and it’s 2021 by the way.

An issue that quite a few seem to be frustrated about is POST/GET form data handling, and the situation with single and double quotes being “escaped”.

Without further ado, this snippet will “unslash” a string, with support for multibyte characters (there’s no magic here, really):

function x_stripslashes( string $str ) {
    return( mb_ereg_replace( '[\x{005c}][\x{0027}]', '\'',
                             mb_ereg_replace( '[\x{005c}][\x{0022}]', '"',
                                              $str ) )
    );
}

NCweb 0.0.5, your Nextcloud Web Server

by

NCweb 0.0.5 has been released, yay 🙂

You can grab a copy here if you’re curious about the changes, if not, carry on.

If you want to read more about NCweb, check out the GitHub repository

The initial announcement can be found here

Spoiler alert: This is possibly a completely useless application if you do not run Nextcloud, don’t have PHP or don’t know what PHP is, or don’t run Nginx or Apache. And even if you do meet the criteria, it may still disappoint you as well as being useless to you.

pdftk and php-pdftk on Ubuntu 18.04 without using snap

by

During a product launch I recently came across an “interesting” issue involving pdftk (and php-pdftk). Some of the developers had made assumptions (ever heard that one before?) about the operating environment and how things were/are configured.

These assumptions were based on a development environment that in no way reflected the final production environment (ever heard that one before?). In this particular case, they were expecting the great PDF toolkit (pdftk) to be available and working just like it did in their development environment.

To summarize the issue: pdftk has been removed from Ubuntu 18.04 due to dependency issues. The “recommended” solution is to install pdftk using snap. This, in itself, is not a bad recommendation. But in a web server environment, it may put you in a place you don’t want to be in.

So after a few hours of toying with ideas and testing various things, I figured there must be some Debian-like package that would actually work when installed on Ubuntu 18.04 and that is not a snap package.

There is.

Later versions (or packages) of pdftk now exist as pdftk-java, and they do work with php-pdftk as well.

In my case, I located pdftk-java_3.1.1-1_all.deb and installed it. Or tried to rather. It has a number of dependencies that you will see for yourself. You’ll need to decide if their “weight” makes it worthwhile for you to go down this path. But it was one, reasonably good, way for us to solve the problem.

The developers you ask? They have been sent to /dev/codersgulag/cobol and will spend a number of solar iterations there.

(The file I ended up using was http://ftp.debian.org/debian/pool/main/p/pdftk-java/pdftk-java_3.1.1-1_all.deb, and it does work on Ubuntu 18.04.LTS)

 

 

NCweb, serve static website content from Nextcloud

by

NCweb is a reasonably small (ish) PHP “application” that will allow you to expose a given folder of a Nextcloud instance and serve documents from it as if it would have been a regular website. The folder does not have to be shared in Nextcloud. You can serve .html (HTML) or .md (Markdown) files. NCweb can be configured to render Markdown files to HTML.

Get it from Github here: github.com/joho1968/NCweb

Troubleshooting WordPress re-directs (301)

by

While trying to configure some internal URL re-writing in nginx for a WordPress site, I ran across an annoying issue:

Regardless of my re-writing efforts, WordPress would issue a re-direct (301) header (?!)

This wouldn’t have been such a big deal if I didn’t want the URL to stay the same in the browser’s address bar. If I didn’t have that requirement, I would naturally have used a simple re-direct.

After spending some time troubleshooting this, and making sure nginx was actually doing what I wanted it to do, I ran across a few posts talking about disabling “canonical redirects” (sic) in WordPress. So adding this snippet to the end of the active theme’s functions.php:

remove_filter('template_redirect','redirect_canonical');

got rid of WordPress re-directs. Unfortunately, another plugin “stepped in” and started doing it instead (this time, it was the Polylang plugin). I’m sure there are a number of other plugins that exhibit this behavior, and it may be possible to circumvent this in many/most/all of them by using something similar to the above snippet, but I still haven’t solved the actual problem.

Using cURL to debug URL re-writing and URL re-direction can save you a lot of time, like this:

curl -I https://yourwebsite.foo

(Please note that the issues I have experienced here are not related to nginx. This would happen in Apache too as the re-directs are issued by the WordPress stack. Once control is handed off to PHP, there’s little the web server can do.)

If you’re playing with nginx, PHP-FPM, and URL re-writing, you may also find this post of interest: URL re-writing with nginx, PHP, and WordPress

URL re-writing with nginx, PHP, and WordPress

by

There are many posts about nginx, re-directs, PHP, and WordPress. There are somewhat fewer posts that talk about (internal) re-writes, where the request by the web browser is mangled to be served by another resource than the one requested.

For example, I may want a request for https://mysite.foo/cool/penguin to actually be served by https://mysite.foo/coolstuff.php?id=penguin, or simply setup an alias such as https://mysite.foo/cool/penguin to be served by https://mysite.foo/cool/linux, but preserve the URL in the browser address bar.

With PHP-FPM and nginx, you run into an additional problem, which is the fastcgi_parm variables that are passed from nginx to PHP-FPM. So even if you have really fancy URL re-writing configured (and working), the end result may not be passed on to PHP-FPM from nginx.

So solve this, you should look into this construct, which is present in many nginx configurations as a default setup:

fastcgi_param REQUEST_URI $request_uri;

Since your needs probably differ from mine, I wont make this post any longer than it has to be, but that fastcgi_param line above may be a good starting point if you’re experiencing problems with nginx, PHP-FPM, and URL re-writing.

Good luck!

SwiftMailer 5, PHP5, and ISO-8859-15

by

I’ve been using SwiftMailer for as long as I can remember because it’s, IMHO, a great library and far more logical than PHPMailer and “others”. While maintaining a PHP5 codebase for a rather large project, I ran into an issue while using ISO-8859-15 encoded data. Most people won’t care about ISO-8859-15 over ISO-8859-1 (“Latin1”), but since I live in Europe, I prefer to have support for the €uro character 🙂

To make a long story short, if you need SwiftMailer 5 to properly handle ISO-8859-15, look for a line in “MimePart.php” that looks like this:

if (!in_array($charset, array('utf-8', 'iso-8859-1', ''))) {

and change it to this:

if (!in_array($charset, array('utf-8', 'iso-8859-15', 'iso-8859-1', ''))) {

(Yes, the project will move to a PHP7 codebase at some not so distant point in the future.)

Simple password construct validator for PHP

by 
/* 
 * Simple password construct validator for PHP 
 * Joaquim Homrighausen <joho@webbplatsen.se>
 * May 30, 2019 
 * TEAMYUJO 
 * 
 * Do whatever you want with this snippet :) 
 * 
 * This may not necessarily agree with the section
 * "Strength of Memorized Secrets" in the document
 * from NIST:
 *
 * NIST Special Publication 800-63B 
 * Digital Identity Guidelines 
 * Authentication and Lifecycle Management 
 * https://pages.nist.gov/800-63-3/sp800-63b.html 
 */

function password_check_construct ($pstr, $min_length = 8)
{
  //Setup pattern and stuff minimum requested length into it
  if ($min_length < 4) {
    //We need at least four characters to satisfy our regexp
    $min_length = 4;
  }

  $match_rules = '/^(?=.{'.(int)$min_length.',})(?=.*[a-z])(?=.*[0-9])(?=.*[A-Z])(?=.*[[:punct:]]).*$/';

  //Require at least one a-z, one A-z, one 0-9, and one punctuation/special character
  if (preg_match ($match_rules, $pstr) === 1) {
    return (true);
  }
  return (false);
}

This is also available as a gist on GitHub. Knock yourself out 🙂

Setting PHP.INI path (or file) for PHP CLI shell scripts

by

Running a PHP script from the command-line, or CLI, is quite useful at times and is often used to perform some automated task, like a CRON cleanup script, to send out reminders, etc.

It’s common that these CLI scripts need some, but possibly not all, settings that are similar to the main application’s. I may, for example want to include the database configuration settings shared with the main application. So I often create a separate php.ini file for this purpose.

Running /usr/bin/php -c /my/very/special/path cronScript.php is simple enough, but what if I want to be able to create an “executable” PHP shell script? The obvious answer would be something like:

#!/usr/bin/php -c /my/very/special/path

at the top of the .php file, followed by my PHP code, right? Except that may not do what you want. I could not get the PHP interpreter to load anything in /my/very/special/path by using the above construct, even if it works from the actual command-line. After banging my head against the wall for a while, this turns out to work for these “shell scripts”:

#!/usr/bin/php -c=/my/very/special/path

Note the use of the = (equal) sign between the -c and the path (or file).

Carry on.

PHP is_numeric () fails WordPress version string check

by

This is, perhaps, obvious to most PHP developers. But it came somewhat as a surprise to me.

Using is_numeric () for validating a WordPress version string, such as ‘4.7’, does not seem to work very well when WordPress introduces minor releases such as ‘4.7.1’.

Since I cannot be bothered to figure out why it behaves in this (erratic, IMHO) way, I have since replaced the call to is_numeric () with a small function using a simple regular expression (regexp):

    function wpVersionStringCheck ($vs)                                                                                                 
    {                                                                                                                                   
        return (preg_match ('/^(\d+\.)+\d+$/', $vs));                                                                                   
    }

I’m sure there is a hole in there somewhere, but on the following strings at least, it gives me the desired result:

1.0 is valid
1.0. is invalid
1.0.1 is valid
1.banana.0 is invalid