It’s been nice getting wide and praising notes, comments, trackbask about the new Feed2RSS— I must admit being eager to rush it out and while the MagpieRSS seems to be running smoothly, I had a few minor goofs that others have nicely pointed out.
If you started using the new version or have downloaded it, you may want to get a fresh copy especially for the build.php and the feed2js.php files.
I did find that I had a goof where some of the build scripts were generating “html=1” for the NOSCRIPT option when really it needs to be html=y. I wavered between using “y”/”n” for vairable values versus 1/0 and forgot to get all of them in synch. Check any of your newly applied NOSCRIPT script calls to make sure it ends in html=y.
Gerry Paille kindly noted that there was a better way to deal with PHP sites where register globals is turned off, rather than fetching from the GET array into my desired variable names (lots of if-thens), just doing one command:
takes care of it nicely, loading all script parameters into local PHP variables with the same name as sent via the GET method call. This is rolled into both scripts. Gerry pointed out this reference which helped.
I am only a pseudo programmer, so I just keep pecking away until something works, and this works better (I think). I was abel to test on my G4 laptop running locally with register globals both off and on.
“Eugen” also wrote and indicated a problem with the build script not correctly sending the correct values for the targ variable (controlling how links behave). Doh! I had some flawed logic in the build form, now fixed.
be represented as:
which just does not work, as the PHP script ends up getting variables named
etc. I do not know enough or understand how to send an HTTP paramater that does not use expected notiation of &var=value&var=value&var=value
More doh! D’Arcy just ichatted me in the middle of a dull meeting (bless wireless)- with a parse error on line 100- it was a missing semi-colon on the end of line 97. Just uploaded a replacement.
— King of typos
I have the script working properly at:
Check the source out there, though it is essentially the same as described above by Allan.
It seems to be working fine, and is validating properly as well (click on the valid XHTML link at the bottom of the page).
It seems to be working for me at http://idea.matc.tec.oh.us/feeds –thanks for your work! I need to look into the cache settings because I’ve had it up for about a day and I don’t see any files in my cache directory.
Also, my blog doesn’t publish date with dc but uses pubDate; got any hints for fixing that 🙂 ?
Todd, Magpie creates cryptic named cache files, e.g.
but I am not sure how/when it decideds to create a new one. It looks like they each correspond to a different RSS URL.
I am not sure how you are trying to view the files, it may be they are hidden becaise of their naming style? I’d have to investigate to see why it would not be writing files. If you are not getting PHP errors than it must be dealing with write permissions okay.
As far as the way the date values are accessed, this is the beauty of Magpie- no matter what XML tag is used to define the date (pudDate, dc:date. etc) Magpie finds it and returns it to an array always named dc:date– it does not mean that your pubDate values are ignored, they are just referenced by a different name later. This way, my script does not have to do all kinds of branching depending on the RSS feed type.
I have tested this on RSS 2.0 feeds that use pubdate and it works as advertised.
I haven’t installed these latest versions yet, but on the first version, I couldn’t get the cache to work until I created a directory called “cache” (not “cached”) with the right permissions (775 should do it by the way, not 777).
Also, although the code seems to support it, I’m not seeing etags coming through. This is a critical bandwidth saver.
Oh, and those long, convoluted strings for file names look like MD5 encodings of the url requested. It’s a guaranteed way to get a unique id.
I’ve not run into an issue with Magpie needing a specific name for the cache directory/ It looks like it tries to create on named “cache” if is not defined, but my tests show ti writing to ones name “cached”– though it would not hut to suggest the default name.
As far as permissions (which I am hardly a master of mostly a slave), it may vary depend on how servers are set up and wether the process that runs the server is consider a “group” owner. The code comments read:
” * MAGPIE_CACHE_DIR – Where should Magpie cache parsed RSS objects?
* This should be a location that the webserver can write to. If this
* directory does not already exist Mapie will try to be smart and create
* it. This will often fail for permissions reasons.”
I usuallly go 777 for places my webserver needs to write to. But I cannot say I tested with 775.
And I would need to know more of what an “etag” is to comment. I would prefer not to try and do wild parsing on different versions of RSS feeds…
I am not getting anything written to the “cached” directory either. I have tried using David’s suggestion by renaming the directory to cache and double checking the permissions. I also deleted the “cached” directory all together to see if Magpie would create a new directrory and it did not.
I have the cache working, but I’m not 100% sure what I did that caused the change. I think it is pretty much as Dave described above. I changed the name of the directory from cached to cache and edited the feed2js.php file to reflect the name change. The permissons for the cache directory look like this:
drwxrwxrwx 4 admin admin 136 31 May 13:39 cache
I will have to dig deeper in the cache directory issue– But I have it running fine writing a directory named “cached”:
but it looks like fomr Gerry and David’s case a better suggestion is one named “cache”.
A first thing to try would be to turn on the Magpie debugging, set to “2”:
// value of 2 optionally show lots of debugging info, 0 for production
Another issue is that I thought one could use a relative path- you might try an absolute path for MAGPIE_DIR. If the relative fails, Magpie creates the one called “cache” which might explain your situations.
// Path to cache directory (must be writable permissions CHMOD 777)
// The simplest is a directory inside the location of this file
// define(‘MAGPIE_DIR’, ‘./cached/’)
Also try using the magpie_debug.php script provided to test your settings as well.
Comments are closed.