PHP – Page 5 – Weapon of Choice

2014-05-312021-09-26

How to workaround the Same Origin policy

How do you programmatically import stuff from a web page on another domain? I have this problem from time to time, mostly when I want to try something in JavaScript without worrying about deploying a proper setup. And recently I had this problem once again. And once again I hit the Same Origin policy thick wall.

Recent browsers support CORS, but for fiddling with a third party page you can’t reasonably ask their owners to ask their hosting providers to allow requests from your domain of choice, like jsfiddle.net, so your only chance is JSONP. And when you look around for a solution involving JSONP and Same Origin policy, you inevitably find YQL, used as a proxy.

{[ .yql-select | 1.hilite(=mysql=) ]}

YQL, which can act as a free proxy by using a simple query, is very attractive. If you are lucky, you can find some example of how to use it with jQuery. So, after some programming work you get to a nice jQuery plugin, like this:

{[ .proxyGet | 1.hilite(=javascript=) ]}

A little diversion. Disco-tools is a European effort for putting order into the messy terminology used for skills and competences, only made worse by so many different languages used for European CVs. So they decided to publish a nice thesaurus of all possible skills in the world, properly translated to many languages. Now at version 2, you can browse the thesaurus like a tree. If you look at the network traffic while clicking around, you will notice that some ajax calls are issued to get a piece of subtree like this (source view):

{[ .disco-source | 1.hilite(=javascript=) ]}

Then you could want to use my nice jQuery plugin for getting cross domain stuff using YQL. Notice that disco-tools.eu is very messy. They return a JSON object but send a wrong (text/html) Content-Type. We then need further filtering here because YQL seems unable to refrain from honoring the received Content-Type and always “corrects” the response by enclosing it into the body of a fictitious HTML page. So you’d get to something like this:

{[ .yql-usage | 1.hilite(=javascript=) ]}

For some vanilla JSON objects, the provided filter is enough to extract the good JSON part. But sometimes, like in this case, the wrong Content-Type clashes against the unescaped HTML special characters in the complex JSON object, and YQL’s “correction” is even much broader, because it absolutely cannot stand author’s errors. So you’d get to something like this:

{[ .yql-result | 1.hilite(=html=) ]}

In the above snippet I had to color it like HTML, which is how YQL thinks it is. For example, you can see that all open HTML tags get properly closed.

THAT IS EXTREMELY HARD TO FIX IN GENERAL !!!

I had no other choice but to deploy my own proxy and give up on YQL.

{[ .my-proxy | 1.hilite(=php=) ]}

And use it like this:

{[ .my-usage | 1.hilite(=javascript=) ]}

to get the same result the browser would get:

{[ .my-result | 1.hilite(=javascript=) ]}

2011-11-092018-06-06

Late Static Binding Example

Example

class A
{
    static public $data = 'A';
    
    static public function set()
    {
        //self::$data = '--'; //normal binding
        static::$data = '--'; //late binding
    }
}

class B extends A
{
    static public $data = 'B';
}

class C extends A
{
    static public $data = 'C';
}


echo A::$data, B::$data, C::$data;
C::set();
echo A::$data, B::$data, C::$data;

normal binding

ABC--BC

late binding

ABCAB--

2011-08-03

How to fix a preg_match bug

This is the second time I try to fix the preg_match bug with a number 50887. The first time I tried it, less than two months ago, my solution was buggy too, and for this reason I have unpublished it.

There are many different scenarios that I didn’t take into account, but almost all of them were related to How to count expected matches of a PHP regular expression. The rest were essentially the same: I thought that the preg_match bug was affecting just the last optional match. Later I found instead that it affects really all the matches at the end, any number of them, be they optional or not. Due to this little misunderstanding I had to rewrite a big portion of the function.

{[ .fix | 1.hilite(=php=) ]}

For the function ando_preg_count_groups(…) see the post How to count expected matches of a PHP regular expression.

Minimal Tests

Test 1a

{[ .test-1a-program | 1.hilite(=php=) ]}

In the next comparison we see the same result, and it really is, because
the count of expected matches equals the count of returned matches.
Array
(
    [0] => Saturday
    [DN] => Sat
    [1] => 
    [2] => 
    [3] => 
    [4] => 
    [5] => Sat
)
Array
(
    [0] => Saturday
    [DN] => Sat
    [1] => 
    [2] => 
    [3] => 
    [4] => 
    [5] => Sat
)

Test 1b

{[ .test-1b-program | 1.hilite(=php=) ]}

In the next comparison we see above that the bug applies to all the matches at the end,
and below that my fix correctly returns all expected matches, including the empty ones.
Array
(
    [0] => Tuesday
    [DN] => Tue
    [1] => 
    [2] => Tue
)
Array
(
    [0] => Tuesday
    [DN] => Tue
    [1] => 
    [2] => Tue
    [3] => 
    [4] => 
    [5] => 
)

Test 1c

{[ .test-1c-program | 1.hilite(=php=) ]}

In the next comparison we see above the bug at its extreme,
and below that my fix works as well as in the other cases.
Array
(
    [0] => 
)
Array
(
    [0] => 
    [DN] => 
    [1] => 
    [2] => 
    [3] => 
    [4] => 
    [5] => 
)

The following tests are based on $regex = ‘(?|Saturday|Sun(day)?)’;.

Test 2a

{[ .test-2a-program | 1.hilite(=php=) ]}

Array
(
    [0] => Sun
)
Array
(
    [0] => Sun
    [1] => 
)

Test 2b

{[ .test-2b-program | 1.hilite(=php=) ]}

Array
(
    [0] => Sunday
    [1] => day
)
Array
(
    [0] => Sunday
    [1] => day
)

Test 2c

{[ .test-2c-program | 1.hilite(=php=) ]}

Array
(
    [0] => Saturday
)
Array
(
    [0] => Saturday
    [1] => 
)

The following tests are based on $regex = ‘(?|(Sat)ur(day)|Sun(day)?)’;.

Test 3a

{[ .test-2a-program | 1.hilite(=php=) ]}

Array
(
    [0] => Sun
)
Array
(
    [0] => Sun
    [1] => 
    [2] => 
)

Test 3b

{[ .test-2b-program | 1.hilite(=php=) ]}

Array
(
    [0] => Sunday
    [1] => day
)
Array
(
    [0] => Sunday
    [1] => day
    [2] => 
)

Test 3c

{[ .test-2c-program | 1.hilite(=php=) ]}

Array
(
    [0] => Saturday
    [1] => Sat
    [2] => day
)
Array
(
    [0] => Saturday
    [1] => Sat
    [2] => day
)