I had patched 4.6.1 to 4.6.2. When I tried to apply the most recent patch, I get the following:

$ patch -p0 < ../xmlrpc-4.6.2.patch 
patching file xmlrpc.php
patching file includes/xmlrpc.inc
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file includes/xmlrpc.inc.rej
patching file includes/xmlrpcs.inc
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file includes/xmlrpcs.inc.rej
patching file modules/blogapi.module
Hunk #3 succeeded at 174 with fuzz 2.
Hunk #4 succeeded at 191 with fuzz 2.
patching file modules/drupal.module
patching file modules/ping.module

Can I just copy the includes/xmlrpc* files from the 4.6.3 installation over to my current installation?

Comments

nsk’s picture

I used this:

wget http://drupal.org/files/projects/drupal-4.6.3.tar.gz

mkdir backup

cp -a drupal/* backup/

cd drupal

rm xmlrpc.php

cd ..

tar -zxvf drupal-4.6.3.tar.gz

cd drupal-4.6.3

cp -uri * ../drupal/

cp xmlrpc.php ../drupal/

--
NSK, Admin of Drupal-based site http://www.wikinerds.org

noneck’s picture

this was quite helpful in the 3 upgrades i did today!

noel

white cat’s picture

Please be advised, I Am Not A Drupal Expert.
I have not tested this extensively, but it seems to work fine, so as ever proceed with caution, perform backups, etc.

I have done this on a few of my drupal sites and it works well.

N.B. I am upgrading from 4.6.2 to 4.6.3.

From the 4.6.3 package extract only :

modules/*
includes/*
xmlrpc.php

thats everything from the modules directory and everything from the includes directory and the xmlrpc.php file.

Using FTP ( or as you prefer ) transfer the above and overwrite - thus preserving what is not changed.

and that is it.

Thanks to chx who informed me of this easy method to upgrade.

FlemmingLeer’s picture

If you cannot patch xmlrpc.php via a linux setup use the file mentioned above in the link by nsk and extract xmlrpc.php.

And simply upload it to your server.

That should do it.

Winrar can extract the file.

gbanse’s picture

So the only affected file is xmlrpc.php?

wernst’s picture

Comparing my tarballs for 4.6.2 and 4.6.3 reveals about half a dozen files with new dates in the includes folder and another half dozen in the modules folder, along with xmlrpc.php.

The "patch" only changes 6 files in total. So obviously, the 4.6.3 package has things that the patch doesn't.

I just copied over ALL the files in the above mentioned folders to the server, overwriting destination files. Seems to work just fine for me.

-Warr

chx’s picture

The patch contains only security fixes. As we switched XML-RPC libraries, this means xmlrpc.php, xmlrpc.inc, xmlrpcs.inc, blogapi.module, drupal.module and ping.module. Other bugfixes have affected other modules, but that is not in the patch.

Removing xmlrpc.php cures the problem because you disable the whole XML-RPC server with that.
--
Read my developer blog on Drupal4hu.

--
Drupal development: making the world better, one patch at a time. | A bedroom without a teddy is like a face without a smile.

FlemmingLeer’s picture

So what you are saying is that only taking xmlrpc.php from 4.6.3 package is not enough.

sepeck’s picture

Absolutly. Removing one file prevents the security issue if you are not updating. xml-rpc has changed significantly and that involves other files. In addition, there are several smaller bug fixes that were corrected as well.

Rather than trying for a shortcut, why not just follow the full upgrade instructions provided in the install.txt file?

-sp
---------
Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide

the_other_mac’s picture

Because some of us don't have shell access to our webservers, but do have modified modules that we would like not to overwrite. Please be patient with those of us who are not omnipotent.

sepeck’s picture

I am not omnipotent and that was kind of rude. I am tryin gto help, if you don't want any then that's fine.

The security workaround for not being unable to upgrade is in the first paragraph of the announcement. http://drupal.org/drupal-4.6.3

I assume you have some sort of file transfer access to your server. Modifying core files always leaves you with this configuration annoyance and that is why it is to be avoided if at all posible. I realize that there are some contrib modules that rely on patches to core modules so....

I assume that you would maintain a local mirror of your files and a log of what you have done. This will allow you to more rapidly resolve these updates. I certainly don't patch files on my live server, that would mean I have development tools on it.

-sp
---------
Drupal Best Practices Guide - My stuff Black Mountain

-Steven Peck
---------
Test site, always start with a test site.
Drupal Best Practices Guide