vBulletin stylesheets...

[dc_pitascii]

We have vbulletin forums running on one hostname (same domain), photopost running on another hostname (same domain), and a shared userbase and db for auth.

I've got shared cookies between them working. forums auth -> authenticated for photopost.

However, the vbulletin files (all) are effectively on another system.

I can copy whatever vbulletin files need to be references by photopost to be able to use vBulletin stylesheets.

What is a complete list of files and directories necessary from vBulletin, to have PhotoPost support the vBulletin stylesheets?

Thanks!

[Chuck S]

The enhanced integration requires that the vbulletin server path be available to photopost to work. If this is not available you can not use the enhanced integration and you can alter your stylesheet and headers to mock the look of vb

[dc_pitascii]

Originally Posted by Chuck S

The enhanced integration requires that the vbulletin server path be available to photopost to work. If this is not available you can not use the enhanced integration and you can alter your stylesheet and headers to mock the look of vb

So, if I want PhotoPhost to be able to use the enhanced integration feature, I necessarily must copy each and every vBulletin file from one service instance to another service instance if each instance cant see the other while they are running? Does this mean it is not possible to perform a partial copy of only the ncessary vBulletin files needed? All vbulletin files are needed?

[Chuck S]

You can try it if you choose

[dc_pitascii]

Originally Posted by Chuck S

You can try it if you choose

Naw. If I wanted do-it-yourself, then [insert something funny here.]

Thanks for putting in an effort.

If I examine the code, to determine what files are needed, that will have to happen at some future date, as I don't have time to do that right now.

[Chuck S]

yeah when someone installs with vbulletin integration as noted it needs to be installed on the same server for it to work and thus people dont run it like your trying

[dc_pitascii]

Originally Posted by Chuck S

yeah when someone installs with vbulletin integration as noted it needs to be installed on the same server for it to work and thus people dont run it like your trying

Copying the stylesheet-integration dependent files would also allow this to work and allow for central configuration. However, such a change increases complexity by at least one order of magnitude.

Independent service environments mean we can partition photopost off the network when security issues are found without loss of service to the forums. Upgrade procedures are also independent this way. Overhead through following includsion trees are minimized by not relying on the vBulletin stylesheets.

Tis ok. I have built a custom stylesheet that closely matches the forums server.

However, I have found 2 issues with custom stylesheets:
1) It appears the "present day" in the calendar is hard-coded to be red. (I should double-check this.)Where do I submit a request to have this controlled by a stylesheet too? email or forums?

2) the iframe that is used to try to show the current version, and link to the member area from the admincp (when stats are selected in the left frame.) appears to be "purple" and this does not appear to be controlled with the local stylesheets, meaning a black background for that iframe space makes those two links difficult to read. Same question as the above: where do I submit a request to have this fixed in future versions.

[Chuck S]

1. pp-inc.php you can change yours and any suggestion you can place in the suggestions forum

Content visible to verified customers only.

2. The statistics are controlled by css classes and even the html that shows an iframe however what message is displayed is not something on your system so how that html is being sent is being sent so there is nothing to change.

[dc_pitascii]

Originally Posted by Chuck S

1. pp-inc.php you can change yours and any suggestion you can place in the suggestions forum

Okie dokie.

Content visible to verified customers only.

Yep. And then remember to change that after every upgrade. I'll put it in the suggestion forum, with hopes that is is controllable at some future date in stylesheets.

2. The statistics are controlled by css classes and even the html that shows an iframe however what message is displayed is not something on your system so how that html is being sent is being sent so there is nothing to change.

Sure there is. The content being referenced with the iframe can be changed to include the same css elements for font folor, and styles, or with font color="#..."> ... just because it is not on our system does not mean it can't be changed. A request to have it changed on the system that serves it can still be made.

Customizing php is trivial, but documenting all customized mods, and then reapplying them after each upgrade becomes tedious.

I'll submit requests for both changes.

[Chuck S]

what I am saying is there are NO hard coded color variables in the iframe tag itself and the table that contains the iframe uses the css classes just fine.

Content visible to verified customers only.

The info we send it looks like to me is a simple text message with links to the announcement and members area

[dc_pitascii]

Originally Posted by Chuck S

what I am saying is there are NO hard coded color variables in the iframe tag itself and the table that contains the iframe uses the css classes just fine.

Content visible to verified customers only.

The info we send it looks like to me is a simple text message with links to the announcement and members area

When you examine the loaded content from the browser, do you actually see any css tags for markup?

Here is what I see:

<br /><div align="center"><font face="Verdana, Helvetica, sans-serif" size="2">
<b>PhotoPost 5.31 Now Available!</b><br />
<a target="_top" href="https://www.photopost.com/members/members.pl">quick link to Members Area</a><br /><br />
<a target="top" href="http://www.photopost.com/members/forum/showthread.php?t=125423">update announcement</a>
</font></div><p>

None of the refs to use the CSS labels like the rest of the PhotoPost content.

Actually, here is what it looks like as a result of not having the same sort markup as the rest of the css-enabled photopost pages:
(see attachment)


http://www.photopost.com/ppnews.php
Maybe if the iframe link/script included and supported a variable like "fontColor=white" for font to be white, and maybe "linkcolor=blue" for link color, we could get something that works.
http://www.photopost.com/ppnews.php?...r=blue&version...

[Chuck S]

It appears fine is every stylesheet I view it in and we have many in our stylesheets directory. Hard coding our iframe to specific font color to say white would introduce what I would say is a bug because take for instance our default stylesheet you would see nothing since the background for tddetails is white. See examples here it views fine

Every last stylesheet we have it on stylesheets directory it works with I am showing and no where do we hard code any colors. This would appear to be a specific issue with some stylesheet you made up.

[dc_pitascii]

Originally Posted by Chuck S

Every last stylesheet we have it on stylesheets directory it works with I am showing and no where do we hard code any colors. This would appear to be a specific issue with some stylesheet you made up.

It is ok for you to admit that this product does not support stylesheets that use dark colors for backgrounds. Defects in software and software design are common. You can even include a comment in the provided css that dark colored backgrounds are not supported, due to limits in ability to make css support in PhotoPost ubiquitous. It is ok to admit failure; I do it.

if you rewrite ppnews to accept two new args like:
textColor=
linkColor=

Then you could add some code to your ppnews.php to allow your customers to choose dark backgrounds. Of course this simple bug fix would require customers to modify the colors of the links and text that appears in the iframe.

Example:

if ( $_GET["textColor"] != "white" )
{
echo "<b>";
} else {
echo "<font color=\"#FFFFFF\" bold>";
}
echo "PhotoPost 5.31 Now Available!";
if ( $_GET["textColor"] != "white" )
{
echo "</b><br />";
} else {
echo "</font><br />";
}

Now, if a user chooses to add textColor=white to the URL that includes ppnews.php in their iframe, they can have white text, and gain support for dark colored backgrounds with CSS.

http://www.photopost.com/ppnews.php?textColor=white

It is not necessary to show how this could work with the arg "linkcolor=" since you have a proof of concept on how to fix the problem your code has with not supporting dark colored backgrounds.

However, if you need another code example, I can provide one.

There is symmetry here... I must give support to get support. (heh heh)

I can also provide a code example of how you can fix the problem with the "today" numbered date always being red, instead being controlled with CSS--

that would be even easier, as no new php would be needed. I'd only need to add a new CSS tag to the css file(s) and then modify the HTML portion of the code in the PHP file where the color "red" is applied to instead use the new CSS label.

There you go! Methods to fix two bugs in your software.

Give me CVS access to write to your respositories and file access to the ppnews.php script, and I can even fix them myself.

Hope this helps.

[Chuck S]

We do not pass color codes to the ppnews script but if you want my opinion we can always do this since you seem to want us to hard code the color here

Content visible to verified customers only.

That should keep things very uniform

[dc_pitascii]

Originally Posted by Chuck S

We do not pass color codes to the ppnews script but if you want my opinion we can always do this since you seem to want us to hard code the color here

Content visible to verified customers only.

That should keep things very uniform

Hey! That would be an even easier solution. Since this does not appear in a public doc, I could care less about a uniform appearance in the mod-space, but MORE about content being readable.