We have updated Types this afternoon and it has caused this site to break (www.writing.ie). We can only have the site live with Types disabled...but the site relies massively on Types (and the entire Toolset Suite in fact). Can I have the previous version of the plug in to roll back as an emergency temporary solution? Then I will need support quickly to resolve the issue.
It's suggested to backup a website before you update any software, and to perform tests on a beta site, if the live site is cannot afford a downtime.
This is a suggestion for future updates.
For now, you can manually downgrade Toolset every time you need it, by getting the previous versions on the Toolset Downloads area
Under each plugins section for download there is a link to the changelogs and previous versions.
There you can get all available older versions.
But I suggest, to send us access and a site's copy if you could, and describe the error, so we can look at it and fix it eventually.
Important update on issue two only: the second issue I reported (with regard to CRED) has now been resolved by ourselves. It was a conflict with a piece of code in the theme. We corrected that, and all is now working well for this part of the issue.
Issue one (the first issue reported in this ticket) remains unresolved. Please login to the staging site asap to look at that (the Toolset Types issue).
Yes, you can update to version 2.3.1 on the staging site I gave you access to.
NOTE: I believe that the code conflict that I outlined above (which resolved the CRED/editor issue) may also have resolved the Types upgrade issue. I have no idea how, but I pulled a copy of the site down onto my local server and tried it out, and it worked fine.
Please go ahead and trying updating Types on the staging site and see if everything still works for you. If so, I can apply the change to the live site, too.
I have no idea what it was about that code - which has been on the site in functions.php unchanged for almost six years - which suddenly conflicted with the Toolset plugins.
If I upload the piece of code, could you take a look at it? I'm concerned that, unless we understand the cause of the issue, it could recur.
Okay, the code is just something we added in functions.php six years ago, and has had no issues until a couple of days ago when this happened. The code simply changes the display name of 'Posts' to 'Magazine Articles'. I don't know what has caused it suddenly to be an issue related to Types and Cred.
So first of all I will show the code as it was (which causes the site to break) until a few days ago:
// Change name of Posts Labels to Magazine Article
function change_post_menu_label() {
global $menu;
global $submenu;
$menu[5][0] = 'Magazine Articles';
$submenu['edit.php'][5][0] = 'All Magazine Articles';
$submenu['edit.php'][10][0] = 'Add Magazine Article';
echo '';
}
function change_post_object_label() {
global $wp_post_types;
$labels = &$wp_post_types['magazine']->labels;
$labels->name = 'Magazine Articles';
$labels->singular_name = 'Magazine Article';
$labels->add_new = 'Add New Magazine Article';
$labels->add_new_item = 'Add New Magazine Article ';
$labels->edit_item = 'Edit Magazine Article';
$labels->new_item = 'New Magazine Article';
$labels->view_item = 'View Magazine Article';
$labels->search_items = 'Search Magazine Articles';
$labels->not_found = 'No Magazine Articles found';
$labels->not_found_in_trash = 'No Magazine Articles found in Trash';
}
add_action( 'init', 'change_post_object_label' );
add_action( 'admin_menu', 'change_post_menu_label' );
The following is the new code I'm using, which does the same job but doesn't conflict with Types/Cred
// Function to change "posts" to "Magazine Articles" in the admin side menu
function change_post_menu_label() {
global $menu;
global $submenu;
$menu[5][0] = 'Magazine Articles';
$submenu['edit.php'][5][0] = 'All Magazine Articles';
$submenu['edit.php'][10][0] = 'Add New Magazine Article';
echo '';
}
add_action( 'admin_menu', 'change_post_menu_label' );
// Function to change post object labels to "news"
function change_post_object_label() {
global $wp_post_types;
$labels = &$wp_post_types['post']->labels;
$labels->name = 'Magazine Articles';
$labels->singular_name = 'Magazine Article';
$labels->add_new = 'Add Magazine Article';
$labels->add_new_item = 'Add Magazine Article';
$labels->edit_item = 'Edit Magazine Article';
$labels->new_item = 'Magazine Article';
$labels->view_item = 'View Magazine Article';
$labels->search_items = 'Search Magazine Articles';
$labels->not_found = 'No Magazine Articles found';
$labels->not_found_in_trash = 'No Magazine Articles found in Trash';
}
add_action( 'init', 'change_post_object_label' );
As I say, I can't see what about the old code causes the issue. If you can help, it may be good to get a complete understanding of why tings broke so badly this week.
With the old code: having CRED active stopped all editors and buttons in wp-admin working. Having Types active stopped any post types or fields from displaying anywhere on the front end at all.