bill

Mike, petulant-level was set correctly ??
I went back and looked at the code for each and you’re right, b2 doesn’t declare a doc type. It also doesn’t break in my RSS reader either ?? You’re using RSS .91 and b2 is using 1.0. I added the following line to the output and it stopped the reader from complaining and it validated w3c (I wasn’t trying to validate the HTML, the validator validates the doc type which in this case is DTD RSS .91)
<!DOCTYPE rss PUBLIC “-//Netscape Communications//DTD RSS 0.91//EN”
“https://my.netscape.com/publish/formats/rss-0.91.dtd”&gt;
I literally have 40+ channels in my RSS reader and the Word Press one was the only one that caused it to choke before I added that line. I’ll admit, I’m no expert in RSS or even XML but I’m just relaying to you what did and didn’t work.
On the comments, now that you mention it, I didn’t do a file to file comparison. The files I looked at in b2 had comments (i.e. many of the files in the root dir) and I was mostly checking out the includes files in WordPress. Still doesn’t mean it’s right though ??
In regards to the list issue, I don’t think you’re going to convince me on that one, yes, it’s a list but that’s what arrays are for. If it’s a list pass it back as an array and then let the presentation layer deal with it. By passing it back with the “li” tags already there you’re taking away the ability of the presentation layer to deal with it. What if I want the categories to go horizontal across the top? What if I’m writing an add-on to WordPress and now I have to essentially duplicate that function because it prints directly to the browser rather than just returning the data. Presentation should be in one level and data access/manipulation/business logic in another. The moment you start mixing the two it’s hard to ever pull them back apart again.
Mike, on the Smarty templates, I think I may have been a little confusing in my comments. Smarty is a good choice but my point was .71 or .72 would have been a more convienent (for users) choice for deploying a template engine. From a user’s perspective, let’s say I started with b2. Then I migrate to .72 and I have to change my code because some functions don’t work they way they did in b2. But, I’m cool with that because I’m changing forks in the project so it’s to be expected. But then . . . when? . . . .73?, .74?, 1.0? is the big Smary change coming and I have to re-write all of my formatting yet again? I’ve seen other open source projects shoot themselves in the foot with this. Developers come along and say “hey cool, I’m going to add this feature and that feature and release them as add-on modules” and then you release the next version of the software and functions return different values than they did in the last release and/or some functions don’t exist at all. So the developers piss and moan and bit and some re-write their stuff and on the next release changes break their stuff again. By this time people are tired of having to support a bunch of angry people who’s add-ons don’t work because the core API’s keep changing.
If this was a closed source offering like Blogger or RadioUserland that’s a little easier to deal with. But by virtue of being open source you’re inviting others to contribute. Perhaps not to the core application but one would think that you would welcome other developers writing applications that plug into the framework you’re building making the end result more robust. If the framework keeps changing
Regarding the trackbacks, comments, etc, let me offer an example:
This is the query in b2trackback.php
$queryc = “SELECT * FROM $tablecomments WHERE comment_post_ID = $id AND comment_content LIKE ‘%<trackback />%’ ORDER BY comment_date”;
Now, MySQL is a great db and she’s very fast but wouldn’t a more efficient and more scalable query be:
$queryc = “SELECT * FROM $tabletrackbacks WHERE trackback_ID = $id ORDER BY trackback_date”;
You’ve eliminated a LIKE query and you’ve moved this data into it’s own tables which will make queries on it faster than if you have to query comments and trackbacks.
I’m not talking about changing the presentation of the data, only the way it’s stored and thus the part that limits how scalable the application can be. If you’re thinking that the performance improvement would be minimal, you’re probably right on a small to medium sized site but on larger sites you take it where you can get it and this seems like a pretty easy one.
Also, another idea that I had that I thought I would throw out . . . I think one of the selling points of b2 was that you didn’t need to publish the site. Having run some sites that see a lot of traffic, publishing isn’t a bad thing if done correctly. For instance, why can’t you index.php be a file that the admin dumps a current verion of the site into every time there’s an update? That way the only dynamic calls you have to make are to the comments, trackbacks, and pingback link totals rather than pulling up a fresh copy of the site every page view. Obviously most people will be able to get by just fine being fully dynamic but having that as an option might be a pretty cool feature for someone who gets Slashdotted. ??
Lastly, I hope none of this has been taken as anything other than constructive feedback. I’m not offering my opinions because I think you’re wrong and I’m right, I’m offering them because I think they might be helpful. Sure, not having a trackback table isn’t going to kill you but, hey, it’s a thought, right?

I’m using the version downloaded from:
https://www.ads-software.com/beta/wordpress-072-beta-2.tar.gz
which is listed as being pretty solid. I had installed b2 and really liked it and then found out about this fork and installed it over b2. Luckily, I had not posted anything yet because it fried the few test posts I had put in but . . . you know, it’s beta software so if it had been important I should have backed up the db (Linux RH9, MySQL4, PHP4.x, Apache2).
The b2rss.php simply didn’t validate. I had been testing out b2 with an RSS feed reeder called Sharp Reader and it was working fine. I installed WordPress and it started telling me it couldn’t read the file. So I attempted to validate the document via w3c and it said it couldn’t validate it because there was no document type. I inserted the document type as the leading line of output in the b2rss.php file and it then validated fine.
From searching here on the site (after finding out the documentation was out of date <g>) I discovered that the syntax for including links to trackback and pingback was different. I read the suggestions here and the closest I could come to making anything work was that both backtrack and pingback would report the same number of backtracks and pingbacks as the number of comments and that when you clicked on either of those links you went to the comments page with no reference to pingback or trackback links. I tried using comments_popup_link() as suggested and replaced teh comment var with trackback and pingback calls (which was what was suggested on this forum if simply activating pingback and trackback didn’t automatically generate them) but not much help.
Like I said, nice little package but I don’t have time to debug it. I thought I would throw this out there to you in case you haven’t run into it. Actually, I don’t have time to debug it because there’s no comments in the code and what documentation exists is out of date leaving me the options of learning exactly how the program works down to the last detail or bailing on it and going back to b2 for now. ?? I’ll come back to it once you guys have got it out there in production environments and I have the time to play around with it.
If you’re open to some notes, here’s mine:
1. I’m not a huge fan of some of the architecture decisions between b2 and WordPress. For instance that archives and categories spit out the html without returning that level of control back over to the calling function seems odd. I didn’t want to have an ordered list (i.e “li”) for those two items yet my only option was to go in and hack the main code because instead of returning an array or even a string with the html in it, the html is spit out by the function itself. I mean, at least give me the option of doing this:
$this_var = somefunction();
$temp_var = eregi_replace(“something here”, “something else here”, $this_var)
print $temp_var;
I guess I could just buffer the output and do some regex’s on the buffer but who wants to do that? Data and format should always, always, always, always be independent of each other. I mean it would have been just as easy to create a ordered list function that you pass an array to and it returns an ordered list.
2. You guys might want to consider using some more common fonts in the default install. Not for nothing but Georgia, “Times New Roman”, Times, serif sucks as a default ?? At least on my computer I can’t tell the difference between a zero and a lower case “o” when typing in text boxes in the admin area which always makes me go back several times to check I have the appropriate value.
3. Comments, comments, comments. I know it’s beta code but somebody’s gotta be writing this and that person would probably benefit from a few comments here and there. At a minimum a single line or two describing what a function does would cut down dramatically on someone else’s time when they’re trying to help hunt down a bug.
4. You offer the option of upgrading from b2 but you don’t really carry over any of the settings from b2 which means that they have to all be set up again.
5. Conceptually, comments, trackback links, and pingback links are different things. They need to be pulled apart in the database.
6. I noticed that you guys were taking this in the direction of adding new functionality while trying to change the core architecture (or re-write the core architecture) at the same time. I would focus on one or the other right now with my preference being the architecture. If you don’t, you’re going to have changing function calls every release and you’re likely to piss off a lot of users who have to completely re-write their templates because you’ve decided that pingback_popup_link() can be merged into comments_popup_link() without including a backwards compatibility function. While such a choice may be the best decision going forward it does burden the users and if you can minimize that by doing one huge architecture release that reduces change in future releases you’ll be leaps and bounds ahead in terms of user loyalty.
Ahhh . . . I think that’s it from the 2 or 3 hours I spent playing around with it. Despite my critiques I really like it and I think it has a lot of potential but I just didn’t have enough time to want to figure that stuff out at the moment.