The ipage server support checked that it was the theme causing it and reverted the theme back.
but a dummy post appeared on the homepage and I don’t know how to remove it as there are no posts yet on the site.
thanks
I just encountered the same issue with update 3.0.12
This is the error message I got:
Fatal error: Cannot redeclare class TC_footer_main in /home/content/32/11284132/html/RootDownDesign/wp-content/themes/customizr-child/class-footer-footer_main.php on line 15
I deleted all of the .php files I brought into my child theme and that let me back into my site.
Very confusing. I thought by creating a Child Theme, this allowed modifcations to the theme while still being able to receive updates. Am I wrong?
It allows you not to lose the changes you make.
But frankly speaking (don’t let the mods hear me saying this), I prefer to document very well the small individual changes I make and simply repeat them every upgrade. That way, I can see clearly if something has changed inside the code and adapt accordingly.
However, I repeat, the number of php changes that I have is small.
I do use a child theme for the CSS, because that cannot break my site. However, I go through it every now and again, comparing it with the color.css to see if my changes are still necessary/correct.
I’ve just discovered this WordPress page, which gives exceptionally clear detail on what has changed between releases: http://themes.trac.wordpress.org/changeset?old_path=/customizr/3.0.10&new_path=/customizr/3.0.12
Simply change the version number (exactly) in the URL and you can see the detailed differences to every file.
After the server support team restored the previous theme version there is an image post on my home page that I don’t know how to remove, it is not a post and it seems to be feeding itself from the Media directly. If I delete the image there it will take the next.
Where could it be coming from?
You need to disable all the files from the child theme except functions.php and style.css. By disabling I mean renaming (put “old_” before their names). Than re-enable them one by one and see which ones are causing erros. Compare them to their new versions and replicate your changes in parent version, saving the moded files in child theme folder.
In 3.0.12 a lot of structure changes were made, to both file templates and functions, because of the dev tools. Now almost all functions are filterable. You can alter their output without needing to know in what file they are.
Everything happens in your child theme’s functions.php and is 100% upgrade-safe.
Unfortunately now I am still using the 3.0.9 and am not willing to try the update again after the last time it screwed up everything. So the child theme files should be the same with the main theme I have.
The 13 update worked with the help of the server customer service so I will close this now. Hopefully future updates will not break my site again.
actually easy if you fail to update, I’ve been there on my website kyusoku bihaku , but with replaced file with the latest downloads from http://wordpress.org/latest.zip, everything just back to normal, this same technique to manually upgrade wordpress
You need to disable all the files from the child theme except functions.php and style.css. By disabling I mean renaming (put “old_” before their names).
Does that work for php files? Before I knew what I know now, I copied one of the php files in the parent theme and renamed it to …_copy.php while I played with the ….php. It brought my site down as WordPress/Customizr was trying to load both files and they conflicted with each other. It was only when I eliminated the copy that I could get the site back up.
Perhaps this is something that wouldn’t happen today because Nikeo has coded in the checking to see if a function is already loaded (and maybe he hadn’t at that point; v2.18, if I recall correctly).
