I have now replicated the problem on fkelly.org. So that's two "independent" sites running on Raven's servers. I will make a note of this over in Mantis too. I have exhaustively compared the files and versions using Beyond Compare. Not to say I could not have missed something because we have thrown everything AND the kitchen sink into this distribution but if I made a mistake I sure replicated it.

I had several other feeds, like Nukescripts, running on the site, now they don't work either.

Humm. I will have a look at the blocks table.

So strange. Revision 1830 supposedly stopped content from being written to the blocks table. I just sat here and stared at what I have on my pc's svn and what is on the fkelly.org site. They are identical. They are revision 1830. Yet when I deleted all the old rss blocks and then put Velonews back in, the content field was being written out to the blocks table and the cache was not being updated. I just don't get it.

Time to drink.

I'll try and replicate this then using the SVN files as soon as I can to see if it is some quirk with the distro or server related.

I think that the file /admin/modules/blocks.php is not completely converted over.

If you look at the function BlocksEditSave there is logic to null out the variable $content that goes into the field content in the blocks table. That executes if the variable $url is not empty and that variable should tell us whether we have a rss file. However, there is no similar logic that I can see in BlocksAdd, instead it continues with the old approach of putting the rss data into the content field.

I'm not sure whether the intent is to create the cache data in blocks.php and if so maybe I am missing where it is created but I just don't see it. I haven't looked at the mainfile logic to see if it should create it anyway but that's not happening on my system.

I downloaded from SVN on a different computer where I test RN and did a comparison. I can't see why it stopped working, but I'll do an export from that SVN and test on a separate server when I get a chance.
_________________

I couldn't even create a block using the SVN files I downloaded a few days ago.
I think my internet connections dropping out so I may have a corrupt file or something grrrr.

I loaded the latest RN to a server and added an RSS feed from MontegoScripts.com with no problem. Were these new blocks, or existing ones?

In my case, I had the Velonews block working after new years. I tested several blocks on both my production (webmhcc.org) and test site (fkelly.org) and all seemed fine. Then a couple days ago (hard to pinpoint it) I noticed the Velonews feed wasn't working. Since then I haven't been able to get any feed to work on either site. I have deleted them and started from scratch several times over. I have tried every permutation I can think of.

And just as a reminder, while it may not be critical or part of the problem, when you create a new feed block it is writing to the content field of the blocks table. Probably no harm done but something we should clean up if time permits.

It looks to me like the cache is not getting written. It looks to me like there should be warnings emanating from simplepie.inc if cache is not writable and under several other error conditions. But I have not been able to narrow it down further.

(Guessing you're asking the same question, but....) If the script didn't change, what would cause the cause suddenly not be written? Did permissions or settings on your server change?

Regarding not being able to write the cache, when I originally tested it, my cache directory wasn't writeable - SimplePie simply reloaded the feed from the source each time. Maybe Guardian can test this by deleting the .spc files from the cache directory, and changing the permissions to prevent writing to the cache.

On the block content field, I thought we had the fixed, but I'll check and update SVN - thanks.

Funny...I forgot to make my cache directory writeable on the last test, and the feed worked fine. As soon as I made it writeable, the cache file was created.

Permissions on my server didn't change. As part of testing I even boosted them to 777 with no luck. I run on Raven's server and have noticed no other changes. I would guess that if he changed anything else it would affect more than just simplepie.

I can try the test you suggested too ... changing the permissions to prevent writing to cache.

I am wondering what the sequence of operations is within simplepie.inc. In other words, if you are using cache and you have a writeable directory will it write a spc file first and then read in the content from that on the first pass. It almost looks to me like the error I am seeing is being generated when the program thinks it has a cache file and goes to read from it and doesn't find anything. That's why I'm asking about the sequence and whether this all happens on one pass. I could see where a spc file would be created when the block is created and then updated periodically thru the simplepie include in mainfile but I don't see that initialization taking place.

OK. Adding a feed block no longer updates the block content field as of SVN build 1872. This build also corrects the feed preview by using the headlines function. All of these changes were made to admin/modules/blocks.php

Thanks. I will try it tomorrow. Have a good evening Kevin

Any chance I could compare the source I'm using with your test server?

PM on the way.