Cheatin uh?

This is happening because your theme was built in an … incorrect manner. It’s what we call doing_it_wrong()…

A lot of people on this thread are blaming WordPress for theme breakage, and a number of people have already pointed out that the problem is with incorrectly coded themes. I agree with that sentiment. I haven’t seen much discussion of what makes ‘incorrect’ code, what makes ‘correct’ code, or why one is correct and the other isn’t. I know I wouldn’t take anyone seriously unless those questions were answered, so here it goes.

So what is doing_it_right()? For a project like WordPress to work, with its plugin and theming systems, and to prevent things from breaking release after release after release, the people writing code for WordPress themes and plugins have to follow a set of rules. Basically (my summary, not canonical), use core functions to manipulate core information– posts, user data, etc–, use hooks and filters, avoid deprecated functions, and avoid directly querying the databases. (Those who remember the old category structure can understand how badly that can go wrong.) The short version is “Read the Codex”. Sure, WordPress is open source and you can do anything you want, really. That is why I use and that is why I love it. But if, say, the database structure changes the developers can alter the core functions to compensate and things don’t break. The developers cannot predict or compensate for the practically infinite number of hacks that are possible. If you use these hacks, or a theme or plugin that does, it isn’t WordPress’ fault.

Finally, if your business relies on your website, and you’re not testing before you upgrade, you need to realize that the onus of your website is on you, and no one else. Test first. Always.

Absolutely!!! You can build an adequate development LAMP server for $500. You don’t need anything fancy, just cheap hardware and Linux install disk– Debian and Centos have very nice package management.

I never install anything live without running it on a development server, with a disposable database. I’ve been building and maintaining WordPress sites since 2.-something and I have never had this kind of failure on a live site.

I know the built in updater makes it easy to just push a button and update live, but don’t use it. I’m not sure why that was included in core but I imagine it was to encourage people to keep their sites up to date and hence keep them more secure, and it was probably motivated by requests for easier updating. Don’t use it. It is dangerous, as many of you have figured out.

Lot of people here going back and forth but no one presenting any real hints at what a legitimate fix might be. Since this seems to be in nearly every case occurring in a themes dashboard for uploading a logo (or what have you) there has got to be a pretty common thread as to what the fix might be.

Does anyone have any lines on how other devs are fixing this problem in their themes so we can connect some dots and maybe offer a direction for people who’s devs aren’t so responsive?

Thanks!

Does anyone have any lines on how other devs are fixing this problem in their themes so we can connect some dots and maybe offer a direction for people who’s devs aren’t so responsive?

There is a link several posts back to a page that supposedly shows how Elegant Themes fixed this, but that page requires that you login to view it.

I am using elegant themes Whos Who v3.2 and wordpress v3.4 and have same problem when uploading file in post editor..

anybody help me, please….

i was having this problem over the weekend, using headway theme v3.05, after i updated to the new wordpress release 3.4.

last night headway released a fix, which was automatically pushed through to my site dashboard – v3.2, and now the image upload function is working fine.

so, as the mods here have suggested, it seems pretty clear it’s a theme issue that each individual theme will have to resolve. shitty, i know, if you’re running multiple themes over different sites, but there you have it…

On my particular theme from Themezilla, the new code for the upload button looks like this:

jQuery(document).ready(function() {

jQuery(‘#tz_portfolio_upload_images’).click(function() {

var tbURL = jQuery(‘#add_image’).attr(‘href’);

if(typeof tbURL === ‘undefined’) {
tbURL = jQuery(‘#content-add_media’).attr(‘href’);
}

tb_show(”, tbURL);
return false;

});

jQuery(‘#tz_background_image_button’).click(function() {

window.send_to_editor = function(html)

{
imgurl = jQuery(‘img’,html).attr(‘src’);
jQuery(‘#tz_background_image’).val(imgurl);
tb_remove();
}

tb_show(”, ‘media-upload.php?post_id=0&type=image&TB_iframe=true’);
return false;

});

});

I run over a dozen sites out of which seven are using WordPress as CMS. I use different themes, including two commercial themes and the rest FREE themes downloaded from WP repository. I upgraded to 3.4 and I faced none of the problems members find here.

Above all, I could also help several members facing various issues after upgrading to 3.4. In my case I followed the correct methods, and in the case of others I helped solving problems, mostly they were related to outdated themes, badly coded themes, and in a large number of cases most of the complaints were related to simple and silly mistakes that could have been avoided. This happened in the case of themes as well as plugins. So, I feel that it is better to list down the correct procedures for updating and carefully doing the work.

Yet another thing that has to be noted is that if you encounter a simple problem, in trying to fix the problems, you commit more mistakes compounding the problem.

I am emphasizing this, because I committed a silly mistake during the last update, and one of my sites was down for almost one month. I took up the problem with my host that simply emailed me a QUICK fix that they drafted years ago. I took up several complaint tickets, talked to them on phone, but to no avail. My second mistake in that case was I just believed what the support staff of my host said, and kept on working on those lines.

Finally, I started trying many things on my local server and fixed everything myself and re-uploaded the site.

What I try to stress is that problems can arise from many sources. We may not be identify them first. But when I identified my problem, it WAS NOT a WordPress problem as my host suggested (one of them, I use three hosting accounts), but the first mistake was committed by me, followed by wrong and misleading advice by host.

Now I feel that was a VERY GOOD thing that happened to me because, I learned more, and the chances of committing mistakes is much less now.

I’m closing this, not because it’s resolved, but because there are too many people shouting for any one voice to be heard ??

There are multiple possibilities for a deceptively simple error :/

Everyone who is having an issue, please make your own topic. I know it looks like you have the same problem, but it’s unlikely that it’s 100% the same. In your topic, reiterate what your, specific, issue is. What did you do to get it, what have you tried to fix it. Do not say ‘I tried everything.’ Just list what you tried. Trust me, it’ll help ??

So what is doing_it_right()? For a project like WordPress to work, with its plugin and theming systems, and to prevent things from breaking release after release after release, the people writing code for WordPress themes and plugins have to follow a set of rules.

We have a whole blog where people talk about that, plus a mailing list.

https://wpdevel.wordpress.com/
https://lists.automattic.com/mailman/listinfo/wp-hackers

Major changes are mentioned and discussed, usually months in advance. It’s very rare than a change this big would go un-announced.

Also remember – WP only monitors themes that are hosted here. A lot of people buy themes from other sites, and those are never scanned or updated. When a major change happens, a search is run to see how many themes will be impacted, and those devs are told what’s up. Every theme update is reviewed, too, so it’s a little harder for themes hosted here to be impacted.

As for plugins, they’re not monitored the same way for myriad reasons, and it’s much easier for a doing_it_wrong() to slip in. Still, impacts are checked for, and if it’s large, deprecate (versus remove). If it’s small, then the devs will be contacted directly.