JeremyVisser

Dumb question, but why are you disabling jQuery? jQuery is used at the core of nearly all JavaScript in WordPress.

It’s like removing the fuel tank from your car to make it lighter.

I’m sorry, I may have misinterpreted you. I assumed you were getting a blank screen.

display: none; in CSS is for hiding elements. If you get rid of that, it should make it show…assuming that is what the problem is, of course.

It is most likely caused either by a PHP syntax error, or a function causing a fatal error. The code you posted does not contain anything likely to cause that, so that’s barking up the wrong tree.

The way I’d go about getting to the bottom of this is enabling WP_DEBUG in your wp-config.php.

If that doesn’t get you the output you need, try also adding ini_set('display_errors','On'); to your wp-config.php.

Let us know how you go.

As dd32 says, you can delete the update_core option, rather than editing the data inside it.

Deleting the entry is probably a safer option, as editing serialised data can have potentially catastrophic consequences — one typo can cause PHP to consume gigantic amounts of memory and CPU, and may cause your account to be suspended, if you are on shared hosting.

Indeed, I’m also getting #3 on my site when trying to use the plugin as an OpenID provider.

I’m very interested in getting this fixed — anything you need from us to help?

I am a complete CakePHP n00b, but I’ll try and reply to you as best I can.

First, what you need is shared authentication. You either need to modify WordPress to get its username and password data from CakePHP’s tables, or modify your Cake app to gets its username/password data from WordPress.

Both should be doable. I know WordPress has a file called wp-includes/pluggable.php. All the functions in there can be replaced by a plugin. Some of the functions in pluggable.php are related to logging in, so you could possibly hack WordPress to fetch its user data from your Cake tables that way.

Once you have the user tables shared, you still have the issue of needing to log in twice. Making the user logged in to WordPress should be as simple as setting the right cookies with the right password hashes inside them.

After logging into my WordPress site, I have four cookies:

• wordpress_
• wordpress_
• wordpress_logged_in_
• wordpress_test_cookie

I am not sure why they have underscores after them — perhaps it is because I am running WordPress MU.

Anyway, the content of the first three cookies looks something like this:

yourusername%somerandomdata

So, basically, it has the username, and what is most likely a salted hash of the password.

I don’t know how to calculate that hash, but once you manage to do it, setting the cookie from within your CakePHP application should be as simple as calling the setcookie function.

I’m not sure if CakePHP has a “proper” way of setting cookies, and even if it does, it would probably not allow you to set the cookies with the right names to suit WordPress.

Once the cookies are set, you should be correctly logged in to WordPress.

If anybody here knows any better how WordPress’ login cookies are set, your feedback is most welcome.

Neohunter, I hope I have been a help, and if not, please let me know why. ??

I would say it’s because you uploaded (or upgraded) WordPress or your theme via FTP while using the ASCII option.

This means it uploads everything, including images, in ASCII. Images are supposed to be in binary format, which means when you upload them as ASCII, they get corrupted.

I suggest trying to re-upload your theme in binary mode (it should be an option on your FTP client), and seeing how you go.

@hulk, seems like your site is being cracked.

Hi Jessica,

Thankyou very much for reporting this issue. I am one of the admins on the Install4Free site.

I have never seen this bug happen before, so thanks for letting me know about it. I couldn’t have fixed a bug if I didn’t know it existed. ??

I’ll get to your ticket, claim it, and start your installation later today.

Cheers,
Jeremy.

All that’s happened is that when your host fixed the problem preventing WordPress from working, WordPress magically started working, and somebody else (a loyal fan?) ran the setup wizard for you.

I’m just going to reset the MySQL database so we can run the setup wizard again, and it’ll be fine.

I wouldn’t exactly call it “hijacked”. ??

It’s not a quirk of PHP. It’s actually the way pretty much all programming languages (at least all the important ones — LOLCODE doesn’t count) work.

Once you learn that logic, you can apply it to whatever programming language you choose later on.

Don’t worry, I have dreams about PHP, and I get confused around those sorts of things too. Happens to everyone.

I had a similar problem with a Plesk-based IIS installation that was running PHP.

Switching PHP to load as an ISAPI extension instead of via CGI fixed the problem.

Really strange. I’m thinking that you should change theme to one that uses more ethical practices and is more hackable.

And you’re sure you’re putting that code in footer.php?