New theme doesn't succeed to recolor title/menubars

After installing OcPortal manually and trying to get all file-permissions right, everything seems to work fine. Except that after creating a new theme in another color and setting this for as many as possible parts of the site, this theme doesn't affect the color of the menubars and titlebars (boxbars?). Other aspects of the theme do work as expected, so I now it's there. Only the new color for all bars doesn't show up.
Anyone any hints for me?
(I think at one moment I saw a flash of the new colors, which immediately got overridden by the default color for bars again). Very frustrating!

O.K. I did a clean install and the problem was gone.

Pfffffffff…. had to do another clean install in connection with language problems. Those seem to be solved now, but the bar-color problem is back. Please any help is welcome!

Hi,

I think possibly this is a bug in 4.2.1. Does that match where you've problem seeing the problem?

No, I'm afraid it happens in 4.2.1 and in 4.2.2.

Should I manuallly change the color of bars in the CSS-files maybe? Is that difficult to accomplish?

Today I removed all Dutch po files, checked all file permissions, and when everything worked fine, installed a new theme. The new theme worked fine (that is, changed the colors of the bars also). Then I re-installed my Dutch po files. And there was my problem again!
On closer look at the file permissions, I noticed that after adding the language files, a lot of the theme files (and other files) in directories named "NL" have "apache" as owner, not "saloweb" (as all other files have). As I suspect that this might cause my problem, I tried to manually reset ownership for all these files (two hundred or something!). I hoped that would solve the problem, but it didn't.
So now the boxbars and other bars are still not influenced by the applicable theme. And also, I cannot reach the Admin Zone or CMS zone, as going there results in my browser asking if I want to save the php-file the URL pointed to.

I would like to know if this apache-business is part of the problem, and if any solution is at hand. Thanks for helping out!

(I considered adding another language, for instance German, to see if my problem will appear then, but right now it's a bit late for that, maybe tomorrow).

Frits

Hi,

There have been problems in the past with how theme image searching and caching works when multiple languages are installed. It's complex code, and I will run some tests soon.

Chris,

I have two further questions.

1. Browsing the forum, I noticed something which might be of relevance to my problem. When I "imported" my Dutch po files, I just put them on the server with my ftp-client. After that, I got critical error messages complaining that a certain directory could not be created. After doing that manually, I could use the site (apart from my themeing problem). In the forums I found the following hint:

"Problem: A directory was needed but missing. ocPortal tried to create it but failed.
Answer: How did this happen?
This happens often when people upload a new language pack without adding it first via tools in the Admin Zone."

Am I right that this means I cannot just add Dutch language files as I did, but that I am to add it as an add-on first? (btw the addon section is not in my tools section but setup section in the admin zone).

2. If it is not possible to get Dutch working alongside English, would it then be possible to convert the Dutch po files to English po files, so that the site will only use English (in name), but actually visitors only see Dutch strings? That would be fine for me, for my target audience is Dutch-only.

Thanks again for your patience, but I really like to get this right.

Am I right that this means I cannot just add Dutch language files as I did, but that I am to add it as an add-on first?

For some servers you need to create the directories manually or add the language by starting a translation (which will prompt ocPortal to use the afm [FTP] to create the directories for you).
We'll clarify the internationalisation tutorial.
What you've done manually is fine.

(btw the addon section is not in my tools section but setup section in the admin zone).

I've made the error message a bt clearer now…
"This happens often when people upload a new language pack without adding it first by starting a translation via the language tools in the Style section of the Admin Zone."

If it is not possible to get Dutch working alongside English, would it then be possible to convert the Dutch po files to English po files, so that the site will only use English (in name), but actually visitors only see Dutch strings? That would be fine for me, for my target audience is Dutch-only.

We'll make sure it works. Probably it would be possibly, but I see no reason to go down that route.

O.k. now I manage to add Dutch language support without error messages about directories which couldn't be created. That's a good step forward.

My other problem still exists: after installing Dutch language support, any new themes don't work properly: some or most boxbars are unaffected by it. This problem cannot be circumvented by uninstalling Dutch language support. After deleting the po files new themes look fine, but as soon as I reinstall the po files, the theme malfunctions again.
A theme, however, which had been created before I ever added Dutch po files, is not affected by the problem. Maybe this information is helpful for finding a solution.

Thank you, as ever.

Hi,

I'll make sure it's sorted, it's a priority for me. I'll be running tests tomorrow (out of time for today).

well Chris, I found part of the solution to my problem:

1. After clearing the image cache (and other caches) with cleanup tools or upgrader.php, themes do manage to pick up the correct colors for boxbars etc. I don't know why this problem only occurs after a language has (ever) been added to the site, but that is not very important (maybe you should add a caveat to the documentation on this).

2. The above did not work for the logo icon. For this, a partial solution was found by me on one installation, by fixing missing writing permissions for my Dutch po files and emptying the caches afterwards. Strange enough, this did nog work on another installation of OcPortal. On this last installation, newly added themes do not pick up the correct color for the logo, nor am I able to correct this by going through the logo wizard for the theme.

Hope you can help me out on this last issue…

Frits

Just some further obervations:

3. On my 'good' installation (which I installed after manually uploading all files), adding a theme and clearing caches does not affect the logo-color (as should be, and is when I wouldn't have added a new language). For this, I have to use the logo wizard.

4. On my 'bad' installation (which I installed with the automatic uploader from the OcPortal site), the result of the logo wizard seems not to be saved at all, color nor slogan (although the script claims it to be saved).

5. Minor detail: should new colors also apply to the 'votes-representing' bars in polls? (in my case they don't)

Further experimenting lead me to control the logo-problem (which can be summarized as: after installing custom language files it is hard/impossible to create separate logo icons for custom themes).

1. First you have to delete any custom logo icon you can find (via edit themes, edit theme images). I first had to answer the question which language version to work on, and choose English (but I have a feeling that this might not be very important: just delete any icon you can find).

2. Then you can create new logo icons for you respective themes. A problem which still exists (but can be overcome) is that a logo icon for a custom theme also tends to be used by the default theme (vice versa). A custom logo icon for one custom theme will not be used by another custom theme, however.

3. With some playing around (deleting logo icons, changing themes etc), I managed to get separate logo icons working for all my different themes.

I leave it to people smarter than me to sort out how this all works exactly. For the likes of me it would be good if some of this could find its way to the documentation on internationalisation and/or themeing.

By the way, the more I see of it, the more I like OcPortal!

Maybe the language/themes problem isn't solved completely after all. After my yesterday evening post, I still experienced some problems (the coloring of a custom theme leaked through into the default theme). This morning this behavior cannot be reproduced by me, but it shouldn't have been there in the first place.

Now in addition to what I noticed earlier, I see now that upon creating a new theme and a logo in that theme, (and manually assigning that logo also for the English version of the same theme, as this didn't come about automatically), strangely a corresponding logo is being used by the default theme (albeit in the correct blue coloring)! When I delete that blue logo, every theme falls back on the original ocp logo (blue for all themes). In other words: there is a unexpected logo-interdependency across themes.

To be more complete, two further observations:

1. When running upgrader.php, I always get complaints about many files being writable that maybe shouldn't be. This is the case for alle files belonging to custom themes, but also for the themes-folder itself en for the tmp-folder. When I correct these permissions, some time later they get writable again.

2. The file themes/map.ini is reported to be "outdated" by upgrader.php. The file is empty. Originally, this file contains only: "default=default", so I guess that when adding a theme, a extra line for that theme is needed. Doing this manually is possible, but after some theme-switching, map.ini gets empty again. More precisely: switching from a custom theme to default theme causes the line "default=default" to be erased. Switching back to the custom theme erases the (manually added) line "red=red" ["red" being the name of the custum theme of course].
Could this be of any relevance?

Hi,

You've given me a great deal to go on here, thank you so much for going into this detail.
I've kept being delayed looking into it properly (wanted to do so a couple of days ago), but I will asap.

I appreciate that. For now: happy new year to you!

Yikes, I still haven't replied. I don't like to keep replying saying I will reply later, but that's what I'm doing again. Sorry about this, I've got bogged down in some things so far this week.

Hi,

Sorry for the delay, I've finally got around to looking through all this. It was one of those nasty problems that involved multiple factors, so got passed over for the simpler bug fixes a few times . I'm embarrassed I said I'd do it the next day and it ended up being two weeks.

Please try the attached sources/themes.php, it seems to fix the problem.

Attachment

sources/themes.php
» Download: themes.php (8 Kb, 151 downloads so far)

On closer look at the file permissions, I noticed that after adding the language files, a lot of the theme files (and other files) in directories named "NL" have "apache" as owner, not "saloweb" (as all other files have). As I suspect that this might cause my problem, I tried to manually reset ownership for all these files (two hundred or something!). I hoped that would solve the problem, but it didn't.

This is normal. The files are created by the web server, which often runs with it's own username.

After clearing the image cache (and other caches) with cleanup tools or upgrader.php, themes do manage to pick up the correct colors for boxbars etc. I don't know why this problem only occurs after a language has (ever) been added to the site, but that is not very important (maybe you should add a caveat to the documentation on this).

The bug was related to theme image precedence. There are some very complex rules about where it can find files, and it tries to run efficiently which is difficult because it is trying to juggle a lot of different possibilities.

Minor detail: should new colors also apply to the 'votes-representing' bars in polls? (in my case they don't)

No, but I think they should- so we'll change this.

Further experimenting lead me to control the logo-problem (which can be summarized as: after installing custom language files it is hard/impossible to create separate logo icons for custom themes).

It will create it for the default theme also. I'm amending the UI To make that clear.

Now in addition to what I noticed earlier, I see now that upon creating a new theme and a logo in that theme, (and manually assigning that logo also for the English version of the same theme, as this didn't come about automatically), strangely a corresponding logo is being used by the default theme (albeit in the correct blue coloring)! When I delete that blue logo, every theme falls back on the original ocp logo (blue for all themes). In other words: there is a unexpected logo-interdependency across themes.

When running upgrader.php, I always get complaints about many files being writable that maybe shouldn't be. This is the case for alle files belonging to custom themes, but also for the themes-folder itself en for the tmp-folder. When I correct these permissions, some time later they get writable again.

Right, I see this is reporting excessively in cases where the webserver user is the user with the permissions, rather than the FTP user, which is the case for auto-created files. I'll fix these messages.

The file themes/map.ini is reported to be "outdated" by upgrader.php. The file is empty. Originally, this file contains only: "default=default", so I guess that when adding a theme, a extra line for that theme is needed. Doing this manually is possible, but after some theme-switching, map.ini gets empty again. More precisely: switching from a custom theme to default theme causes the line "default=default" to be erased. Switching back to the custom theme erases the (manually added) line "red=red" ["red" being the name of the custum theme of course].
Could this be of any relevance?

Nothing to worry about there. The upgrader should not be checking that file though, and really it should be empty from installation as that default line is meaningless (which is why it gets stripped). Both these little issues will be resolved.


During the process of going through all this, I found some other little bugs, which will all be fixed in 4.3 RC3.