Playing With Sharp Objects

My recommendation right now is that the default table names be used until the multiuser support is available. The changes required to support multiple users are very challenging for me, due to a number of factors...

First and foremost, I'm just now starting to pick up on the more advanced features of mySQL - I have until now gotten away with not using things like JOINs but I need to quickly learn how this can help my system. Being able to do these things in one atomic query rather than a bunch of different queries aided by some PHP will make things faster and more efficient, since mySQL is designed to do all that data sifting for us.

There are also a number of places in the code that reference things like items.id and feeds.id that should really be items.item_id and feeds.feed_id to help me use those higher level functions. This means that I must now go back through all the code and replace instances of "id" with the correct one so that column names match when I try to do a JOIN - that is lot of code to go through while not breaking anything.

Some of this recoding is due to my lack of functions for handing these individual tasks, which makes it easier for me when I'm coding the first time since I have to plan less, but harder when I have to go back into the code, which means more wasted time in the long run. So, there needs to be some smarter coding on my part.

Once this new version is ready, I'll release it as 1.0 with as much of the code cleaned up as possible and the start of modular style templates so that people can make their feed reader unique for their community.

The good news is that as of just now the multiuser support is in. The bad news is that the hard coded "items" and "feeds" are everywhere, though I have most of it out, so it should not be too long before I have another tarball that will be free of the hard coded entries.

There will be database changes with this newer version, so I will be sure to put a warning in the next post about that. I'll need some extra testing time in here before I risk everyone else's database.

More coming soon.

Thanks for the quick response. The heart surgery sounds interesting. I'll fix it myself if I can, if not I'll wait for the multiuser version.

Paul,
Thank you very much for bringing this to my attention. It was replete with hard coded 'feeds' and 'items' thanks to my sloppy coding practice. I've replaced it in a number of spots, but likely it's not the only place where it's hard coded. I'll try to go through it this weekend, but I won't be able to get a tarball out yet since I'm still breaking MonkeyChow to get the multiuser support in. We're half-way through heart surgery so it's too laet to turn back. =-)

It looks like init.php is hard coded as well.
$sql = "select aging from feeds where id='$id'";
$sql = "delete from items where `feed_id`=$id and `star`!=1 and `read`=1 and to_days(CURDATE()) - to_days(`timestamp`) > $keep_days";

I'm using the 9 November tarball

Paul,
Good catch! I'll get this in for the next release, which will include multi-user support. Coming soon...

I am using a custom prefix in my install ("wp_mc_") and got the error Creating indexes...
Can't create index. Mysql says: Table 'user763_blog.items' doesn't exist

In install.php line 135 I had to change it to
if(!fof_do_query("ALTER TABLE `$FOF_ITEM_TABLE` ADD INDEX `feed_id_idx` ( `feed_id` )", 1) && mysql_errno() != 1061)

similar for line 140

the items table name is hard coded in those lines instead of taking the value from config.php