5.20 Bug: Categories(FIXED)

RCA · October 2nd, 2005, 11:01 AM

Some user albums and blank categories are added in main index.
Upgraded to build 5.20 9/29 but albums are still there and there is no way to remove reediting albums (or deleting if empty).

Michael P · October 2nd, 2005, 11:16 AM

Do you have a link I can look at? Might help to have phpmyadmin and an admin login to your site to take a quick look (if you dont mind PM'ing it to me).

RCA · October 2nd, 2005, 11:43 AM

I revised tables and categories and everything is set correctly, problem is with cache (catcache).

Michael P · October 2nd, 2005, 06:37 PM

I modified useralbums.php in the current build to include code to update the category cache when an album is added/deleted/removed; maybe this was the problem?

RCA · October 2nd, 2005, 08:37 PM

yes, uploaded new useralbums.php with cache update code, edited an album and problem is solved, no more albums showing as cats under index page.

Michael P · October 2nd, 2005, 08:38 PM

Excellent! Thanks for your help.

Axe · October 6th, 2005, 11:36 AM

Just a tip.

If the archive has been updated since 9/29 to reflect new files, Update the download page so that it doesn't say 9/29.

I downloaded on 9/29, setup from that, the download page STILL says 9/29 with the same version number, as though nothing has changed.

Apparently, things have changed.

So, please update the date or the version number to reflect that something is different. It's not difficult to add a .1 or .57 onto the end of "5.2"

Chuck S · October 8th, 2005, 08:25 AM

Axe

The build date was updated on 9-29 when this was fixed at 1:49PM. Useralbums.php was one of the new files

PhotoPost 5.2 Upgrade Information (updated 9/29/05 1:49 PM)

Axe · October 8th, 2005, 10:24 AM

Well, I dunno then, cuz I downloaded 5.2 (with many many files inside it dated 9/29), and when redownloaded it on 10/6, things were different. The original poster in this thread said in his first post that he'd upgraded to 9/29 already.

Where there two updates on 9/29? Were there fixes added since its initial release on 9/29?

Sorry, just almost all other software I've seen, even if there's just one line of code changed, they've incremented something on the version number x.x.y (usually the y part) to easily show it's a different version.

Chuck S · October 8th, 2005, 10:37 AM

useralbums fix in this thread was applied on 9-29 at 1:49PM at least thats what I show.

If bugs are reported we fix them immediately so new users downloading are not affected by the same bug. We then list the bug fix in the thread just like other companies.

Let's compare. At Vbulletin they list the bug fix and state you can apply that yourself or you can choose to wait a few weeks or a month till they issue a dot release. I know I own a copy of VB and have had to apply many fixes this way instead of waiting. Only thing we do different is we ensure the current build is fixed.

Axe · October 8th, 2005, 11:12 AM

Sure, companies supply patches and fixes, but when they actually update the archive, they increment it somehow, or append the filename with the actual date. They give some indiction so you know EXACTLY which version archive you have downloaded.

The changelog file in the current archive hasn't even been updated. The file is dated 9/27, and has no mention of the 9/29 updates.

Chuck S · October 8th, 2005, 11:37 AM

Well we do it differently as we choose not to have customers repeatedly download a build with known bugs.

What your saying is correct vbulletin allows new customers and old customers to repeatedly download a build that has known bugs. They then issue a dot release weeks later and notify customers. IMO thats a wrong philosophy. Weeks or well over a month can go by with thousands of customers affected with the same bug and new ones downloading the same bug over and over and new support threads on the same issue over and over.

We do the same thing with one exception. We fix the current build with any bugs reported. Once we issue a dot release just like them the build date is updated and the version number incremented and an email sent out.

There is nothing we do differently except make sure new customers and old customers alike are not redownloading the same bugs over and over after they are fixed and reporting the same fixed bugs.

Personally as a customer of all our products I like the way we do things better. Just something to ponder.

Axe · October 8th, 2005, 11:50 AM

Yes, the vBulletin philosophy is wrong, that's why I don't use vBulletin

phpBB, on the other hand, an opensource project, that does not make money from the people who use their software.

If we set aside the fact that there are always problems popping up with phpBB

whenever a bug is made public and fixed, the modifications are posted to the forum (as they are here), a new archive is created (as it's done here) and the version number is incremented to indicate that something has changed.

I admire your reasons for patching and allowing the new fixed versions to get out there as quickly as possible, I can totally understand the way you do things and why. But it'd just be nice for it to be a little easier to distinguish what version (and which revision of that version) you're actually running.

I posted two bugs on October 3rd, which are apparently fixed if you download 5.2 right now, but there's no mention of it being updated since 9/29 on the download page - which gives all those people who downloaded pre-bugfixes no indication that their copy still has bugs/typos/whatever - and nothing in the changelog.

Chuck S · October 8th, 2005, 12:09 PM

Well I am pretty familiar with phpBB and there philosophy is the same as Vbulletin or any other company. There was 3 weeks between one release and the next in which time new users are running and downloading the same buggy version until the announcement over 3 weeks later

EXAMPLE

2.0.17 was released July 19th

2.0.16 was released June 27rd

We operate the same as these companies putting out dot releases with announcements to all users with the one exception that we actually fix the current build for new downloads when a bug is discovered.

Axe · October 8th, 2005, 12:54 PM

But then you end up with 50 different files out there all called photopost52.zip...

*sigh*

You just don't get it...

never mind.

Johnny Doomo · October 8th, 2005, 01:07 PM

I agree with Axe, I too am having trouble tracking down which "5.2" version I have, if the software was tracked specifically, you could easily track what version you had and see if there was a newer version with bug fixes in the download section or even track which fixes you need by stating that it was a fix that would bring 5.2 to 5.2.3.

It would really make it a lot easier when you download the latest version only hours or even days after it's released... since that's when most of the bugs are found and or fixed.

Just my opinion, your company, just a suggestion from users having troubles with the way the fixes are being outlayed.