By fitness trainer on

Just wondering if anyone's upgraded to 6.4 yet...I am going to, but wanted to know if there's been problems.

I'm a newbie, and it was a bit of a hassle simply installing 6.3 in the first place (I knew practically nothing about servers, and nothing at all about databases), but now I have to upgrade and the "upgrade.txt" instructions have me a little puzzled: am I supposed to disable all the modules I can disable? The instructions say to disable all custom modules and contribs...does that mean every module which can be unchecked (disabled), or only non-core modules??

IOW, does "disable all custom modules and contribs" mean "disable non-core modules", or does it mean something else....

⋅ Categories: Drupal 6.x

Comments

petiar’s picture

petiar commented

Although I am not 100 per cent sure, I think you have to disable only non-core modules. I have done that like this when I have been upgrading to 6.3 and the upgrade was successsful.

Can anybody confirm? I would not like to get into the conflict with fitness trainer if his webpage will get fucked up. ;-)

--
Petiar
The biggest slovak folk music magazine proudly uses Drupal
http://folk.sk

--
Petiar
http://petiar.sk

attiks’s picture

attiks commented

i can only speak for myself, but just upgraded 4 sites from 6.3 to 6.4, no problems encountered. I didn't disable anything, just ran update, checked logs, ran cron, checked updates, all OK

PS: I tried this on a test server first

Attiks - graphic design and web applications

Attiks - Print and web design

petiar’s picture

petiar commented

Well, if you test it first, then fair enough you can go for it even without disabling modules. But it always depends on what modules you are using. Also, upgrading to newer version of Drupal core is always good chance to make upgrade of all your modules, so I definitely would recommend to disable them.

Nevertheless, we still don't have satisfying answer to what has been asked.

--
Petiar
The biggest slovak folk music magazine proudly uses Drupal
http://folk.sk

--
Petiar
http://petiar.sk

jdenniss’s picture

jdenniss commented

I just upgraded my site from 6.3 to 6.4 with mostly no issues. I did disable all of the non-core modules.

I also updated several modules after the fact with no show-stopping issues. I am getting an error message (below) on some of the admin pages now and I'm not sure what module is associated with it and I'm currently clueless about how or what to remove/add to the mix.

Warning: Got a packet bigger than 'max_allowed_packet' bytes query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1640694:\"Got a packet bigger than 'max_allowed_packet' bytes\nquery: UPDATE cache_menu SET data = 'a:966:{s:10:\\"front_page\\";a:26:{s:5:\\"title\\";s:0:\\"\\";s:13:\\"page callback\\";s:10:\\"front_page\\";s:16:\\"access arguments\\";a:1:{i:0;s:16:\\"access frontpage\\";}s:4:\\"type\\";i:20;s:6:\\"module\\";s:10:\\"front_page\\";s:14:\\"load_functions\\";s:0:\\"\\";s:16:\\"to_arg_functions\\&quot in /var/www/localhost/htdocs/DP/includes/database.mysql.inc on line 128

-Anti-’s picture

-Anti- commented

> I also updated several modules after the fact with no show-stopping issues

But did you remember to run update.php (which needs to be run everytime you upgrade any module)?
Also, after update.php, go to admin > performance and clear the cache (even if you don't have any
caching enabled).

If those two things don't clear the issue, I think the usual way of troubleshooting would be
to disable contributed modules one by one, until the error disappears. Then enable all the
others again to check that the problem is definitely cleared and that you've correctly
identified the troublesome module.

jdenniss’s picture

jdenniss commented

I did run update.php after the module upgrades. Hadn't cleared the cache (don't have it enabled - we're not really in production, yet). Didn't seem to make any particular difference in this circumstance.

I've backed off modules and disabled the offending one (no php-oid nastygrams). Now comes the process of reintroducing them and identifying the culprit(s)

Ok, I have the list of what I can't seem to enable without generating errors - [ Notifications, Tabbed Block, Profile Plus, Printer Friendly Pages (core), and Organic Groups ]. I have no idea if this is a 6.4 issue or problems with the modules themselves - some are in beta or are rc's or some other config problem with my setup.

jdenniss’s picture

jdenniss commented

Hmmm. There's definitely a problem here.

I discovered that the backup module wasn't configured in after the upgrade. Though it was working flawlessly under 6.3, It now also generates errors when enabled. I'm suspecting a problem with the info strings in the system table, but haven't found a problem yet.

When I enable the module and click the submit button I get:

Warning: Got a packet bigger than 'max_allowed_packet' bytes query: INSERT INTO watchdog (uid, type, message, variables, severity, link, location, referer, hostname, timestamp) VALUES (1, 'php', '%message in %file on line %line.', 'a:4:{s:6:\"%error\";s:12:\"user warning\";s:8:\"%message\";s:1553340:\"Got a packet bigger than 'max_allowed_packet' bytes\nquery: UPDATE cache_menu SET data = 'a:907:{s:10:\\"front_page\\";a:26:{s:5:\\"title\\";s:0:\\"\\";s:13:\\"page callback\\";s:10:\\"front_page\\";s:16:\\"access arguments\\";a:1:{i:0;s:16:\\"access frontpage\\";}s:4:\\"type\\";i:20;s:6:\\"module\\";s:10:\\"front_page\\";s:14:\\"load_functions\\";s:0:\\"\\";s:16:\\"to_arg_functions\\&quot in /var/www/localhost/htdocs/DP/includes/database.mysql.inc on line 128

There's more - a lot more - and it displays every time I go to the 'list modules' page. It looks to be the same sort of errors I was seeing with the other modules.

I haven't done a lot of poking around on the 'user' side, but the site still seems to be mostly functional. Only seeing problems on the admin side.

Any ideas, anyone?

-Anti-’s picture

-Anti- commented

> I think you have to disable only non-core modules
> Can anybody confirm?

Yes, I think so too.

custom = your own modules
contrib = downloaded modules

Having said that, when I upgraded from 6.2 -> 6.3 I didn't disable any modules either.
I just ensured cron wasn't about to run, and that the site was offline to users.
However, I did take a full file/database backup before doing anything.
I'd probably only actually disable the modules if I was upgrading between major versions (Eg. 5x -> 6.x).

Just one other thing I would advise: If following best-practice in directory structure, the only folder you should have to back-up is the '/sites' directory. However, quite a lot of stuff in there seems to be chmodded to 555. Depending on how you back up, your ftp client might not copy across those folders/files and it might not inform you that they weren't backed up. So double check that everything in /sites was actually copied. Usually I batch-chmod everything in /sites to 755 before compressing the directory to ensure this.

Cheers.

nirvanajyothi’s picture

nirvanajyothi commented

Thats right.No need to deactivate the CORE modules.

There is a good video here http://learnbythedrop.com/drop/70 .May be helpful.

Medicine,Surgery ...and Drupal.

KaLeL16’s picture

KaLeL16 commented

for some wierd reason i just uploaded update.php and overwrote the existing one
and when i check the version of my drupal its saying tis upto date. Did i do something wrong here?

KaLeL16’s picture

KaLeL16 commented

does anyone wanna help a newbie out? =)

attiks’s picture

attiks commented

overwriting update.php isn't a problem, the version info is installed into the database. You have to overwrite all files and folders, you might skip the files directory but it is safe to overwrite it as well

Attiks - graphic design and web applications

Attiks - Print and web design

KaLeL16’s picture

KaLeL16 commented

ok i tried uploading the 6.4 settings.php but it wont overwrite it. im using cute ftp and ive set the permission and it still wont overwrite

-Anti-’s picture

-Anti- commented

> ok i tried uploading the 6.4 settings.php but it wont overwrite it

The /default directory also has 555 chmod.
You need to chmod that to 755 too, because the permission is recursive.

My ftp client has an option to 'batch-chmod' all folders and files within a parent directory.
If you client doesn't have that option, you need to chmod /default and all folders and files in it individually.

attiks’s picture

attiks commented

You shouldn't override settings.php, it isn't even included in the drupal tar ball (?) and it contains the connection details for the database (amongst other things), you should upload everything in the tar ball except the sites directory.

Attiks - graphic design and web applications

Attiks - Print and web design

-Anti-’s picture

-Anti- commented

Yep, sorry, I didn't read what you were trying to do, within the context of upgrading. There are situations in which you want to copy a new defaults folder (ie. cloning a live site to a dev site).

But for upgrading drupal, you want to replace everything *except* for the /sites directory and its contents (well, if you follow best practice, and have all your custom files in the sites directory).

kenorb’s picture

kenorb commented

#357938: max_allowed_packet on admin/build/modules page
#317775: Caching entire {menu_router} table causes MySQL error/slow rebuilds and slows menu_link_save