also something strange that i noticed when i attempt to login, i enter my password and press enter... but after i press enter, a lot more asterisks appear than the amount of letters in my password. any significance to that?

Did you delete all files from 1.x version before uploading the new ones? And when do you get this error?

also something strange that i noticed when i attempt to login, i enter my password and press enter... but after i press enter, a lot more asterisks appear than the amount of letters in my password. any significance to that?

This is a new feature :)

yeh... i backed up my database and deleted everything before installing. this is maybe my third or fourth upgrade of b2evo, and the first time i've had trouble with an upgrade. :-/

Got link?

Is this happening from a plugin or hack or mod, or unmodified b2evolution using the stock skins? Generally speaking, when I see that error it's because something I'm trying isn't the right way to get it done is why I ask.

i had a custom skin installed that allowed different banners for each of my 4 different blogs... there were also a few minor changes i made to the way my blogs displayed the date... and i also had no sidebar... that's about as far as my customizations went.

the link to my blog is http://shunsai-inc.com/blog/

that link produces the index.php line 59 error... the admin.php produces the _main.inc.php line 446 error.

i just finished re-deleting everything and reuploading/reinstalling everything. i was worried that maybe the first time, everything didn't get deleted or not everything uploaded. this time i'm sure everything was deleted and uploaded, and still getting the same error.

oh yeah, i also checked the .htaccess file per my webhosts suggestion, and it looks strange to me... all that's written in it is:

Options -MultiViews
ErrorDocument 404 //time.php

besides that, there's a similar file except its called hrhtaccess... my guess is the hr stands for hostrocket (my webhost provider). that one says:

./guestbook/index.html

not sure if either of these have any significance...

So let me double-triple make sure I understand: You had some customizations, but are not using them and are having this problem. In other words all the files are EXACTLY what they were when you unzipped b2evolution - right?

I'm wondering, assuming this is happening without mods (and I think that is a true statement) if maybe you have corrupted files? I know you've tried 3 or 4 times now, but did you grab a fresh .zip package from the downloads page or did you try with the same set of files from your computer that have resulted in failure? My thought is that maybe something went bad when downloading or unzipping, which would make the same set of files always fail.

Also in your conf/_basic_config.php file you can pick a new beginning bit for the table names. Lemme look a second ...

$tableprefix = 'evo_';

You can change that to something like

$tableprefix = 'BUGTEST_';

then use your exact same other info in that file to basically build a brand new shiny bright installation. That won't fix your problem, but it will leave your actual tables out of the picture - not that I fear your tables are at fault or risk!

EdB wrote:

So let me double-triple make sure I understand: You had some customizations, but are not using them and are having this problem. In other words all the files are EXACTLY what they were when you unzipped b2evolution - right?

I'm wondering, assuming this is happening without mods (and I think that is a true statement) if maybe you have corrupted files? I know you've tried 3 or 4 times now, but did you grab a fresh .zip package from the downloads page or did you try with the same set of files from your computer that have resulted in failure? My thought is that maybe something went bad when downloading or unzipping, which would make the same set of files always fail.

Also in your conf/_basic_config.php file you can pick a new beginning bit for the table names. Lemme look a second ...

$tableprefix = 'evo_';

You can change that to something like

$tableprefix = 'BUGTEST_';

then use your exact same other info in that file to basically build a brand new shiny bright installation. That won't fix your problem, but it will leave your actual tables out of the picture - not that I fear your tables are at fault or risk!

it's funny you should say that, because after this second delete/upload/install, i started to wonder if my zip file was corrupt too and whether i should try re-downloading the 2.3.0.rc-1 package altogether. and yes, you understand correctly: i had some customizations, but am not using them and am having this problem. In other words all the files are EXACTLY what they were when i unzipped b2evolution

well, i redownloaded the b2evo zip file, even chose a different mirror. i unzipped the files to a folder different from my original download and compared their properties in windows explorer. everything is identical down to the byte. is there still a chance that the original zip i downloaded was corrupt?

I guess there is always a chance, but to me it sounds like a very small chance right now.

Sorry, but this is beyond me to help. Hopefully one of the people who knows all about different server configurations will come along because that's where I think the problem must be.

If your blog still doesn't work after the upload that you're currently doing try cracking open conf/_advanced.php and changing the following section of code to look like this :

// If you get blank pages, PHP may be crashing because it doesn't have enough memory.
// The default is 8 MB (in PHP < 5.2) and 128 MB (in PHP > 5.2)
// Try uncommmenting the following line:
ini_set( 'memory_limit', '32M' );

As an aside, from looking at your phpinfo you don't have a visible memory setting so you may need to ask your host to change the memory level for you

¥

ok, thanks for the suggestion. i checked my php settings and the memory limit seems to be 8 mb. i checked the _advanced.php as suggested, but couldn't find a line containing "memory_limit" save the notes explaining reasons for changing it. i'll try adding the line "ini_set( 'memory_limit', '32M' );" underneath the notes when i get a chance. currently, i'm getting a 500 Internal Server Error and can't access my files right this very minute. so i've sent in a new trouble ticket to my webhost asking them to check on that and to up the limit to 32 mb. i'll report back once i get their response.

update: i uncommented the line you suggested, but no change. i'm still waiting to hear word from my webhost about upping the limit on their end.

you know what, screw it! i'm in over my head. i never wanted to do anything fancy with my blog. i was quite fine with 1.x series... the only reason i upgraded is because it seemed like going through this torture was inevitable and forthcoming... that and my blog/website kept getting hacked. but all i've ended up with is a completely broken blog and no proper place to vent. >:( :'(

i wrote my webhost asking about the memory limit. they replied:

As was mentioned previously while the global
PHP settings cannot be changed in many if not
most cases one can set local settings on a
per account or per directory basis by adding
php_flag or php_value directives to .htaccess.

Examples:

php_flag register_globals off
php_flag allow_url_fopen off

Those I can confirm will work on all servers.
As far as the memory_limit setting you can try
the following, however this may not work in all
cases:

php_value memory_limit 32M

i tried that, but i seem to be too php and mysql retarded for this, because i keep getting the same Fatal Error results. i notice a lot of the diehards on here don't really think its a good idea to downgrade, but unfortunately, this 2.30 RC-1 isn't going anywhere for me... i'd really like some suggestions for simple instructions for downgrading back to 1.10.x

i backed up my database in xml, sql, and odt (?) hopefully for safe measures. can anyone point me in the right direction by way of downgrading. sorry if this sounds like a pissy post, but i've been unable to blog now for over a week. :(

In the setup for B2evo you find a file called sample.htaccess. Rename that to .htaccess and place it in the directory where your blog resides. You may want to place it in the root of your server, that is the folder /public_html/ Whichever works is depending on the setup and the reply from your host is not fully conclusive on this detail. (do not attempt to overwrite an existing .htaccess.)
If this doesn't work out of the box please reply once more to this post and we will give you suggestions to modify this file.

Your 500 internal server error is probably caused by a folder with permissions 777 or similar. Did you CHMOD the /media/ folder or the /conf/ folder. 755 is good for a folder 765 766 775 776 777 is bad.

The password is stored as md5. That is an encryption (sort of) containing 32 chars. When the password in your login box grows, that's where it's being converted from your 5-8 digit password to the 32 digit md5 ( password ). This is normal behaviour.

Good luck

shunsai sorry it's a PITA, but honestly I think it's your host.

Your web got hacked when you ran 1.10.something? Upgrading won't fix that!

"Downgrading" is pretty much not possible, but you can restore a previous version IF you have a backup of your database and files from a time when it worked. And actually you can get the files from the download tab above, but you absolutely must have a copy of your database.

To go back in time you would have to DROP all the tables in your database, then restore your backup copy into your database. Then you need to delete all the b2evolution files from your server and restore the files from a time when it worked. Take care to keep an eye on your conf/_basic_config.php file because it connects the files to the database. Also you are the only person who can possibly have a backup of everything in your media folder, so take care of those files as well.

Hey when you get it restored to a golden oldie you can use it to vent how much your host (or upgrading if you prefer) sucks ;)

Afwas, i did change the sample.htaccess file to .htaccess before with no results. but i tried again upon your suggestion, and tried it in both my blog directory and my public html directory. still

Fatal error: Call to a member function on a non-object in /home/shunsai/public_html/blog/index.php on line 59

when trying to view the blog and

Fatal error: Call to a member function on a non-object in /home/shunsai/public_html/blog/inc/_main.inc.php on line 446

when trying to login to the backoffice. Any suggestions of flags to add to the .htaccess file?

the error lines referred to index.php and _main.inc.php respectively are:

if( (($Blog = & $BlogCache->get_by_url( $ReqAbsUrl, false )) !== false) )

and

$User = & $UserCache->get_by_login($login);

so it would seem that the problem is rooted in, or at the very least related to the cache.

EdB, well, i think it's my host too, and they don't know it yet, but their days are numbered. my 2 year contract with them ends in june, but i doubt i'll wait that long. i'm considering moving to hostmonster (i'm currently with hostrocket). and yeh, i know upgrading my blog won't prevent my site or blog from getting hacked. that's not what i meant. i more meant, there are vulnerabilities that get patched with updates, so when i stick to an older one, i become more vulnerable... that's part of the reason why i updated... to get the added security benefits or what have you of the latest version.

i don't really want to touch my original tables or my original blog database. what i was in the beginning of doing though was creating a completely new, separately named database and then importing my backed up (1.10.2) database into that one. would that still somehow affect my current database (the one that's been updated for my non-working 2.30 RC-1)?

I'm not sure I follow what you are trying but basically: no. If you build a new database and restore your backup into it then you will have another copy that will work with the 1.10.2 files. The problem you will have is two sets of files trying to live at the same URL. That would be your $baseurl in your conf/_basic_config.php file yah?

I'm not smart on the php stuff, but I notice both the lines that are throwing the error have the same " = & " thing in them. That means something like "what.ev.er." to me, but it means smart stuff to php. Possibly that little detail is what is choking your current server situation?

Hey keep the database backup really safe because IT more than anything else is your existing blog.

Here's a thought: can you make a brand new installation of 230RC1 in a brand new database? Make a folder called something like TESTING and make your $baseurl know that name just to see if you can get 230 running or not. I suspect it will fail, but if it works then we have more info to work with.

EdB wrote:

I'm not sure I follow what you are trying but basically: no. If you build a new database and restore your backup into it then you will have another copy that will work with the 1.10.2 files. The problem you will have is two sets of files trying to live at the same URL. That would be your $baseurl in your conf/_basic_config.php file yah?

I'm not smart on the php stuff, but I notice both the lines that are throwing the error have the same " = & " thing in them. That means something like "what.ev.er." to me, but it means smart stuff to php. Possibly that little detail is what is choking your current server situation?

Hey keep the database backup really safe because IT more than anything else is your existing blog.

Here's a thought: can you make a brand new installation of 230RC1 in a brand new database? Make a folder called something like TESTING and make your $baseurl know that name just to see if you can get 230 running or not. I suspect it will fail, but if it works then we have more info to work with.

i'll try what you suggest, but it doesn't sound too different from what i said (or at least what i meant). currently my blog folder is "/blog/" but if i were to say create a new database and new installation of 1.10.2 in a folder called "/bloggz/" to avoid confusion, and then imported my database, would my newly imported database still somehow point to my original "/blog/" installation? if they're separate installations in separate folders, they shouldn't be vying for the same $baseurl, should they?

btw, i want to be sure. backing up database. when we speak of backing up database, with myphp, that would be the same as the export option right? and it results in a text/zip file format of your choosing (sql, xml, odt, etc.), right?

Yes: export from phpmyadmin is a backup method. Also if your cpanel is like my cpanel then you probably have a 'backup' utility that will give you the same info in a different format. I personally like the backup utility because it is really easy to restore from that one compared to restoring from export. Maybe it's because I haven't figured out how to restore nicely from export?

Your second installation would need to have the right connection info in conf/_basic_config.php, including the new $baseurl value. That is the only way you might have a conflict, but if you are doing it through fantastico it'll take care of that for you.

Wanna know another trick? In the _basic_config file you can tell it to use the SAME database with a different table prefix. I forget the name of the variable, but the default value is "evo_". So changing that with a new installation means you'll have 2 databases worth of tables in one database.

But yeah it's probably not going to get you anywhere :(

yeh, i see it in there- $tableprefix = 'evo_';

seems like we're somewhat on the same wavelength. these are all the things i'm tinkering around with.

it may sound lopsided and pointless, but right now i'm doing fresh installs of both 1.10.2 and 2.30rc-1 and gonna create separate databases for them with separate prefixes. it's an experiment to see what works and what doesn't, and also test some limits.

i'm really not the type to reject technological advances as they come along, but i try neither to be an early adopter. i thought 2.x-series had been around long enough that i might escape it's seething wrath. i should've just gone up to 1.10.3. hehe. oh well.

*sigh*

well, i've done about all the experiments i can do in one night (almost 1am here in japan). as a brief recap, i made new installations of three different versions of b2evo- 1.10.2, 2.20beta, and 2.30rc1.

1.10.2 worked fine... i was able to login and see the backoffice (oh how i miss that)... but for the 2.x series, i got the same line 446 errors...

...something weird about 1.10.2- it didn't look like the 1.10.2 that i was using before... it had a lot more smilies and video embed options in the Expert Write section. i don't remember any of those at all, and i know for a fact that 1.10.2 was the last version i had functionally installed. hmmm...

well, i'm open to any more suggestions. my attempts to import my database in myphp proved futile- whether for reasons of having diff. prefixes or just by reason of myphp being crap. so, what it's looking like now is that i'm royally fracked (oh god, did i just admit that i watch that show in public?). no going backwards and no moving forwards.

i hope some of the developers have a trick or two up their sleeves. this is unbelievably frustrating.

maybe tomorrow i'll try 2.0.0... :S

Sorry but I've nothing else to offer here. To my mind it has to be something about your host, but I've no idea what. Perhaps one of the really smart people will come along with good info?

well thanks for trying EdB. i just made a new installation of 2.0.0alpha and got a line 439 error... which is the same '$usercache' get_by_login value as before. so now i know it's all of the 2.x series that don't work with my site.

¥åßßå, Afwas, anymore ideas/suggestions? any suggestions as to what my host to do to remedy the problem? they don't really seem too concerned....

I'm pretty sure that this is a host/memory problem, if you'd like to send me a backup of your current db I'll upload it to my own server and see if it fails ( when I get a chance )

¥

shunsai wrote:

Afwas, i did change the sample.htaccess file to .htaccess before with no results. but i tried again upon your suggestion, and tried it in both my blog directory and my public html directory. still

Fatal error: Call to a member function on a non-object in /home/shunsai/public_html/blog/index.php on line 59

when trying to view the blog and

Fatal error: Call to a member function on a non-object in /home/shunsai/public_html/blog/inc/_main.inc.php on line 446

when trying to login to the backoffice. Any suggestions of flags to add to the .htaccess file?

the error lines referred to index.php and _main.inc.php respectively are:

if( (($Blog = & $BlogCache->get_by_url( $ReqAbsUrl, false )) !== false) )

and

$User = & $UserCache->get_by_login($login);

so it would seem that the problem is rooted in, or at the very least related to the cache.

Hi, I get the exact same error after installing the latest version (b2evolution 2.4.0-rc2 ).
This is on a fresh install (no previous b2evolution).
Platform is RedHat ES Linux
PHP 4.3.2

Looks like something in the code fails with BlogCache and UserCache objects.

--
Matti

mmm. that sux. to date, i still haven't been able to have this problem resolved, so my blog is still offline. i turned it over to my host to try and have them resolve the problem, but i haven't heard much back from them since... if they are able to resolve it, i'll post the outcome here. if there's anything on the development end of it, i hope this problem is figured out soon. so far no one seems to have any definitive reasons behind this particular error (blogcache, usercache)... just well-educated guesses that are difficult to prove.

¥åßßå wrote:

I'm pretty sure that this is a host/memory problem

¥

thanks ¥åßßå . i wasn't trying to discredit what you said. i believe you're right... but unfortunately i have no way of fixing that myself yet. that's all i mean. i'm waiting on word from my host... and provided they can't resolve whatever the memory issue is, i'll be forced to take my business elsewhere. but currently, there's not much i can do but wait.

¥åßßå wrote:

¥åßßå wrote:

I'm pretty sure that this is a host/memory problem

¥

Well, I have tested with the 16M memory limit (php.ini) setting as well and that didn't help.
It just looks like the caching code fails for some reason.

that's interesting. i did try adding a piece of code like that to an .htaccess file, but it didn't help. try asking your host to change the memory limit on their end and see if that makes any difference. i'm still waiting on a response from my host.

after about 2 weeks of waiting on a response from my host, it's finally arrived. let's call it 'the nail in the coffin'...

Hello

This is an issue that we cannot resolve. A few of our technicians have looked at it, and couldn't not find the sole error of it. It is possible one of the files may have been corrupted, or the software was exploited and some code was changed. You will be better off contacting the developer of the software for a fix. We will be happy to assist with any upgrading problems or installation problems, but we cannot debug 3rd party software.

Hi shunsai

feel free to quote the following to your hosts

to your hosts wrote:

Hi there,
Could you possibly confirm the memory limit allowed in php.ini? The current version of the application needs more memory than before, if you change the memory limit to 32 meg in WHM ( probably on yourdomain.com:2086 ) then this problem should be resolved.

If this doesn't cure it then could you let us know the exact hardware and any relevant versions and settings for php/apache/mysql that you provide to your customers? We make great efforts to ensure that it runs on as many variations of platforms/hardware/settings as we can.

many thanks for your attention
¥ b2evolution dev team

Hopefully they'll reply before I go grey ..... hmmm, *spots a grey hair ....... or two* :|

¥

¥åßßå, thanks for the response. before you responded though i sent my own reply to them saying

thanks for your response. just to be sure, was upping the script memory limit tried by any of the technicians? and i don't mean just by changing the value in the .htaccess file. what kind of tests were conducted to try and figure out the problem?

to which they relatively quickly responded:

Hello

I personally tested upping the memory limit, but the error outputed does not signify one that would be caused by that. Typically when memory is the issue you will get an error such as "failed to allocate xxxxx bytes of memory". That error "Call to a member function on a non-object in" is due to the script not being able to find a function in a class that is being called from (most likely missing or renamed). I have done a search for that function, and could not find any files that define the function.

but since you replied, i just told them to disregard that message and just copied-and-pasted your message. now just waiting their new response. thanks again. i'll keep you posted.

Hello,

The memory_limit in the php.ini file has been raised to 64MB. If you need anything else, please let us know.

Thanks.

hmmm. doesn't really seem like they answered the question about configuration. i still can't login or view my blog, so i'll try deleting all the files once again and re-uploading later..

deleted everything. reuploaded everything. same fatal error.

Fatal error: Call to a member function on a non-object in /home/shunsai/public_html/blog/inc/_main.inc.php on line 447

something i do find strange though is that, regardless of how many times i've reinstalled/upgraded my b2evo (even to the same version), i still always get this message before upgrading:

The version number is correct, but we have detected changes in the database schema. This can happen with CVS versions...

The following database changes will be carried out. If you are not sure what this means, it will probably be alright.

    *

      ALTER TABLE evo_items__prerendering CHANGE COLUMN itpr_datemodified itpr_datemodified             TIMESTAMP NOT NULL

and then this message after upgrading:

Checking DB schema version... 9700 : OK.
Resetting b2evolution.net polling times... OK.
Altering table «evo_items__prerendering»...

    * Changed type of evo_items__prerendering.itpr_datemodified from timestamp(14) to itpr_datemodified TIMESTAMP NOT NULL

Upgrade completed successfully!

if my database has already been upgraded (ie. 2.3.0 to 2.3.0), why would there have to be any changes to any of the tables at all? does this indicate something is wrong with my database and the tables aren't upgrading properly?

Okay let's look at that weird "table ain't right" bit. Can you create a new installation in a folder using the same exact files and compare the structure of the items__prerendering tables?

Not an upgrade - a clean installation with no "prior record of belligerence" And you can use the same exact database with the change in _basic_config I threw out there back on the first page of this thread if you want.

By "compare the structure of that table" I mean look at your database in phpmyadmin and on the left side click the name of that table. It should tell you all kinds of stuff about the table. It's the details there that are worth looking at. http://wonderwinds.com/items__prerendering.html is a screenshot of me looking at my items__prerendering table - which is 240 so don't be surprised if yours doesn't match mine. I'm just curious if your real one (the one that gives you the error) matches a database you build from scratch purely for comparison purposes.

Can't hurt yah?

re-mail to host:

Once again, thanks for your response. Could you let us know the exact hardware and any relevant versions and settings for php/apache/mysql that you provide to your customers? We make great efforts to ensure that it runs on as many variations of platforms/hardware/settings as we can.

many thanks for your attention
¥ b2evolution dev team

the reply:

Hello,

Your server is running PHP 4.3 series on the Apache 1.3 series, and has MySQL 4.0.

Thanks.

as much as i want to just throw my hands up, i cannot just give up. is there any possibility at all that this is a b2evolution bug as my host seems to suggest? fplanque? blueyed? ¥åßßå? any other devs? is there any possibility of validity of their claims that

"the error outputed does not signify one that would be caused by [the memory limit]. Typically when memory is the issue you will get an error such as "failed to allocate xxxxx bytes of memory". That error 'Call to a member function on a non-object in' is due to the script not being able to find a function in a class that is being called from (most likely missing or renamed)"?

sorry if i'm coming across as a pest with this. i've written them a lengthy trouble ticket trying to get to the root of what's at fault here. but at this point, as you may be able to tell, i'm pretty desperate.

The version number is correct, but we have detected changes in the database schema. This can happen with CVS versions...

Have you followed up on that error message? If you personally did not make any changes to your database then, to me, this is something that needs to be understood.

The best way to test that is a completely fresh installation and comparing that table in both installations.

You simply should not be seeing that message is why I say this.

@EdB: I researched on that error, but it seems the installer is taking care of a MySQL flaw:

// There's a bug with a "NOT NULL" field reported as "NULL", work around it (http://bugs.mysql.com/bug.php?id=20910):
if( $fieldtype == 'TIMESTAMP' )
{
	$ct_sql = $DB->get_var( 'SHOW CREATE TABLE '.$table, 1, 0 );
	if( preg_match( '~^\s*`'.$tablefield->Field.'`\s+TIMESTAMP\s+(NOT )?NULL~im', $ct_sql, $match ) )
	{
	$tablefield->Null = empty($match[1]) ? 'YES' : 'NO';
	}
}

I checked the MySQL site and this seems totally unrelated.

--F

Okay cool. I had a very similar issue when I upgraded to 240 because I changed my "cat url name" to not be unique. In my case the installer said it was going to fix it then failed to do so. I therefore thought this was important.

Wait a minute... Why is it saying that when shunsai "upgrades" from 230 to 230? That implies the condition was not corrected and is being detected again - no?

EdB wrote:

Wait a minute... Why is it saying that when shunsai "upgrades" from 230 to 230? That implies the condition was not corrected and is being detected again - no?

That's the bug in MySQL. MySQL reports the TIMESTAMP to be NULL where it is set NOT NULL (and actually is not null and cannot be null). But MySQL reports NULL and B2evo fixes the NULL to NOT NULL.

I was unable to duplicate that error when upgrading a brand new 230 to itself. I have MySQL version 4.1.22-standard, and see where shunsai has 4.0.25. Afwas is this known bug specific to 4.0.25? If so then the host might be convinced to upgrade the version, or at least we'll know for a fact where the problem lies. If not then it's non-standard behavior that needs to be understood.

shunsai wrote:

The version number is correct, but we have detected changes in the database schema. This can happen with CVS versions...

The following database changes will be carried out. If you are not sure what this means, it will probably be alright.

    *

      ALTER TABLE evo_items__prerendering CHANGE COLUMN itpr_datemodified itpr_datemodified             TIMESTAMP NOT NULL

and then this message after upgrading:

Checking DB schema version... 9700 : OK.
Resetting b2evolution.net polling times... OK.
Altering table «evo_items__prerendering»...

    * Changed type of evo_items__prerendering.itpr_datemodified from timestamp(14) to itpr_datemodified TIMESTAMP NOT NULL

Upgrade completed successfully!

This is quite possibly the root of all evil. In a 2.3.0-RC1 installation, itpr_datemodified is neither NULL nor NOT NULL.
Field == itpr_datemodified
Type == timestamp
Collation == blank (no value, not a value of 'blank')
Attributes == ON UPDATE CURRENT_TIMESTAMP
Null == no
Default == CURRENT_TIMESTAMP

shunsai please look at your database, select the evo_items table, then select the evo_items__prerendering table and see if the structure matches what I have here. If it does NOT match you might want to edit the field and make it match this, then test your blog.

Still this may be a problem with your version but I have no reason to suspect that because I don't know which bug in what bugs what version of ... anything! ;)

i dunno if you'll be able to make heads or tails of this, but my evo_items_prerendering structure doesn't look very much like what you have. mine says:

evo_items__prerendering
Field Type Null Default
itpr_itm_ID int(11) No 0
itpr_format enum('htmlbody', 'entityencoded', 'xml', 'text') No htmlbody
itpr_renderers text No
itpr_content_prerendered mediumtext Yes NULL
itpr_datemodified timestamp(14) No NULL


Indexes:
Keyname Type Cardinality Field
PRIMARY PRIMARY 189 itpr_itm_ID
itpr_format


Space usage:
Type Usage
Data 465,120 B
Index 5,120 B
Total 470,240 B
Row Statistics:
Statements Value
Format dynamic
Rows 189
Row length ø 2,460
Row size ø 2,488 B
Creation Feb 06, 2008 at 03:51 AM
Last update Feb 06, 2008 at 03:51 AM

btw, i should add, when i said 2.3.0 -> 2.3.0, that was just an example. currently, my databases should be updated to 2.4.0 (i tried installing it once it came out)... so any reinstallations i've done since then have been 2.4.0 -> 2.4.0.

i'm not sure how much of a difference that makes in the tables structure.

i wish i knew if it were just my account with my host or all hostrocket users. i'm really starting to get suspicious about them. many of my options in my controlpanel do not seem to work as they should. also, i have an email from them from september 2007 that says "all shared hosting servers will be upgraded to PHP 5 on or after November 27th, 2007" but if i'm reading their replies and my controlpanel correctly, the server my account is on is still at php 4.3.11. also phpMyAdmin for me is version 2.10.0.2... a version that hasn't been updated in over a year (the current available version is 2.11.4).

i don't know that any of these specific issues are what's at the root of my upgrading woes, but i must say that they haven't really done much to inspire my trust. consider this msg i wrote, and their reply:

dear hostrocket support team,
I don't really understand what is at the root of this script error and why hostrocket seems to be in the minority of hosts not compatible with the latest b2evolution. someone mentioned not being able to debug 3rd party software. i don't really know how to respond to that. i'm somewhat caught in the middle- everyone is saying 'it's not my fault... it's their fault... it's your problem... tough cookies'. fine. it is my problem. does this mean hostrocket has reached the limits of what they're willing to do to ensure compatibility with this b2evo script- this script i was first introduced to by hostrocket by the way.

has anyone been able to get the 2.xx version of the b2evo script running on a hostrocket server? or is it just an isolated incidence? is anyone concerned about this at all? my page seems to be constantly being hacked by moroccan internet terrorists. i get internal server errors more often than i would like. my guestbook script has magically disappeared altogether and no alternative guestbook script has been offered. and now, the final straw- my host is no longer compatible with the updated version of the blog script they introduced me to. what am i realistically supposed to do? realistically, go to the developers and tell them 'hey, you have a bug in your script, and it only affects a miniscule fraction of the people who use it'? well, i'm still trying that. but i can't quickly rule out the possibility that it's possibly a serverside/host problem either.

to be honest, i'm becoming increasingly dissatisfied with the level of service i've been getting from hostrocket lately. responses have been somewhat slow and curt recently, as if i'm a problem that no one really wants to deal with.

but getting back to technical issues, i'm curious as to why within the control panel, certain functions don't seem to work. for example:

1. in the 'PHP Pear Packages' option i always get the following message when trying to show available extensions ("There was a problem fetching the list of available modules.").

2. in the 'PHP Configuration' option, at the top of the page it says ("These PHP configuration settings are customizable by the server administrator. They are listed for reference only... Maximum amount of memory a script may consume 8MB"). if it says that the configuration is customizable, and the limit has been raised to 64mb, why does it still say 8MB is the limit?

3. in the 'Backups' option, when i try uploading a MySQL Database, it takes me to a "Restoring Database" screen that stays that way indefinitely... nothing changes.

4. in 'phpMyAdmin' option, when i try importing a database, i always get an error.

of the 7 or so options i use, only 3 work for me. so if not debugging, what kind of support is it that i can ask for exactly?

i apologize if this sounds rude or insulting. it is not my intentions to insult anyone at hostrocket. but i do want to respectfully convey my mounting frustrations with my website that seems to be growing more and more pointless everyday. i hope someone takes the time to read this carefully and respond equally as carefully. i'll end by saying that for the most part, i have been satisfied with hostrocket's service in the past.

the reply:

Hello,

Please provide us with the URL of the b2evolution script that is giving you a problem at this time. The URL you referenced in an earlier response does not appear to be the version we were initially discussing. The PHP pear package listing and PHP configuration listing are not accurate. If you want accurate information, you can create a PHP script with the following syntax:

<?php

phpinfo();

?>

Calling that in a browser would show you all applicable variables and installed extensions.

Restoring large databases can frequently result in timeouts. If that happens, you can restore your database via an SSH session using the MySQL command-line utilities. If you are not familiar with how to do this, you can upload the backup via FTP to your account, and we can restore it for you.

We have not had any other complaints of problems with b2evolution. If all else fails, we can try moving your account to a newer server to see if that helps the situation.

Thanks.

i get the feeling they're more trying to confuse me in hopes that i'll give up and go away rather than actually helping me. but i'm a believer in the squeaky wheel getting the grease. i guess i'll keep nagging them until they decide to drop me as a customer or my contract expires in june (whichever comes first).

oh yeh, EdB, before i forget:

localhost

* Server version: 4.0.25-standard
* Protocol version: 10
* Server: Localhost via UNIX socket

phpMyAdmin - 2.10.0.2

* MySQL client version: 4.1.22
* Used PHP extensions: mysql

that's according to phpMyAdmin. apparently i am running MySQL 4.1.22. i'm not sure what the 4.0.25-standard refers to. can anyone clarify?

I dunno if they're trying to "impress you to shut you up" or actually think they're helping by talking in a manner most folk don't understand. People deeply into this stuff tend to sometimes speak too much geek for a regular person to understand, but their reply did seem a bit ... uncool I guess.

So yeah I think this is fixable but you'll have to fix it or PM me your login credentials so I can get to your phpmyadmin place. http://wonderwinds.com/items__prerendering.html is still there, and since you're using 240 your evo_items__prerendering table itpr_datemodified thingie should look like mine. Meaning the attribute and default should be what is in that image and my post above. Get to that screen and check the box and click the icon for "edit", and make them be what mine are.

Then test your blog. No more installing over and over - just make the change and see if you can load your blog and get to your back office.

Or shoot me some login creds and I'll give it a go. If it doesn't work I'll set things back as they are now and we won't be any worse off for trying.

i kinda misinterpreted your previous post, but i've checked the link you sent me now (http://wonderwinds.com/items__prerendering.html) and compared it with my own phpmyadmin and all seems to be the exact same with a few minor exceptions.

for one, i don't have a 'collation' column nor any latin1_swedish_ci values. two, in your 'itpr_datemodified' field, whereas yours says 'timestamp' for the type, 'on update current_timestamp' for the attribute and 'current_timestamp' for default, mine reads 'timestamp(14)' for the type while attribute and default values are both blank.

i'm not sure what timestamp(14) means, but if i were to guess, it would be the fact that there is a 14 hr time difference between where i reside (in osaka, japan) versus where my account/host physically are (somewhere within EST zone).

I was wondering about the (14) part. Could easily be the offset from GMT - especially if that is how many hours away from it you are :)

Our MyAQL versions are different which can explain the extra column in my tables. Yours is findable at http://shunsai-inc.com/blog/install/phpinfo.php and mine is at http://wonderwinds.com/install/phpinfo.php with both being a little bit more than half-way down the page.

Look you've been beating your head against this for a long time now right? So visit that table and edit that field and change the two items that you have that don't match mine. They're both blank for you - attribute and default value - but not for me. I forget and would have to scroll but if you make them match mine and it doesn't work you can edit them back to what they are now yah?

Oh and I was wrong in saying "no more upgrading" because your blog won't show. It looks like you have the files for 1.10.3 installed again? IF you are trying to downgrade to that version then (a) forget about modifying the table and (b) you need to DROP all the tables in your database and restore a known good backup. Or - again - upload the files for 240 and try editing the table.

OT: Doesn't it suck when you find out you're not really getting what you paid for with hosting services? My host is kinda overpriced but when I have problems they respond with "human friendly" answers. I like that yah?

default 14 chars (length) in timestamp: 21:04:2002 13:25:59

Hi Shunsai,

Sorry it's taken a smidge, I got busy. I uploaded your 2.3.summat database and upgraded it to 2.4.whatever with zero problems.

The main differences between my setup and yours ( apart from the fact that I have a blonde for a host ) is that I run php/myql 5.summat

If you want to have a meander round the install ( your user/pass will be the same ), you can find it here ( [url=http://shunsai.innervisions.org.uk/]http://shunsai.innervisions.org.uk/[/url] ), and you can find the phpinfo here ( [url=http://shunsai.innervisions.org.uk/phpinfo.php]php info[/url] ). You may like to point your hosts to both of those links.

You may also like to inform your hosts that PHP4 is unsupported from August this year :
php.net wrote:

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

I'd take them up on their offer to move you to a newer server, but I'd demand one that ran php/mysql 5.summat

¥

*edit*
Ohh yeah, and ask them to slap you on one where suexec is installed which will save you shedloads of permissions problems ;)

man ¥åßßå, you have no idea how good it is to see my blog breathing again... even if in a temporary, cloned body. thank you so much for testing this for me! so this verifies that the problem isn't my database and it isn't b2evolution. i hope i can convince my host of that.

actually, i'm actually starting to feel like this nightmare might be resolved in a satisfactory way afterall. thanks for your help. and you too EdB, i really appreciate your unrelenting efforts to help me (and hopefully others with this problem) troubleshoot and get to the bottom of this. oh and Afwas, thanks for the tip. what a coincidence- 14 characters, 14 time zones.

now to bring the battle to hostrocket and see what they have to say...

If you wish to use your blog on it's temporary home feel free, I can always do you a fresh backup when your host is sorted.

The chances are that if they move you to a php5 server ( with mysql5, and suexec, in for a penny in for a pound huh ;) ) then all your worries will be over ;)

¥

i wish i had understood a lot of this sooner. on the b2evo requirement page it says

PHP Related Dependencies

Make sure that *if* (not all hosting providers use it) your PHP info says anything about a Zend Optomizer that the version is 2.6.2 or newer. That means that 2.6.3 is fine but 2.6.1 is not. You will also want to make sure that your Zend Engine is newer than 1.3. The reason for this is that the older versions have bugs in them which cause this software page not to behave properly in certain circumstances.

comparing that to my phpinfo page

Zend Extension 20021010

This program makes use of the Zend Scripting Language Engine:
Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies with the ionCube PHP Loader v3.1.32, Copyright (c) 2002-2007, by ionCube Ltd., and with Zend Extension Manager v1.0.6, Copyright (c) 2003-2004, by Zend Technologies with Zend Optimizer v2.5.7, Copyright (c) 1998-2004, by Zend Technologies

looks like the Zend on the server they had me set up on was a few years outdated.

well, their latest response to my latest rant is

Hi,

We are in the process of copying your account to a server running php5 suexec, and mysql5. We will reply back once the transfer is complete with your new IP address.

i have no idea how long that will take, but hopefully all this will be over soon. *holds breath till then*

well, it appears the pre-nightmare is over!

Hi,

Your account transfer is complete. I have updated the DNS to point to the new server, but it will take around 1-3 for the domain name to point there. I have left the other account on the old server for now,while we see how it goes on the new server for you. Please look over your site to see if the new server fixed the issues that you were having on the old one.

Once you have checked over the site, please reply back and let us know the results.

Thank you for choosing HostRocket!

i've checked it and am now able to login to the backoffice. the upgrade went off without a hitch, no errors whatsover.

so my advice to anyone else getting FATAL ERROR messages (at least the ones referring to $usercache and $blogcache) are to first check your phpinfo in the install directory, and determine what the version numbers are for PHP, MYSQL, and Zend Optimizer. personally, i think my problem was related to Zend, because, even though my PHP and MYSQL were old versions, they were still listed as compatible in b2evo's system requirements. the one thing that seems to have been outdated and clearly stated as outdated in b2evo's system requirement was Zend.

i read on wikipedia that Zend is an alternative type of PHP accelerator, that unlike typical PHP accelerators, has no code caching feature. so it doesn't seem that its a coincidence that my host was running an extremely old version of Zend and that b2evo was returning cache related errors.

the memory_limit as others stated is probably good to check, i but i would first suggest checking phpinfo and determing the versions of software installed. chances are, something is outdated.

thanks again to all who helped- EdB, ¥åßßå, Afwas, et al. your help was indispensible (wish i could say the same for my host). now i can catch up with the rest of the b2evo 2.xx community who have been having functionality problems (as opposed to 'getting started" problems). time to look about updating my old skins...

I never even thought of zend :p

Glad it's all working for you now :D

¥

oh yeah... how could i forget-

¥åßßå-dåßßå-doooooo!!!

lol

First off, thanks to everyone (especially shunsai) for saving me the headache of going through this myself! I too am having the fatal error:

Fatal error: Call to a member function on a non-object in /home/oxrocke/public_html/blogs/index.php on line 59

I have a shared hosting account on hostrocket as well and have just put in a trouble ticket referring to this post to see if they will help me. It was tricky even getting b2evolution to install on hostrocket's server and I have had several correspondence with them regarding b2evo up to this point.

Anyways, just had to post to give this thread a thumbs up... keeping my fingers crossed that I will receive similar treatment - I don't relish the idea of switching hosts right now... ;)

hope it works out for ya! you can report back here when you know the results.