Thread

Thanks Robin, nothing yet-

Yep- definitely something going wrong with the system generated emails.  I sent one directly from my EL mail to the addy associated w/your forum account.  Should be there now- if not… we really are in trouble!

We can stick to that while we hash through things.  Thanks!

Nope, still nothing…

Not sure what’s going on with that- try firing off an email to me at .(JavaScript must be enabled to view this email address) and I’ll see if replying works.

In the meantime, I’ll go ahead and post here.  Want to make sure I have plenty of time to do the update if that proves to be a good option.

Do you have a backup of the database available- the one from before the upgrade? I’d like to run through the upgrade process myself- it looks like some steps were missed and the best way to ensure the integrity of the db is to run it fresh while I take care of any issues.

Either FTP it up and link me, or go ahead and replace the current db (preferable). Let me know if it’s possible and that I’ve got permission to re-run the updater on this one. I can try to manually fix things, but I’m worried I’ll miss something. A fresh update is the better call.

Thanks,

Robin

Thanks Robin, I’ve sent an email as well- the site has been rolled back to where I was before, I have a backup of the DB and the site files. For whatever reason the footer in the CP says v 2.1.3, I know it’s not- the build gives 20101220.

Curious, why is the warning telling me to install version 2.2.2?

Pretty sure 2.1.3 is what was in your old config- though I’ll double check once I FTP back in.  But then the warning should be for 2.1.4!  Hrm.  I’ll figure it out.  Pretty easy to track the version via build+DB changes.

Anyway- off to step it through and hopefully figure out what’s up!  And I did get/reply to your email.  Hopefully you’ll get mine, but if not the forums should work well enough.

Wow- that was irksome.  OK- first, go in and test things out.  I ran through the update (it failed once- it was some kind of weird caching thing where it was reading the version from the config as 2.1.5 instead of 2.2.0- which was actually IN the config.  I forced a php error to get it to clear!).

Anyway, will ponder on that after you can get in and check things out.  From here, things look fine.  That said?  Make sure your theme folder has been updated- there have been some changes since 2.1.3, which really is what I think you were running.  Could have been 2.1.4, but 2.1.5 db changes were definitely needed.

Also- move over any third parties from ‘old’- I do what you do, just rename the old system folder. 

Then give it a good test out and let’s see if everything checks out solid.

Thanks Robin, everything seems to be good- re it being 2.1.3, I was looking too quickly and thought it was telling me that it was 2.3.1, so that was probably the correct version before the upgrade.
This is the first of maybe a half-dozen sites I need to bring up to speed, one that I’m looking at right now is definitely v 2.1.3 and the notice tells me to upgrade to 2.2.2- why isn’t it telling me 2.3.1? Am I looking at the same procedure for all of the upgrades I need to do? Should I wait for 2.3.2? This wasn’t the first site I’ve tried to bring up to speed, but it was one I could afford to let languish while we (you) figured out what was wrong. The rest can’t go like that…

Thanks for your help-

Ha- yes, I’ve done that with 2.1.3 before as well- once spent half an hour trying to figure out why I couldn’t find a bug.

What I believe is happening in all cases is that it’s reading the version number from cache, rather than from the actual updated file.  So in the case where I ran it- it updated through a few and then wrote version 2.1.0 but when it read from cache?  It saw 2.0.0 still and thus tried to run the 2.1.0 update over again- which generates mysql errors if it tries to make a change that’s no longer possible.

I recall seeing it a few times in the past, and the only way to get the server to clear the cache was to introduce a php error.  So- I asked Pascal what’s up that a server would do that- and he pointed to APC or other op-code caches (and we are now in the server realm and I just nod along with him vaguely).

So I believe that’s what’s happening.  2 options- talk to your server admin, see if that seems to be the case, see if they can do something about it.  Even if it’s ‘turn it off when I update’.  This would be my preference for the long haul, sense 9 times out of 10, rerunning an update won’t actually hurt anything, though it may cause a mysql error.  But sometimes- say the 2.0 update- it will actually hurt the data.  (i.e., you don’t want to run the utf8 conversion twice or you get jibberish).

That said?  For the short term, there’s nothing in the updates you need to run that will be hurt by rerunning.  Here’s how I did the successful update:
1. Run update as usual
2. If it hits mysql error?  FTP in, look at cache- note the version number.  It writes that at end, so you KNOW those changes happened.
3. To be on safe side (you can probably skip this- we pretty much know it’s a cache issue), look at the NEXT update file and make sure it hasn’t already run any of those db changes.  I’d say in your case?  99% chance it hasn’t.)
4. K- fine.  Just start the wizard overagain at the beginning by going to mysite.com/system/index.php.
5. When it shows you the version you are running?  It will probably be wrong.  So the config may show 2.1.4 but the installer tells you you’re on 2.1.3.  AHA- cache issue!
6. IF it’s the cache issue- bleh.  Go make a php error in your cache file.  I just plopped some text in like

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');

blarg

/*
|--------------------------------------------------------------------------
| ExpressionEngine Config Items
|--------------------------------------------------------------------------

7.  Reload that wizard page- you get a blank screen from the php error.  Comment out the error- and reload page.  It should see the right version number now.  Carry on with the update.

I only had to php error once- but if it happened again- just check that config version number is not seeing what the wizard is seeing- introduce error to clear out that cache- and carry on.

I realize this is super clunky, but there’s not anything we can do on the php side about that caching behavior.  It’s super rare when it comes up, but it looks like what’s happening here.

Like I say- best thing to do is see if it can be addressed on the server side w/the caching behavior.  But if you need to push through an update?  It’s not hard to do.  And waiting for the next release likely won’t help, as it’s really a server cache issue.  And EE is just not able to see the real config while being served the cached config.

Did that all make sense?  And did it help?

Thank you Robin, it makes some sense- the server cache setting is messed up. The sites in question are on a managed VPS so I have quite a bit of access and can lean on the provider for help but, well, I’m not sure what I’m supposed to ask…

Hrm, I’d try something like:

I’m running a PHP CMS that writes to a config file to store some key settings.  When updating, it reads and writes to that cache file.  It successfully writes the new information, but sometimes it seems to be reading the old information, rather than the information that was just written to the file (though I can see the new information when I open the file via ftp).

The only way to immediately ensure it reads from the newest version of the config file is to introduce a PHP error.  It’s been suggested that the server is delivering a cached version of the file in these cases (APC or other op-code caches).  How can I make sure that config file isn’t cached by the server?

Not sure this will do the trick?  But I’d start with something like that and see what they come back with.

Thanks! I’ll do just that-

Sounds good- I’m going to leave this one open.  Let us know what you hear!

Okay, after a little back and forth with the server admin we ended with the following:

I’ve removed eAccelerator from your server.

——————
root@host [~]# php -v
PHP 5.2.17 (cli) (built: Apr 30 2011 15:09:40)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies with the ionCube PHP
Loader v4.0.9, Copyright (c) 2002-2011, by ionCube Ltd., and with Zend Optimizer v3.3.9, Copyright (c) 1998-2009, by Zend Technologies

I attempted an upgrade from 2.1.3 to 2.3.1, same process, several browsers, the first error I received:

A Database Error Occurred
Error Number: 1050

Table ‘exp_file_watermarks’ already exists

CREATE TABLE `exp_file_watermarks` ( `wm_id` int(4) UNSIGNED AUTO_INCREMENT, `wm_name` varchar(80), `wm_type` varchar(10) DEFAULT ‘text’, `wm_image_path` varchar(100), `wm_test_image_path` varchar(100), `wm_use_font` char(1) DEFAULT ‘y’, `wm_font` varchar(30), `wm_font_size` int(3) UNSIGNED, `wm_text` varchar(100), `wm_vrt_alignment` varchar(10) DEFAULT ‘top’, `wm_hor_alignment` varchar(10) DEFAULT ‘left’, `wm_padding` int(3) UNSIGNED, `wm_opacity` int(3) UNSIGNED, `wm_x_offset` int(4) UNSIGNED, `wm_y_offset` int(4) UNSIGNED, `wm_x_transp` int(4), `wm_y_transp` int(4), `wm_font_color` varchar(7), `wm_use_drop_shadow` char(1) DEFAULT ‘y’, `wm_shadow_distance` int(3) UNSIGNED, `wm_shadow_color` varchar(7), PRIMARY KEY `wm_id` (`wm_id`) ) DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

Filename: updates/ud_215.php

Line Number: 317

Hit the “back” button, then this error, which stops the process cold.

A Database Error Occurred
Error Number: 1060

Duplicate column name ‘batch_location’

ALTER TABLE `exp_upload_prefs` ADD `batch_location` VARCHAR(255)

Filename: updates/ud_215.php

Line Number: 169

I went in to the cache folder (system/expressionengine/cache) however there are no files to add an error too…

Blast- I give the worst directions every.  It’s a server cache issue rather than an EE one.  Which means it’s seeing an ‘old’ version of the config file (not the cache file like I typed).

So when it fails- the file you need to look at is system/expressionengine/config/config.php.

If after failing- you go to the START of the wizard- which you hit with a url like mysite.com/system/index.php - and start the update from there, it tells you what version you are currently on.  Compare that version with the version number in system/expressionengine/config/config.php - if they are NOT the same?  It’s reading a from some kind of server cache and trying to run an update that’s already happened.

Introduce the error in the system/expressionengine/config/config.php file.  Reload wizard start page.  It white screens.  Fix error.  Reload wizard- the version it tells you you are on should now match the version in the config file.

Also- ‘bleh’ on that not fixing the cache issue, which is what I’m still betting is happening.

That help?