patch for Dreamhost (and others?)

[Alper Çuğun]

Hey Drew,

Cool that you got hKit into a public repository. I had been
maintaining my own local version because Dreamhost does not support
allow_url_fopen.

Here's a patch which checks for either that or curl being present and
uses a suitable one (and runs the example.php on Dreamhost). Use it as
you see fit.

Best,
--
Alper Çugun


Patch:

Index: hkit.class.php
===================================================================
--- hkit.class.php (revision 10)
+++ hkit.class.php (working copy)
@@ -84,16 +84,21 @@
{
// pre-flight checks
$pass = true;
- $required = array('dom_import_simplexml', 'file_get_contents',
'simplexml_load_string');
+ $required = array('dom_import_simplexml',
'simplexml_load_string');
$missing = array();

- foreach ($required as $f){
- if (!function_exists($f)){
+ foreach ($required as $f) {
+ if (!function_exists($f)) {
$pass = false;
$missing[] = $f . '()';
}
}

+ if (!ini_get('allow_url_fopen') && !function_exists('curl_init'))
{
+ $missing[] = 'allow_url_fopen or curl_init';
+ $pass = false;
+ }
+
if (!$pass)
die('hKit error: these required functions are not available:
<strong>' . implode(', ', $missing) . '</strong>');

@@ -362,8 +367,24 @@
$url = $this->tidy_proxy . $url;
}

- return @file_get_contents($url);
+ $raw = '';
+
+ if (ini_get('allow_url_fopen')) {
+ // Returns FALSE on failure
+ $raw = @file_get_contents($url);
+ } else {
+ $this->curl = curl_init();
+
+ curl_setopt($this->curl, CURLOPT_URL, $url);
+ curl_setopt($this->curl, CURLOPT_HEADER, false);
+ curl_setopt($this->curl, CURLOPT_FAILONERROR, true);
+ curl_setopt($this->curl, CURLOPT_RETURNTRANSFER, true);
+
+ // Returns FALSE on failure
+ $raw = curl_exec($this->curl);
+ }

+ return $raw;
}

[Drew McLellan]

On Jan 12, 10:18 am, "Alper Çuğun" <alper.cu...@gmail.com> wrote:

> Cool that you got hKit into a public repository. I had been
> maintaining my own local version because Dreamhost does not support
> allow_url_fopen.
>
> Here's a patch which checks for either that or curl being present and
> uses a suitable one (and runs the example.php on Dreamhost). Use it as
> you see fit.

Hey Alper

Thanks for this - I committed an almost identical patch to SVN a
earlier this week. Great minds think alike ;)
I ported it from the version of hkit I've been running over at
microformatic.com for a few months.

I've made curl the default method, where available. This also means we
can take advantage of the CURLOPT_FOLLOWLOCATION option, so that hkit
can follow HTTP 30x redirects.

I'm not sure if there's a way to subscribe to a feed of SVN commits.
Perhaps I should get the commit emails sent to another list (like hkit-
commits?) so people can subscribe to a feed of that.

drew.

[Alper Çuğun]

On 12 jan, 23:45, Drew McLellan <drew.mclel...@gmail.com> wrote:
> I've made curl the default method, where available. This also means we
> can take advantage of the CURLOPT_FOLLOWLOCATION option, so that hkit
> can follow HTTP 30x redirects.

Nice. Shame I missed it.

Next up I'd also like to tackle the multiple instantiation problem,
unless you have a fix for that lying around as well.

best,
--
Alper Çugun

[Drew McLellan]

On Jan 15, 10:39 am, "Alper Çuğun" <alper.cu...@gmail.com> wrote:
> Next up I'd also like to tackle the multiple instantiation problem,
> unless you have a fix for that lying around as well.

That'd be great, Alper. I have nothing underway for that, and it's a
big issue. (Although I don't think it should be too hard to solve,
fingers crossed.)

drew.

[Alper Çugun]

On Jan 15, 2008, at 12:28 , Drew McLellan wrote:

That'd be great, Alper. I have nothing underway for that, and it's a
big issue. (Although I don't think it should be too hard to solve,
fingers crossed.)

I've got a preliminary patch which solves the big issue as seen here: 

http://wordpresstest.aardverschuiving.com/hKit/hkit-read-only/test-multiple.php

using a method described here: http://www.achievo.org/blog/archives/46-Mixins-in-PHP.html

It's not really finished because I have not made some design decisions yet which I didn't think were mine to make. (hCard is hard coded on a couple of places and that should be refactored.)

Curently both getByURL and getByString take a $profile argument so if you would call them subsequently they would either try to load the same profile twice or try to load different profiles into the same hKit class. It is probably possible to make that work by resetting the class before loading a profile etc. etc. but it is definitely not the most maintainable solution.

A better solution would be, I think to give hKit a profile on instantiation and not have it be changeable after, like:

$hCardParser = new hKit('hCard');

but that would change the interface of the library. Another halfway solution is to have the loadProfile check if it has already loaded a profile and if so, not do anything.

Suggestions?

[Drew McLellan]

Hey Alper

Sorry for the delay - thinks all blew up yesterday with another little
project I work on :D

If we need to change the way hkit is called in order to sort out this
profiles problem, then this is a good point to do it at. However, we
should take into consideration both the case of multiple instances of
hkit and reuse of the same instance.

If you've found instances of hCard-specific stuff that should be
removed, that's great - could you point them out?

I had a read of your post - the mixins stuff looks cool. However,
let's not use a sledgehammer to crack a nut here. If the problem can
be solved simply then it should be. I've not yet looked at it myself,
but I shall this week. (I also have a patch from Gareth that I need to
look at merging in.)

It's far easier for us to change how hkit is called than to change the
output. Typically people will call hkit in just a few places, so those
are easy bits of code to update, whereas code parsing the output tends
to be way more involved.

drew.

On Jan 21, 2:39 pm, Alper Çugun <al...@alper.nl> wrote:
> On Jan 15, 2008, at 12:28 , Drew McLellan wrote:
>
> > That'd be great, Alper. I have nothing underway for that, and it's a
> > big issue. (Although I don't think it should be too hard to solve,
> > fingers crossed.)
>

> I've got a preliminary patch which solves the big issue as seen here:http://wordpresstest.aardverschuiving.com/hKit/hkit-read-only/test-mu...

> using a method described here:http://www.achievo.org/blog/archives/46-Mixins-in-PHP.html
>
> It's not really finished because I have not made some design decisions
> yet which I didn't think were mine to make. (hCard is hard coded on a
> couple of places and that should be refactored.)
>
> Curently both getByURL and getByString take a $profile argument so if
> you would call them subsequently they would either try to load the
> same profile twice or try to load different profiles into the same
> hKit class. It is probably possible to make that work by resetting the
> class before loading a profile etc. etc. but it is definitely not the
> most maintainable solution.
>
> A better solution would be, I think to give hKit a profile on
> instantiation and not have it be changeable after, like:
> $hCardParser = new hKit('hCard');
> but that would change the interface of the library. Another halfway
> solution is to have the loadProfile check if it has already loaded a
> profile and if so, not do anything.
>
> Suggestions?
>

> --
> Alper Çugun
>
> Mobile: +31-6-24553306 * E-mail: em...@alper.nl
> See my webpage and blogs at:http://www.alper.nl

[Alper Çugun]

On Jan 23, 2008, at 12:10 , Drew McLellan wrote:

Sorry for the delay - thinks all blew up yesterday with another little
project I work on :D

np

If we need to change the way hkit is called in order to sort out this
profiles problem, then this is a good point to do it at. However, we
should take into consideration both the case of multiple instances of
hkit and reuse of the same instance.

One basic questions needs to be answered first: Is it okay to instantiate an hKit('hCard') and use that only for parsing hCards and force users to instantiate other hKits for other microformat types (so no longer one instance that can do everything)?

If you've found instances of hCard-specific stuff that should be
removed, that's great - could you point them out?

I was talking about my current version of the patch. I haven't made things as generic as they could be yet. I will do that once the design decisions are final.

I had a read of your post - the mixins stuff looks cool. However,
let's not use a sledgehammer to crack a nut here. If the problem can
be solved simply then it should be. I've not yet looked at it myself,
but I shall this week. (I also have a patch from Gareth that I need to
look at merging in.)

I'm afraid that mixins in PHP are somewhat kludgy but somewhat cleaner than possible alternatives.

One such is the following:

hcard.profile.php contains class variables and functions. The loadProfile I implement reads both from the mixin class and makes them properties of hKit. Reading the class_vars is pretty straight forward, but putting the functions in place properly requires some extra plumbing (with the __call function miss method and lookup table).

Alternatively you could copy just the class variables to hKit and just keep the functions (they're static anyway) in hcard.profile global. You would just have to make sure they don't clash in the future. That's a mixed approach which is only marginally easier and not that much more maintainable, so I don't much prefer it.

Maybe I am trying to squat a nut here but in any other language you would use mixins (with a sane mixin pattern) for this task. If there is a better way to do it, I'm interested.

Best,