Problems changing default stylesheet (0.9.2.6)

jakekrohn

First off, great piece of work. I have enjoyed exploring the interface and code and foresee being able to use it for great things. However, I am having trouble specifying a different "Default style folder" via the "Global Application Settings" page. When I change the value and save the page, the constant value is modified in `appg/settings.php`, but this value is being overridden by `StyleID` data that comes from the `Session` object. Therefore, I continue to see the default "Vanilla" style. Poking around in the code has been enlightening. Correct me if I'm wrong, but the handler that saves the "Global Application Settings" page does little else than save the values to the constant file. No database transactions (i.e. inserting a style or changing user's styles) are carried out. And that makes sense to me, given that one does not collect all of the necessary information to properly create a new style record. And it's probably a good idea to leave user-specific style IDs alone, given the existence of the "Custom Styles" extension. It looks like my problem lies in the `UserManager` class, where the `StyleID` is hardcoded to '1' at the time of account creation. I don't think I want to use the "Custom Styles" extension, because I don't want to allow user-defined styles. So as a workaround, I did the following: 1. Added a new style to the `LUM_Style` table and pointed it to my new subdirectory in `styles`. 2. Modified the `Vanilla.User.class.php` file (Line 515) so that the default style ID was that of the style I added in step 1. Subsequently, any new user will default to using the custom default style. Is this the suggested way to go about doing something like this? I saw a lot of discussion about this topic, but no one seemed to be having quite the same problem I was having. Or am I missing something completely obvious? One other question: I'm still in the exploratory phase and have yet to deploy the forum. Would I be best served to wait for 0.9.3 to come out? From the limited reading I have done thus far, it looks like it introduces some pretty big changes? Again, thanks for making such a great product. Jake Krohn

lech

I think you may be missing the completely obvious, because even if you don't enable the style manager which allows the users to specify the use of another style, you can still change the overall appearance of the board. In the global application settings, the default style can be swapped out by you the admin to make the board use whatever other styles you have on hand and the users will still have no choice :)

jakekrohn

I think I figured it out. The forum was initially configured to not "Allow non-members to browse the forum." Because of this, whenever I wanted to look at the forum, I logged in and the default style (Vanilla; set on account creation) was shown to me because that's what was in the Session object. (See line 95 in `Utility.Context.class.php`) However, once I allowed non-members to browse the forum, it became apparent that they will always see the custom style because they have no Session data telling the system what kind of style they would like to see. So, does this make sense? From the documentation it's not apparently obvious that this is how the system will act. Is this intended behavior, or just an unfortunate consequence of a series of design decisions? Either way, I can live with it since the workaround is easy to do. But maybe I can look at clarifying the docs to explain this a little better? Thanks. Jake

Mark

The requirement of the StyleID has to do with a very old version of Vanilla that had custom styles built into the core.

The "Default Style Folder" is a folder defined so that people who aren't in the user table can have a style to look at even if they don't have a StyleID.

If you want everyone, including both registered and non-registered members, to see your custom style, do this:

1. Use the Global Application Settings form to specify the path to your custome style for Default Style Folder (as you've already done).

AND, EITHER

2. Edit the LUM_Style table so that StyleID 1 points to your custom style

OR

3. Alter the core to give new users a different StyleID, and add a new entry to the LUM_Style folder for your custom style (as you've already done). Finally, to ensure that existing users use your new custom style, change their styleID manually. Assuming that your custom style has a StyleID of 2, this would be the query:

update LUM_User set StyleID = 2

jakekrohn

Ok, cool. Thanks. I got the 0.9.3 code from the repository, and I see that you've changed some things around with respect to user creation and that those changes solve the problem. Nice. Again, thanks.