Symphony.

Hi all. Like the subject line implies, my expectations are fairly low here!

I have a Symphony 1.7 site that was mounted in 2007. (Remember 2007?) It's a nifty little site, with some nifty things running, but it's just a personal journalling type site in specialist mode. Having said that, I don't use it a whole lot.

However, lately it's started throwing fairly hefty PHP errors. The host is now running PHP v. 5.3.14, and clearly old 1.7 runs some code that is now deprecated.

I'm wondering if anyone has updated Sym 1.7 for current PHP versions? Maybe? And if so, are you willing to share?

I live in hope (but not too much!). Thanks for any (and I do mean any) informed advice on this one!

Well, those are only warnings. If you put a

error_reporting(E_ALL & ~E_DEPRECATED);

somewhere in your code (never seen Sym 1.7 so, no idea where) they should go away at least for now.

As for the actual problems: PHP 5.x turned around the way references were being sent: Before, you'd do

function foo(&$a) {
   ...
}

foo($bar);
foo(&$bar);

Both ways of calling foo were allowed.

As of PHP 5.4 you're only allowed to call the function using

foo($bar);

That should solve 90% of the errors you're getting.

set_magic_quotes_runtime might be a much bigger problem as it changes PHP's behaviour all over the place, adding slashes to strings where it sees the need to do so. Maybe your site will still run if you simply remove the expression, maybe not. If not, the work required to fix it could potentially add up a lot as you'd need to find all the spots in wich the setting was taking effect.

I made a hotfix for Symphony 1.7 running on PHP 5.3 in class.general.php, but I forgot to document it (or use Git, stupid me).

If you send me your class.general.php, I will send you mine. :-)

You find my email address on my micro-website.

Thanks, both, for your replies!

@phoque - "...those are only warnings...": true! Fortunately the site still seems fully functional. Given some of the custom elements in it, it won't be getting migrated anywhere, so I'm keen for it to keep working! :)

@michael-e - would be grateful to see if your "hotfix" elminates these error messages before I start trying phoque's suggestions. I've put up a gist of the version of that file that I've got. I'll also shoot you a quick note, just in case you'd prefer to be in touch directly.

(I note the file header says: "This code cannot be modified or redistributed without permission." Can we assume permission has been given? I live in hope!)

I have taken a look at your version and my latest version of the file. Obviously I did two things to make Symphony 1.7.1 run on PHP 5.3 without throwing errors in the frontend:

1. I added php_value display_errors off to the .htaccess file, so in my case most of the errors are only written to the logs, but not displayed. You may as well have to change the providers's error settings.

2. I changed the in_array_multi function in class.general.php. I made it static, because it is called as static function, and I slightly reworked a condition inside.

My function looks like this:

static function in_array_multi($needle, $haystack){

    if($needle == $haystack) return true;

    if(is_array($haystack)){

        foreach($haystack as $key => $val){

            if(is_array($val)){
                if(General::in_array_multi($needle, $val)){
                    return true;
                }
            }elseif(!strcmp($needle, $key) || !strcmp($needle, $val)){ 
                return true;

            }
        }
    }

    return false;                   
}

Apart from this I only see changes to the email core function(s), which have been introduced very late to Symphony 1.7, as far as I remember. If you want to add these as well (or compare the file yourself), I have created a gist for you.

If you want to get rid of all warnings (instead of writing the remaining errors to the log exclusively, like I do), you will have to follow @phoque's advice.

P.S.: You are right concerning the permissions thing. But I assume/hope that Allen will grant permission. :-)

The file has been made publicly available years ago, so I guess you are fine: https://github.com/symphony/symphony-1.7/blob/master/symphony/lib/core/class.general.php.

Yes, I know. (This is why I assume that it's no problem at all). Still, for a lawyer this would not mean that we are permitted to make it public as well.

:-)

Well, other lawyers might argue that by posting Symphony 1.7 on Github the right of redistribution has been given – looking at their terms of service:

By setting your repositories to be viewed publicly, you agree to allow others to view and fork your repositories.

But of course I'm not a lawyer.

Maybe the Symphony team could clarify the 1.7 license or change it (maybe even move it to the official organisation and remove the symphony user)?

Updates: I applied those two steps from comment #5, alas! without seeing any difference to my output, so my guess is that your warning about my providers's error settings must be coming in to play here.

This probably means poking further along the lines that phoque suggested.

And seeing Nils' pointer to the code on Github, perhaps the best thing for me to do would be to fork that 1.7 code, and put my changes there (when I get time!), just in case this is any use for other 1.7 sites out there.

Would it be worth someone from The Team adding a note to the README about altering this code, as all the files have that same header:

###
#
# Symphony web publishing system
#
# Copyright 2004 - 2006 Twenty One Degrees Pty. Ltd. This code cannot be
# modified or redistributed without permission.
#
# For terms of use please visit http://21degrees.com.au/products/symphony/terms/
#
###

even though it is "publicly available"... There is no OS (or any other) license applied or identified, and the URL in that header gives a 404.

Edit: Composed while Nils was posting his reply in #9.

So the warnings are thrown to the frontend. Hmmm. You might try to copy some code from Sym 2 to 1.7., i.e. replace line 14 in /symphony/lib/boot/bundle.php with the following:

if(!defined('PHP_VERSION_ID')){
    $version = PHP_VERSION;

    /**
     * For versions of PHP below 5.2.7, the PHP_VERSION_ID constant, doesn't
     * exist, so this will just mimic the functionality as described on the
     * PHP documentation
     *
     * @link http://php.net/manual/en/function.phpversion.php
     * @var integer
     */
    define('PHP_VERSION_ID', ($version{0} * 10000 + $version{2} * 100 + $version{4}));
}

if (PHP_VERSION_ID >= 50300){
    error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);
}
else{
    error_reporting(E_ALL & ~E_NOTICE);
}

Regarding the licence: https://github.com/symphony/symphony-1.7/issues/1

Please don' worry, feel free to do what you wish. I'll look at amending the licence so it shares the same MIT licence as 2.x when I get a chance.

Just a bit of background: Symphony 1.x codebase started out as a proprietary and paid for product. It later adopted a freeware licence when 1.7 was introduced.

We didn't want to move to an open source licence before we had the infrastructure to accomodate a community of contributors. When we released 2.x, we also introduced a new website and officially made the transition over to Git. That was when we felt it was the right time to adopt the MIT licence.

@Allen - many thanks for this clarification; much appreciated! It would be great if the license was amended. This legacy code could then be updated in a more transparent way, to meet new standards in the underlying technology, thus providing a bit of future-proofing.

I've now made the relevant licence updates to Symphony 1.7. The project is now migrated to the symphonycms organisation on Github: https://github.com/symphonycms/symphony-1.7