Critical Error

Could not get theme data for themes_id [32]

DEBUG MODE

Line : 1010
File : functions.php

I've read everything here that pertains to the problem (After sifting through such useless titles as "Locked Out" "Big Errors"  and nothing suggested works to fix the problem.

Something as simple as "Disabling the Site" - logging out - clear cache and cookies, and logging back in created this error message in IE7, FF and Opera - with the /cache cleared, and all browser cookies and caches cleared.

I've had this before, and I thought it was me,  and the only way I could get it back then was to edit the DB and change one of the theme_id's to the number it was looking for.

Here's the current dump for ip_themes that returns the error.



If I change this - (30, 'vista', 'Crystal', 'style_crystal.css', 'crystal' to - (32 Then everything goes back to normal.

Q. Where is IP getting the information from for themes_id [32] when it doesn't exist in the Db, and all caches / cookies etc, etc, have been cleared ??

I think the clue is in the last line of your create table:

Quote:

AUTO_INCREMENT=32;

Dunno if that's the problem MTV as it appears to be looking for a theme ID, and not an incremental value.

 

It already has a theme id, by virtue of the error: Critical Error

Could not get theme data for themes_id [32]

And how do you think xs_styles.php obtains the theme id?




sql_fetchrowset is really using the php function mysql_fetch_array($result, MYSQL_ASSOC) the "MYSQL_ASSOC" returns associative indices.

And so the value of rows are associated with their index in the table, and the way mysql works, last auto-index is associated with the last row, which in turn is assigned by xs_styles as the value of the theme id for the last theme. Spin this around the other way, go into your themes table and change the theme id back to 30, and set then auto-increment value to 30, see what happens

Try to reset your def_themes.php as well...

____________
Luca
SEARCH is the quickest way to get support.
Icy Phoenix ColorizeIt - CustomIcy - HON

Ah yes... now thinking about it, we are bordering into the subtle world of how this crazy templating system works... one of the things is that it normally only tries to access the DB themes table for themes if the def_themes is empty, or if caching is disabled...

There is something else that is more likely... *edit - more likely to my last post, not MG's * - there is a function called setup_style() that gets the style based on the board_config default_style, or if a user has a preferred theme, then: setup_style($userdata['user_style']...) - so maybe the error for Lopalong was really the fact that he had set a default theme / personal theme for the theme that was numbered 32... (it is setup_style()  which loads the def_themes file, and uses it if it has data, or else queries the database...) and when you want to remove a theme, you have to do it from within extreme styles, so that it can strip all the references to that theme from the users table... Now that would make a lot more sense if you're hacking themes about like our buddy down under...

So I suddenly realise now that xs_styles.php is a red-herring... the clue was in Lop's first post:

Quote:

DEBUG MODE

Line : 1010
File : functions.php

Which is precisely the file where this function comes from... Sometimes I jump ahead of myself too far for my own good.. I think its the walamat galloping too fast..

@ MTV,

Quote:

so maybe the error for Lopalong was really the fact that he had set a default theme / personal theme for the theme that was numbered 32... (it is setup_style()  which loads the def_themes file, and uses it if it has data, or else queries the database...) and when you want to remove a theme, you have to do it from within extreme styles, so that it can strip all the references to that theme from the users table...

Somewhere, something is screwed up ? def_themes.php, no longer appears to have theme 32 as it was no doubt flushed from the file when it was removed / uninstalled.  Why it still looks for it? is a mystery - But I do give it a hiding with swapping themes, re-naming folders, config files and the like, and as I'm using localhost for most of the work, maybe MS couldn't keep track of what was happening.



@MG,

Easy! once one gets to know where these things are.  

MTV wrote: 

Now that would make a lot more sense if you're hacking themes about like our buddy down under...

Modelling - NOT hacking!

And I'm still only a learner when it comes to phpBB - aka IP.  

Lopalong wrote: [View Post]

@ MTV,
You were right in one way, auto-increment appends the next number to the next theme but it wouldn't matter if the existing theme was 32 and auto increment was 132. The next theme would be 133.

Well yes, thats just because its the primary key - as per my second post on xs_styles.php, it looks like something subtle happens there - it still has what looks like a crazy way of obtaining the the theme_id - indirectly using mysql_fetch_array($result, MYSQL_ASSOC) - why use a function that returns associative indices? Totally strange, I mean, I would have expected something using standard sql_fetchrow like:


But there, thats immaterial for the error message you got, and ultimately, although xs_styles.php uses a method which gives the row index, it is still addressing the field 'themes_id', so perhaps it is be getting the right info... but I'm just not sure exactly what the phpbb dB library returns for mysql_fetch_array($result, MYSQL_ASSOC)... since it could still just be getting the row index associated with the field 'themes_id' rather than the value stored in there itself... if you're curious read this- anyway... an example of how crazy this mod is - not doing the obvious!

And I think MGs message about deleting the entries in def_themes.php was actually to stop you having another error - the dreaded white page. Any false entries in there usually result in nothing being seen at all.

To recap from my last post, the reason your error message appeared is because setup_style() was accessing the DB to query the themes id - the only reason it does this is because def_themes was empty at that time. That the theme reappeared in def_themes is probably because you changed your theme id back to 32 - then when setup_style() found theme-id 32 in your database, the theme info is then stored in def_themes (actually another function does that step, cache_themes in functions_categories_hierarchy.php...

If you're not convinced about this, open functions.php and look at the lines 947 - 1010 (where your error message occured). It was querying the else to that is line 1010:which is precisely the error you got.

And so... it was trying to query the themes id based on what is stored in your settings for the default theme in the config table $board_config['default_style']. As I'm sure you'll discover in time... def_themes screws things up in a much nastier way - you'll be lucky to even see an error message  

Lopalong wrote: [View Post]

Modelling - NOT hacking!

I'm beginning to doubt you're an Aussie now... I mean, first off, use of euphemisms... only Americans do that... (e.g. "bathroom" instead of "toilet"), secondly... making fancy themes - I mean, Australians are too down to earth to care about appearances... you still have mullets over there! And 3rd... that you're even in front of a computer... I mean a real Aussie would be out in his yard trying to perfect the spin bowling technique to be the next Shane Warne

All too confusing!  

The bottom line on how I understand it is: The error wasn't being generated by the Db, and there really was no need for me to modify it.

When and / or if it happens again, I will compare the Db entries against def_themes.php, and that should or will indicate where the the problem or request was being generated from. Until then, it's a mystery-bag.

 

Lopalong wrote: [View Post]

All too confusing!  

Edit to stay on topic:

The bottom line is: The error wasn't being generated by the Db, and there really was no need for me to modify it.

When and / or if it happens again, I will compare the Db entries against def_themes.php, and that should or will indicate where the the problem or request was being generated from. Until then, it's a mystery-bag.

 

Hmmm.... you are suffering from amnesia from your very first post which clearly states where the error occurred.
Actyall its because your board default theme setting - it contains an entry for a theme that doesn't exist.

To see whats happening to give this error, here are the relevant lines from functions.php:

The clue is in the IF: In other words, if the row couldn't be queried from DB, try a number of things to change the theme settings, but, if the original query was relating to the default style, it means that default style couldn't be retrieved from DB, so then we have problems (there should always be a default style) - hence the error message on line 1010. So the question is why did mysql return an error? We come back my previous point, about the board default theme setting, that it contains an entry for a theme that doesn't exist.

MTV,

My question was:

Quote:

Q. Where is IP getting the information from for themes_id [32] when it doesn't exist in the Db, and all caches / cookies etc, etc, have been cleared ??

Why and how it happens doesn't interest me in the slightest, only that the theme was at one time installed and had been deleted / uninstalled along with a few others.

IP had cached this information elsewhere and all I wanted to know was where that information may be stored. Not a breakdown of the core-file code on how MYSQL works or how IP deciphers that information.

Quote:

Why and how it happens doesn't interest me in the slightest, only that the theme was at one time installed and had been deleted / uninstalled along with a few others.

I am trying to help you understand why you get to

Quote:

"Where is IP getting the information from for themes_id [32] when it doesn't exist in the Db, and all caches / cookies etc, etc, have been cleared ??

Sorry I'm trying to explain why this error occurs.

It is because you have a default theme set in your board config which no longer exists, you need to go into ACP>> board config.

Function get_themes is being called with $board_config['default_style'])  - the themes_id is being obtained from the settings for your board default themes. But you are right that it could be a caching issue, in that the board config database table is also cached. However, if you make a change in the default theme, you should change it in your ACP, so it will regenerate the cache file. But you stated

Quote:

The bottom line is: The error wasn't being generated by the Db, and there really was no need for me to modify it.

which is perhaps a misstatement on your part - the error is clearly created by the DB, because it contains data in default board style for a theme that doesn't exist, a theme defined by what is configured to be your default board style, as said previously. Yes it could be in a database cache file, but that cache file depends on what is in the database.

I'm still not sure. Let me suggest this to you:

I removed all themes from the Db "Dumping data for table `ip_themes`"




And IP still works OK and continues to bring up theme 32, because it is obviously getting its information from def_themes.php here.



If I remove:


I get:

Critical Error

Could not get theme data for themes_id [32]

DEBUG MODE

Line : 1010
File : functions.php

And if I change:



To:


The Error is removed and IP comes up with the "Icy Phoenix" theme.

And as there are NO themes in the Db, it's obvious that functions.php is first taking (or only taking) its information from def_themes.php which makes a lot of sense if one has set this up to reduce Db queries.


That's all my question was - So yes! I DO understand, and NO I don't have amneasia.

Edit: This appears to be the real problem: ('default_style', '32'), as previously somewhere along the way it never changed when the default theme (32) at that time was removed. Dunno, it hasn't happened since. ?

Edit 2:


MTV,

I hope this helps to finally put this to bed.

It happened again after re-installing all of the themes which now number from 40 to 44 and it still looks for 32?

And it appears that the crux of the issue was:

In the ACP I had set.

Default Style = Crystal" (32)
Override user style = (Y)
Replaces users style with the default  

Then I used XS to set a new default and remove what was the "old" default. But the "Board Config" keeps switching it back for a theme that no longer exists.

Now that I have:

Override user style = (N)

It no longer looks for theme (32)

Ha ha, ok, good... I did say it is the settings of your default style as function get_themes is being called with $board_config['default_style']), for a few times now, but its good you found this out in your own way

It still doesn't explain why changing the default style in XS allows one to delete what is the default theme set in the ACP, so there is a conflict between the two functions as the XS setting doesn't recognise the setting in the ACP, and vice-versa.

So I think it's a BUG, and the best remedy I think, is to remove the option from the ACP and use only XS to over-ride user's settings and all other theme functions etc.

Then there won't be any more slightly "warm and long" conversations about as to what the problem may or may not be, because it wont exist anymore.  

Catcha later,  and I'm glad that "all" avenues pertaining to this issue have been covered, and hopefully resolved.