HowTo: Bugfix file too large for wordpress importer

During the update to WordPress 3.2, I encountered (like many other people) the problem with limitation of the filesize for file uploads. Per default PHP will set it to 2MB whereas my wordpress export backup file (XML) has already 4MB. No, reconfiguring PHP’s upload_max_filesize was no option for me as far as the backup was already stored as a dump at the server. So my only thing to do was to replace the uploaded file with the already existing at the harddisk and make WordPress recognizing it. And this was not that difficult if you know where to look for. So here is my patch to get the wordpress-importer import a file already stored at the server hard disk. The wordpress export file to load has to be stored at wp-content/uploads/wordpress.import.xml.

diff --git a/wp-content/plugins/wordpress-importer/wordpress-importer.php b/wp-content/plugins/wordpress-importer/wordpress-importer.php
index 5e38484..e0cace0 100644
--- a/wp-content/plugins/wordpress-importer/wordpress-importer.php
+++ b/wp-content/plugins/wordpress-importer/wordpress-importer.php
@@ -102,6 +102,7 @@ class WP_Import extends WP_Importer {
         * @param string $file Path to the WXR file for importing
         */
        function import( $file ) {
+               $file = ABSPATH . 'wp-content/uploads/wordpress.import.xml'; #wp_import_handle_upload();
                add_filter( 'import_post_meta_key', array( $this, 'is_valid_meta_key' ) );
                add_filter( 'http_request_timeout', array( &$this, 'bump_request_timeout' ) );
 
@@ -132,7 +133,7 @@ class WP_Import extends WP_Importer {
        function import_start( $file ) {
                if ( ! is_file($file) ) {
                        echo '<p><strong>' . __( 'Sorry, there has been an error.', 'wordpress-importer' ) . '</strong><br />';
-                       echo __( 'The file does not exist, please try again.', 'wordpress-importer' ) . '</p>';
+                       echo __( 'The file '.htmlspecialchars($file).' does not exist, please try again.', 'wordpress-importer' ) . '</p>';
                        $this->footer();
                        die();
                }
@@ -188,7 +189,7 @@ class WP_Import extends WP_Importer {
         * @return bool False if error uploading or invalid file, true otherwise
         */
        function handle_upload() {
-               $file = wp_import_handle_upload();
+               $file = array('id' => 4869, 'file' => ABSPATH . 'wp-content/uploads/wordpress.import.xml'); #wp_import_handle_upload();
 
                if ( isset( $file['error'] ) ) {
                        echo '<p><strong>' . __( 'Sorry, there has been an error.', 'wordpress-importer' ) . '</strong><br />';

I did not put any further (compatibility) research into that issue. Worked for me™ with WordPress Version 3.2 and PHP Version 5.3.

WordPress FAQ: Import and Export

HowTo: Bugfix file too large for wordpress importer

Math behind “Rope around the globe”

Some people will know the mathematical problem:

Take a rope and tie it around a tennis ball very tightly. Cut the rope and add an extra meter of length. If you lay the rope around the tennis ball in a circle again, you will get a distance of 16 cm between the rope and the ball.

Now consider the same for the earth. Assuming a perfect globe with an equator of 40 000 km and an additional meter for the rope: What will the distance between earth and the rope be?

Tennis ball (3.35 cm radius):

U1 = 2 × 0.0335 × π
U2 = U1 + 1
r2 = U2 / 2π
r2 = ~0.19265 m
r2 – r1 = 0.19265 – 0.0335 = +0.15915m

Globe (40 000 m radius):

U1 = 2 × 40000 × π
U2 = U1 + 1
r2 = U2 / 2π
r2 = ~40000.1591 m
r2 – r1 = 40000.1591 – 40000 = +0.15915m

Conclusion

The distance is always about 16cm for an additional meter. This comes from the formula r = U / 2π. You can separate the constant from the variables: r2 = U1 / 2π + 1 / 2π. So the 16cm is actually parameter / 2π.

Math behind “Rope around the globe”

My PHP Rant

Writing a lot of PHP source code in the last years, I got more and more annoyed by PHP recently. I assumed it would be a good idea to sum up my thoughts and collect all the stuff that annoyed me while writing source code. I ended up writing an article about PHP called Why I dislike PHP and introduced the snippets section at my website.

Whoever is too lazy to read the whole article, just check out the linked code snippets. It might give you a feeling about my rationale. I’m happy for some feedback whoever has some experience with PHP.

Fun fact: I thought some of the examples—like list() in foreach—were pretty weird ideas by myself. But after writing the article and searching for discussions about PHP, I found discussions about these aspects by core developers.

Associated with this document, I have to announce that I want to discard most PHP projects I am currently working on. I am looking forward to developing with python in the web and I think this might work out (I might be interested in ruby on rails and node.js too; some day). As far as projects are concerned I am the only developer, I will mostly try to get the remaining source code running stable and reliable, but I am looking for a future without PHP.

My PHP Rant

Python wants to become one-based?

Yesterday (or today in my timezone) Guido wrote a reply, which indicated that he wants python to become one-based. I have written recently about my WTF-situation when I realized that SQL is one-based (and also Lua which comes up in the python’s mailing list discussion). Personally speaking I think that python is that damn intuitive because it’s based on mathematical principles (which Guido as mathematician is aware of). But math is not that consistent and beautiful that it solves all problems.

A sequence of numbers is a range of numbers from x to y with x included but y excluded. To get all indizes of a list, you can use range(0, len(seq)). This is damn readable and does not include a nasty -1 like in most other languages. Well… life is not that beautiful. If we change to a one-based numbering system, what will happen? range(1, len(seq)+1)? Seriously? Lua does not exclude y and therefore does not have a nasty +1.

Lists start with 0, because 0 is the firstzeroth number. In a decimal system, the firstzeroth number with two digits is 10. Three digits: 100. The least-significant number is always zero. The firstzeroth number with one digit is 1? This only comes from an exception in mathematics (102..0).

If I want to have all numbers in a list at 2*n indizes in python I will use …

>>> a = [1, 2, 3, 4, 5, 6, 7, 8, 9, 0]
>>> [a[2 * index] for index in xrange(0, len(a) / 2)]
[1, 3, 5, 7, 9]

Again: No nasty +1. Just like Wikipedia points out, it’s about congruence.

I understand that in certain situations it can be useful. If you want to get all numbers at 2n indizes, you probably want to have the mathematical base0=1 and you would be fine with one-based systems. You probably want to get the real firstzeroth number:

>>> import math
>>> a = [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]
>>> [a[2 ** index - 1] for index in xrange(0, int(math.log(len(a), 2)) + 1)]
[0, 1, 2, 13]

For Lua it just says:

a = {0, 1, 1, 2, 3, 5, 8, 13, 21, 34}
for index=1,math.log(#a+1, 2)+1 do
  print(a[2 ^ index])
end

I have shown only mathematical examples, but science is want I consider to be one of the most important fields for python. Other (especially old-school) languages really suck at this and it’s one of python’s strengths to be fine with scientists from other fields. In a mathematical context one-based systems it might be okay (see MATLAB), but for me a list starting with 1 is unpythonic and not useful. Yes, just like the Lua community I can live with a one-based languages, but I generally consider it to be a design fault.

Thanks to Bruce Leban for this awesome funny reply.

Update: Guido, you got me. It was a joke 😉

Python wants to become one-based?

How not to argue

Am 02.04.11, schrieb zensierter Name:

Ist aber extrem gefährliches Halbwissen das den Studierenden als richtig suggeriert wird, jedoch grundlegend falsch ist….. und damit hier eigentlich nichts verloren hat.

Danke, aber die Entscheidungen, was “hier” etwas verloren hat oder nicht treffen wir gerne selbst. Da es sich um eine *einführende* Lehrveranstaltung handelt (die für Anfänger aufgrund des Themas ohnehin schon mehr als komplex ist) ist hier eine sehr “naive” und grundlegende Herangehensweise durchaus angebracht, wobei auch hier in keinster Weise behauptet wurde, dass dies die “richtige” sei, sondern dass sie innerhalb unseres Gesamtkonzeptes akzeptabel ist.

via tu-graz Newsgroup

How not to argue