Today I tried to import some content from another wordpress installation to mine. First off – I imported the XML file into my staging DB, and it all went well. Then I went on and tried to import it on the live server. At hitting the button – the page reloads for a while, and then – nothing.
I tried it a couple of times with no avail.
First thing – I have verified that the file is smaller than the max file size limit set on the server. It was.
So I went ahead to seek help from Mr. Google, but all I came up with was a load of rants and rackets about the WordPress Importer plugin. That meant I need to roll up my sleeves and get my hands dirty with raw plugin code…
Making a long story short – it all comes down to this line:
$dom = new DOMDocument;
within the WXR_Parser_SimpleXML class, in a file named parser.php of the importer plugin. And at that – the plugin cannot be blamed. Thing is – when calling the DOMDocument class, if it is not installed on the server , it will return nothing. Nesting this call inside a try and catch will not do either. This might be an issue with WordPress, and maybe turning on debug mode can help, I admit I haven’t checked it.
So only thing left is indeed to check if the libxml and the domdocument extensions are indeed installed with the server. They are probably not, so setting them with the server is most likely to solve the problem.
So having gone through the Blog tutorial and the Simple authentication tutoiral, I have come across my first rode bump: a really ugly exception:
PHP Fatal error: Class 'AppController' not found in /var/www/lib/Cake/Controller/CakeErrorController.php on line ...
At that I was completely lost. So I went for help from Mr. Google.
The first search result I have stumbled upon was in Italian, but I would never let such a trifle to stop me. I realized there may be a way to drill further down this error, if I set right my error handling level with the debugger: add (modify) this line in your app/config/core.php:
Unfortunately this line is already set in there.
So I went on for the second result. There I have found out that PHP5.4 would allow this syntax:
$this->Auth->user()['role'] while in older version you would rather use:
$user = $this->Auth->user()
$role = $user['role'];
I am not syaing this piece of info was completely irrelevant. It was in fact, indirectly. Because it taught me 2 things:
- Cake is looking for the error controller to alert about a problem, and at not finding it – would alert about the missing error handler. Instead of alerting about the actual probelm, it would whine about it’s issues with the error handling.
- Good to know you can use this syntax in new versions of PHP!
Off-course at this stage I am still at a loss about the issue that had caused all this in the first place. So I go for the 3rd, 4th … results, and I come across this very helpful link by Oxford Rob (from whom I have also borrowed the quotation) with some very usefull lead: It is all in the appcontroller.php file. Here’s where we start to debug.
So first stage is to set a new fresh copy of this file, instaed of the one we’re having – at doing that – the application is loading correctly. With that I get a couple of more civilized error messages that I am going to take care of later on.
So now I am going to add back gradually everything that was in the appcontroller so I am able to tell where exactly everything should fall apart. And here it is:
public $components = array('DebugKit.Toolbar');
What is this DebugKit.toolbar – I really know nothing of. But at least I am able to go on and try to look it up. I am now left with two unsolved issues:
- The error handler issue is still not solved.
- I am left with a more civilized error message:
Error: The application is trying to load a file from the DebugKit plugin on my application’s main page. So that’s probably the next thing I need to try and fix.
What happens when we click Upgrade Now?
- WordPress creates automatically a file named .maintenance
- All these files might be overriden:
- All the files under /wp-includes/
- All the files under /wp-admin/
- Any wordpress’ original theme folder (Twentyten, Twentyeleven etc..) under wp_content/
- All files directly under wordpress’ root
- A couple of files/folders may be added to wp_content/
- On the database, The “db_upgraded” flag on the wp_options table is set to “0″
- If all went well, WordPress deletes automatically the .maintenance file
Once done, the right db and system versions are recorded on the wp_config.php file:
* The WordPress version string
* @global string $wp_version
$wp_version = '3.1.3';
* Holds the WordPress DB revision, increments when changes are made to the WordPress DB schema.
* @global int $wp_db_version
$wp_db_version = 17516;
If anything goes wrong – here’s an interesting article with some suggestions for troubleshooting.
Paul Simon listed 50 ways to leave your lover. I am about to list at least 50 ways for Magento to give you a heart attack. The most recent one resulted in an urgent text message from my client: He added a new category – and – magic! Next thing he knows: the home page is empty.
I have already written about troubleshooting products not displayed in Magento’s front. However this case is a bit different: while there – the products where never displayed on the site – neither on new products page nor on category’s page, here – right at creation, they were displayed as expected. However, for some mysterious reason, they suddenly disapeared!
So I run again for help from Mr.Google. Go through the check list again. Here’s something I haven’t tried yet: re-indexing.
System => Manage Indices. All items are green as in ‘updated’. I decide to give them a shake anyway: I hit select all, then selected Reindex Data on the actions menu, then hit Submit. Tada! More magic! The products are back!
Here’s also a detailed explanation of what may cause this behavior and how to ‘ghostbust’ it
Last night, after a very hectic day, one notch before a new installation on a clean hard disc, I just realized that there’s one option I hadn’t try yet: KDE.
KDE was never my favorite, but logging in there after all I’ve been through, was really refreshing. Great colors, everything works, this is a nice sanctuary to stay in until the war’s over
But this morning, at booting the system, I didn’t even get to the login screen. The system halted at it’s last check before starting X and there it rested, or, as it is referred to in most Google results – ‘The system hangs at battery check’
As it turned out: Up until now – Ubuntu used the gdm display manager. As of now – it was changed to the new lightdm manager, which apparently is not quite baked yet. According to the major part of complaints all over the Internet – it mainly lacks support for Nvidia drivers, even the most recent. Ubuntu’s new window manager – Unity, is based on this display manager. It exists in two main versions: 3d (which comes as a default) and 2d (which is not installed by default but can be added). A fresh installation also makes it available to login on ‘gnome classic’ – compared to the new ‘gnome-3′ – (Not installed by default either, and can be added).
So seems my hardware (a reasonably new Nvidia GeForce 9600) is not supported by lightdm (and any window manager based on it, such as gnome-3 and Unity 2d or 3d), and as classic gnome is also set to work over lightdm – it would not work properly either.
This situation starts to look like a spaghetti dish, and it seems that nowhere I go – there’s a dead end. Trying to sort it out as much as I can, I realize I have now two missions: First – getting to a functional log-in screen. Having that achieved – logging in to a functional desktop – at the moment being only KDE.
So at the moment I’m on phase 1 – being hanged at ‘battery check ok’
- I you run into any graphic related problem, better start with having both gdm and lightdm installed on your system.
- Log into a none-graphic terminal by hitting ctrl-alt-fN (when N is any number between 1-6) and logging in to a prompt line
sudo apt-get update
(enter superuser password)
- Install gdm: At the prompt, type
sudo apt-get install gdm
- Install lightdm: At the prompt type
sudo apt-get install lightdm
- Install lightdm login part manager: At the prompt type
sudo apt-get install lightdm-gtk-greeter
- Selecting which display manager should be on is done by typing at the promtp:
dpkg-configure gdm to set up gdm, or
dpkg-configure lightdm At any rate you will get a menu where you can select the proper manager hitting the arrow-up or arrow-down keys. This is a matter of try and error. Try first loghtdm, and then reboot your systme hitting:
sudo shutdown -r now At least one of them should work.
- At boot – please take some time to wait – the ‘battery check screen’ may hang there for awhile. Give it a couple of minutes (time to grab a sandwich or a have a quick channel-zapping round on the tv), before you give up and start anew. At least one way or another should work for you.
- Having achieved the login screen again – make sure you log in to kde – and you should be good to go.
- Now all left is to sit and wait until all is quiet at the Gnome/Unity front, and all refuges may return home.
It all started a couple of days ago, when I posted this on Ubuntuforum bulletin boards: