Layout Problem after 3.2.1 to 5.11 upgrade

[sonick]

Greetings,

First, the requested variables for posting support requests:

OS: Linux
Distro: Red Hat Enterprise Linux ES release 3
Kernel: Linux - 2.4.21-32.0.1.ELsmp #1 SMP - i686 athlon i386 GNU/Linux
PHP: 4.3.11
MySQL: Ver 14.7 Distrib 4.1.9, for pc-linux-gnu (i686)
Host Type: Dedicated
Server Ownership: Leased unit from monstercommerce.com, CoLo resident
Host and Site Admin: Myself
Gallery URL: http://www.cycleforums.com/photopost (Currently offline due to improper layout)
vBulletin Integration: Yes, vBulletin 2.2.8
Note: In order to view the gallery as it is currently, I will have to work with someone in concurrent communication to flip the board on/off so it can be viewed. I cannot enable the board for "a while" as the many users the site has will return and attempt to interact with it as usual. I require that the upgrade be working and complete before turning the users loose on it.

-
I am writing to report an issue discovered post-upgrade from 3.2.1 to 5.11. The upgrade.php mechanisms themselves were all performed without a hitch, 100% success rate from all operations during each stepped revision upgrade within the script. Once the final revision was reporting 5.11 and the upgrade.php output stated that the upgrade was complete, myself and the other root administrator for the site went to check the gallery to assure everything was working properly, and immediately we were greeted with a layout that was absent any visible table borders, font types and sizes were wrong, and various other layout options that prior to this version were set manually with the photopost 3.2.1 admin panel (ie: colors for various layout options express in hexadecimal, font names and sizes explicitly declared, etc.)

To summarize, absolutely everything that I am aware of is working properly EXCEPT the inheritance of our past layout design as was set in the previous 3.2.1 admin panel. Databases are all working fine, authentication is fine, headers are fine, footers are fine, ImageMagick operations are fine; everything EXCEPT the appearance as was setup prior through the 3.2.1 admin panel is working properly.

I have searched forums, support faq, code comments, etc. for the answer as to what I may be missing to get our prior look and feel into the current template system, but by this point the prior layout values themselves had been dropped from the database. I did save a copy of the prior values from database.settings from the old database, and of course I have a full backup of the 3.2.1 database as stood before upgrade to 5.11. It appears that in order to create a 5.11 stylesheet containing the values we used prior, the vbulletin integration has to be turned off. With vbulletin integration on, it appears that we need to somehow pull these values from templates in some fashion. Our site requires that the vbulletin integration be turned on; without the cross-authentication alone the big selling point for us on photopost a couple years ago would be rendered moot.

In final summary, I will say that I am a long-time UNIX and Network Admin, but I'm pretty green when it comes to layer 7 and the site code itself. I had expected that the current layout/cosmetic settings in the 3.2.1 database would be culled and somehow imported into the 5.11 environment; whatever mechanism that may be with vb2 integration enabled. If it was supposed to happen, it did not in our environment. Again, the upgrade.php reported 100% rate of success during each step (and there was a considerable number of steps). Prior to this, the software performed flawlessly, and I remain confident that this issue will be solved regardless of whether it's a shortcoming in such a large-step upgrade, or even if it's an egregious oversight by myself. I'd prefer the latter to tell you the truth, I'm perfectly OK with making a stupid mistake if it would get our beloved photo gallery back quickly! I would not have even upgraded to 5.11 if it hadn't been for the published vulnerabilities in the prior code, the functionality was still perfect for our needs. Since we're not yet on vb3 (what a nightmare that will be), a lot of the value-add from 5.11 is moot in our case. In any case, I'm glad to support the software and continue to run it if this layout problem can be solved. All I want is for our prior look & feel to operate properly in the 5.11 environment.

Any and all assistance and input is appreciated and will be taken into account. Sorry this post was so wordy, I don't want to miss any needed information and I have severe spaz/ADHD wordiness problems so it's inevitable in any case

Thanks,
Jayson
sonick@sonick.com

http://www.cycleforums.com
http://www.big-boards.com/highlight/279

[sonick]

Hmmmm, well I was playing around and just wanted to again verify that in photopost 5.11 when you select a stylesheet AND have vbulletin2 integration enabled, the style does not apply to the gallery apperance. In the vbulletin2 admin panel I can clearly see and even save the apperance settings (saves them as a .style file), the settings are saved at the top of this .style file and delineated by "|||" between each var. The problem is multi-faceted though:
A) One would have to know how to convert a vbulletin "|||" delineated data string to a valid stylesheet.
B) Even if I did make a stylesheet using this appearance settings data, the photopost gallery won't use the style selection when vbulletin2 integration is enabled.
C) If I turn off vbulletin2 integration to use the proper stylesheet and apperance, every bit of value-add for which I chose photopost in the first place, is negated.
D) I shouldn't have to even be thinking about this, because the upgrade script should have facilitated a proper transfer of apperance settings for use in a 5.11+vbulletin2 integrated environment! In 3.2.1 I was able to use vb2 integration IN ADDITION TO being able to explicitly set the apperance variables. Now I can't even select stylesheets that are applicable to the rendered page while vb2 integration is enabled... argh.

Also, for clarification, I did make sure that config-inc.php was properly compiled using a hybrid of all the relevant and needed settings from both the old 3.2.1 version and 5.11 version.

So, awaiting input. Thanks again for any/all help.

Thanks,
Jayson
sonick@sonick.com

http://www.cycleforums.com
http://www.big-boards.com/highlight/279

[sonick]

Well, it appears as if my only choice is to kludge every single style aspect into the default.css included with photopost 5.11, in order to get the old look and feel I had explicitly configured in the 3.2.1 admin panel.

Correct me if I'm wrong please.

If this IS the case, then that's hardly what I'd call a thorough upgrade, should not the upgrade script have culled all of the style settings and then built a new default.css in this fashion ? It looks as if the page is getting part of it's apperance settings assumed from the header.htm, and part of the settings from default.css. Frustrating!

[Michael P]

That is correct, we do not build a new stylesheet based off the old way of doing stylesheets. So you will need to change the default.css to use your old settings if you are not using your forum integrated stylesheets.

[sonick]

Scratch that, it's not even using default.css while vb2 integration is enabled. That or it's being overridden by settings coming from header.htm. It shouldn't matter what is in header.htm though, because the prior settings should have been imported into WHICHEVER mechanism is going to display properly post-upgrade.

[sonick]

Originally Posted by Michael P

That is correct, we do not build a new stylesheet based off the old way of doing stylesheets. So you will need to change the default.css to use your old settings if you are not using your forum integrated stylesheets.

Well, I just made most of the changes to default.css, and it's not even taking those changes so long as vb2 integration is enabled.

Further, as a photopost customer, I am disappointed that I was forced to PAY, to UPGRADE for the purpose of patching SECURITY HOLES in the code I'd already paid for. Then, grudgingly doing so, I now find that the apperance settings from my prior install were not culled and re-installed in the new version, and I am to manually pick and choose each appearance setting and place it into a style sheet (that right now doesn't work) ? Honestly, an "upgrade" process that doesn't transfer prior application settings is not even qualified to be described as an "upgrade". Photopost is the ONLY software in my extensive history that would ever purport to offer an "upgrade script", then knowingly NOT transfer across prior configuration elements, then willingly say "yeah, we left those out". My jaw is literally on the floor. The old settings weren't even dumped out to a TEXT file to make the admin aware of what just happened to the entire appearance of his gallery! There's not even a lonely little caveat in the upgrade script that mentions "hey, your apperance settings are being DROPped without archival, please account for this." This is a serious flaw guys.

Look, all I wanted was my gallery to not be vulnerable to sql injection code via URL manipulation of the photopost php scripts. That's ALL I wanted. Now, assuming that we can even get default.css to work properly with vb2 integration enabled, I am stuck doing tit-for-tat APPLICATION changes by hand ?

This is NOT the proper way to care for and evolve your software train. OK, so let's try and get default.css working; but let it be known that making a free BUGFIX available for those using older code would have been the industry-standard way of doing things.

Thanks,
Jayson

[sonick]

Just for clarification, this is not a matter of my vbulletin configuration not using stylesheets, that is a known CONSTANT that applies to vbulletin 2. The issue here is that I'm NOT using vBulletin 3, which seems to be lovingly adapted to in your new code, but 2 is just "eh, your settings got DROPped, yeah you need to build your own stylesheet". vBulletin2 uses "styles" and outputs a saved version as a ".style". There is no mention of stylesheets in vb2.x. (save the one in use for ./bbdir/admin/cp.css)." Further, default.css changes are still not taking when the 5.11 showgallery.php is rendered, or any other script for that matter. Building stylesheets and upgrading the core software are not even in the same REALM, why is this acceptable ? I don't know ANYTHING about html/php/css/etc., the last time I tried my hand at content, <blink> was seriously happenin' high tech stuff for your homepage. Why saddle me with this ??? C'mon now ! I fought tooth and nail to resist a strong urge by others to move to the GPL "coppermine"; citing photopost's code maturity (!) and respect in the industry. Don't make me look dumb!

Disappointed. Hoping for an examination of this oversight by the entire team, and some sort of positive action taken. Ideas on default.css not taking setting changes ? Editing ./ppdir/styles/default.css is not working...

[Chuck S]

Hello If you use vb2 header integration there is this in header-inc.php add the code in bold.

I beleive when the header-inc.php was updated the old link to use a stylesheet was dropped

Content visible to verified customers only.

[sonick]

That took care of a LOT of the formatting problems, now this I can live with.
My sincere thanks for your assistance.

I stand by my feelings on retaining/incorporating prior settings as a matter of proper upgrade methodology, but I'll just have to live with it. Something to ponder if you're so inclined. Vbulletin2 does not use stylesheets, so anyone that has vbulletin 2 is going to run into this issue after they upgrade. I know there are a good many vb2 users still out there because of huge databases combined with tons of installed hacks makes for a guaranteed painful upgrade.

Again, many thanks, this gets me far enough along I can kludge the rest by hand.

Jayson

[Chuck S]

Well the upgrade methodology does not have anything to do with VB2. The missing line I posted was just an oversight on the developers part since in the old old header include this was in there for vb2. Glad it helped.

Anyone who has a way way old Photopost ( we are talking 3 years ) before stylesheets and there are not many will have to modify a stylesheet when they upgrade as the two methods of defining colors are not compatible.

[sonick]

Originally Posted by omegatron

Well the upgrade methodology does not have anything to do with VB2. The missing line I posted was just an oversight on the developers part since in the old old header include this was in there for vb2. Glad it helped.

Anyone who has a way way old Photopost ( we are talking 3 years ) before stylesheets and there are not many will have to modify a stylesheet when they upgrade as the two methods of defining colors are not compatible.

Yeah, I'm learning now that I'm modifying default.css, why the two would not be easy to whip up a migration script. You could migrate some, but not all. I swear I'm not trying to be a nag, but I still think at least a one-sentence warning that prior versions that relied on admin settings to configure the cosmetic appearance, will not after the upgrade, and that a manual edit of the default.css will be necessary. If a warning were in place it would have saved me a bunch of time scouring every bit of code pretending like I know enough to find out wtf is happening, downtime of the gallery, and other little things. Not a big deal at all, just that a small warning would have helped exponentially to the amount of work it would take to include such a warning in the distro. I'm also a bit shocked there is not a CHANGELOG.txt, that may have tipped me off as well. Just trying to help anyone else in the future that may get stung..... I do know that I've been on 2.x far too long :\ The host is hardened very well, and a reflexive IDS is in place in case anyone tries to actually exploit vbulletin, but I'd still like to get the new code in. With the amount of hacks installed, it is going to be A LARGE TASK.

As far as the missing piece of code, I'd be a pretty big hypocrite to gripe about that. Just glad you were able to track it down. Thanks again !!!!

All in all, I am really happy with photopost, our users love it, and as you can see when I open the gallery in about 20 minutes or so (running backups, syncing images, etc.) if you go have a peek, it's a very popular feature on the board. Our ./ppdir/data directory is 1.2gigs and growing after 1.5 years in service.

Thanks again for your help Omegatron! Still a loyal photopost user in this camp thanks to the rapid response on the missing bit of code....

Best Regards,
Jayson
sonick@sonick.com

http://www.cycleforums.com
http://www.cycleforums.com/photopost
http://www.big-boards.com/highlight/279

[Chuck S]

There is a documentation folder with upgrade.txt and changelog.txt although it only goes back to 4.1

[sonick]

Originally Posted by omegatron

There is a documentation folder with upgrade.txt and changelog.txt although it only goes back to 4.1

Whoops, yeah I did see that, I must've meant prior to 4.1. BUT, what's done is done, it's working, and I remain loyal to photopost. I'll say this much.... I was HUGELY skeptical that the upgrade script would be able to make it through that many stepped revisions without some sort of critical oversight.... (just because SO many things can go wrong), but no, all of the critical operational stuff went off without a hitch. That is impressive. Anyway, now that my attention is off of the cosmetics, I'm really digging into the new options and finding a lot of them very intuitive on your part, and integrating them into our config.

Thanks
J

[sonick]

Wow, that's strange. I'm still playing around, added a tidbit to the header.htm, and noticed that it wasn't parsed. Assured my copy was fresh, cleared the php accelerator cache, cleared my cache, still not showing my changes to header.htm. Removed the path to header.htm ALTOGETHER from the config, cleared all cache instances of the file once again, and it still rendered the header. LOL. Obviously, the header from the FORUM is being displayed properly, but the header.htm in the ./ppdir is not being parsed. I didn't notice until now because they are identical; which was necessary in 3.2.1, it was required to copy the parsed html output of the header so it could appear seamless. Obvious that's not necessary now, as it's pulling it from the forum somehow.

So, this is my NEW question to you now omegatron...... can you find a reason why photopost5.11 integrated with vb2 would not be incorporating the code from header.htm into the rendered page ? All the paths/perms and all the basic stuff is covered, no worries as far as that goes, this is definetely another oddity.....

No biggie if you don't find anything, but it would help us for a couple disclaimers we need to add specific to the gallery only.....

thx
J

[sonick]

I just upgraded to 5.12. The code snippet in omegatron's post that goes in header-inc.php to permit vb2 integration to work properly, STILL was not integrated into the 5.12 code. I do appreciate the effort to get an independent analysis done on the code and a fix released, thank you! Just wanted to FYI on this since I'm probably not the only vb2 dinosaur....