:::: MENU ::::
Posts tagged with: php

Reading PHP serialized data quickly in a Linux Terminal

Here’s a quick script for reading a data file containing serialized data generated by PHP, and outputting it in a human readable format to a Linux command line interface. A short web search found no existing utilities for achieving this, so hopefully it will be useful.

You must use absolute paths (using tilde also expansion works, of course). Save this as a file called deserialize-php, make it executable, and move it into your /usr/bin folder to make it universally accessible.

#!/usr/bin/env php
<?php
 
// Enable error reporting
error_reporting(E_ALL | E_STRICT);
 
// Get command line arguments
$userArgs = $argv;
 
// Check that an argument was provided
if ( !isset( $userArgs[1] ) ) {
    echo "\nNo path submitted: a path to a serialized PHP data file is required'\n\n";
    die();
} elseif ( '/' == substr( $userArgs[1], 0, 1 ) ) {
    // The supplied path is absolute
    $serializedPath = $userArgs[1];
} else {
    // If the supplied path is relative
    echo "\nRelative path supplied but not supported, please provide an absolute path\n\n";
    die();
}
 
// Get the serialised data for processing
$serialized = file_get_contents( $serializedPath );
 
// Unserialize the data
$unserialized = unserialize( $serialized );
 
// Print the data array in readable form
print_r( $unserialized );

Then you should be able to use it like this:

$ unserialize-php serialized-data.php

Tip: Fix Composer package 404 errors with continuous integration servers

Is PHP’s composer package manager pulling in dependencies successfully on your development machine but failing on your continuous integration server? In my case, Drone.io, the young, ludicrously simple CI platform, was failing in setup of a PHP project because of strange 404 “Not found” errors.

drone.io illustration

drone.io’s bug hunting, er, drone

The solution is to use a flag with your “composer install” command: composer install  --prefer-source

The explanation is that composer users GitHub’s API to fetch packages, and it uses it anonymously by default. Anonymous users have a strict call limit – 60 per hour per IP. That means that for a hosted CI, only 60 calls can be made to GitHub for potentially thousands of customers. When the limit is reached, GitHub returns 404 (not the most helpful error given the context).

Thanks to Pagoda Box for researching this solution.



phpList API sprint: results

The last two days I’ve been sprint-hacking the phpList public API. What is PHPList, why an API, and what is a sprint-hack, you may ask. The first is a Free Software MailChimp competitor established 10 years ago, and available to install or use as a service. The second is for calling phpList actions remotely (such as sending a newsletter), and for easy integration with other apps and websites. The third I guess you know: a hacking sprint is a short burst of effort to write or improve a project, typically (but not always) code.

phpList logo

Continue Reading


Set up a local web development server on Fedora 16 with Apache

The following procedure allows you to run your own webserver on Fedora 16, so that you can develop web scripts and applications and test them locally without an Internet connection. I assume that you’re using Gnome 3. Run the stated commands in a terminal – accessible via alt+F2, enter: gnome-terminal [press enter]

Login as root:

su

Install the Apache webserver:

yum install httpd

Configure Apache to handle requests to your local website:

nano /etc/httpd/conf/httpd.conf

Navigate to the end of that file using your arrow keys, or the page down button, and add the following text at the bottom. Replace the text in {} with whatever suits your setup

<VirtualHost *:80>
DocumentRoot {PATH TO YOUR WEB FILES (THE SPECIFIED FOLDER MUST EXIST), E.G.: /var/www/mysite}
ServerName {ADDRESS TO ACCESS YOUR WEBSITE IN A BROWSER BY, E.G.: local.mysite}
</VirtualHost>

The actual text that you add might look like this:

<VirtualHost *:80>
DocumentRoot /var/www/mysite
ServerName local.mysite
</VirtualHost>

Save and close the file:

ctrl+x [enter]

y [enter]

Configure your hosts file to route requests for your website to Apache:

nano /etc/hosts

Add to the end of this file the following text:

127.0.0.1   {ADDRESS TO ACCESS YOUR WEBSITE IN A BROWSER BY, E.G.: local.mysite}

The actual text that you add might look like this:

127.0.0.1    local.mysite

Save and close the file:

ctrl+x [enter]

y [enter]

Restart Apache:

service httpd restart

Your website should now be accessible in a website via whatever address you specified above, e.g. local.mysite (note not www.local.mysite).

(Optional) Configure file permissions:

If your website is still not accessible, you may have a file permissions issue. You can temporarily disable selinux to see if that is causing the problem. If that doesn’t help, you can use a permissions debugging tool to find problems with your UNIX file permissions.


Install zip module php-zip on Fedora 16

Due to an issue with the packaging of zip functionality within Fedora’s PHP package, the yum package php-zip, which was available for Fedora 15, is not available in Fedora 16. This is actually a “feature”, not a “bug”, but either way, getting zip support in PHP now takes a few extra steps.

1. Install dependencies as root or using sudo:

yum install pcre-devel gcc zlib zlib-devel

2. Install zip module using PECL (PEAR‘s sister):

pecl install zip

3. Edit the main PHP configuration file to register the new module. Add this text:

extension=zip.so;

a few lines before this:

Module Settings

in /etc/php.ini, as root or using sudo, like this:

nano /etc/php.ini

4. Restart your web server as root or using sudo:

service httpd restart

5. Check that support is enabled using phpinfo(). You should have a section on your phpinfo() page that looks like the image below.

Screenshot of zip support shown on phpinfo() page

Zip support confirmed by phpinfo()

That’s it, good luck 🙂