[Resolved] Text tab not working with Toolset Types 3.2.1

[Author]

Posts

[valterB]

After a recent update I have some problems, which I suspect could have something to do with Toolset.
1. Cannot change from Visual to Text Tab in the editor (only Visual tab is working).
2. Cannot edit content of a custom date field.

The reason I suspect this could have something to do with Toolset is that I have other WordPress sites with similar plugins (but not Toolset) where everything is working fine.
Also: when disabling Toolset Types the Text Tab in the editor works again.
Of course this means that many other things stops working because they need Types (for instance the custom date field)
How can I solve this problem?

Here is a list of the Toolset plugins installed:
Toolset Access 2.6
Toolset Advanced Export 1.0
Toolset Forms 2.2.1
Toolset Layouts 1.7
Toolset Maps 1.7
Toolset Module Manager 1.8.3
Toolset Types 3.2.1
Toolset Views 2.7.1

I am also using this:
Wordpress 4.9.8
Astra pro 1.6.7
Elementor 2.3.4
Elementor Pro 2.2.4
Ultimate Addon for Elementor 1.8.3

Best regards
Valter

hejaolika.se

[Nigel]

Hi Valter

This sounds like it is related to Types, but the problem isn't reported for Types in isolation, suggesting a conflict with one of your other plugins or theme.

Can you disable all plugins except Types and switch to twentyseventeen theme, then confirm that you do *not* see the problem.

Then use a process of elimination to re-activate the other plugins/theme, testing each time, to identify the source of the conflict.

Also, keep an eye on the browser console for JS errors.

Let me know what you find, so that I can try to reproduce.

[valterB]

Hi Nigel

thanks for your reply!

I was thinking maybe it would be possible to go back to an older version of Toolset to see if that would solve the problems?

Before, I tested disabling most of the plugins, the problem remained. I did not test absolutely everything though... I guess I need a clone of the site for this kind of testing but I don't have that at the moment.

Would it be possible to test using older versions of Toolset in this case?

Valter

[Nigel]

Hi Valter

The problem with reverting to an older version means that the issue won't get identified and so won't get fixed meaning you would be stuck being unable to upgrade.

Also, as there are no other reports of the same issue with the current Types version, it must be something specific to your set up. The most likely cause is a conflict, which is what needs testing.

If you only have the live site available and no staging site, I would point out that most hosts now offer staging, and if yours does not you should consider moving.

Which doesn't help right now.

I would use Duplicator (or All in One WP Migration, which is more user-friendly but has a size limit on the free version) to install a duplicate of your site on your local computer, where you can test without the risk of breaking anything on your live site.

If testing with only Types active and using the twentyseventeen theme you *still* see the issue, then that would suggest some corruption of the database settings, and to identify that we would need a copy of your site for testing (we could use the same duplicator or all-in-one backups).

Let me know what you are able to test and what you find.

[valterB]

Hi,
if I create av copy of the site, I won't have any problems using Toolset on both?
My license only covers one site I think.

Valter

[Nigel]

It simply means the copy on a second site will be unregistered, so that it won't be able to receive automatic updates, but will still function...

[valterB]

Hi Nigel,
I have been experimenting with All in One WP Migration to create clones of the site, using some different settings.
Interestingly the clone often (but not always) does not have the same problems as the original.
Could it be that exporting and importing with All in One WP Migration fixes problems?
(That would also mean that it is not a compabitility issue?)
Could that mean it would be more safe to use a clone that seems to be ok?
Would appreciate your advice on this!
Valter

[Nigel]

It could be that in the migration process some setting or option was lost that affects this, I have noticed the same from time to time, that migrating a site with All in One WP Migration can mysteriously fix something that using Duplicator to do the same doesn't, for example.

But then that is not something we can debug.

If we have a version of the site where the issue is confirmed in a predictable environment (ideally with just the required Toolset plugins active and nothing else, plus a standard WP theme such as twentyseventeen) then we can debug that to try and identify the issue.

If you duplicate your site and the issue magically goes away, you can count yourself lucky, but be prepared that it could happen again.

[valterB]

Is this a good plan:
First I change the doc root for hejaolika.se to the clone that seems to be working
Then I can use the "original" for testing, to see if problems go away when disabling other plugins.

Would you recommend doing this, or is this risky in any way?

[Nigel]

If you change the URL the server points to it can take time for these changes to propagate fully.

IMHO a better option would be, if you have a second version of the site that is working as intended, overwrite the live version of the site with this copy.

Either the live version of the site then works correctly, or if it does not, then that indicates that there is something specific to the production server causing the issue.

[valterB]

Now I have overwritten the live site with the "good" copy.
And the problems are still there on the live site.

What should I do next?

I need to do tests on the live site to find the problem?
But to do that I first need to change the doc root for live to clone?

[Nigel]

That points to a server-specific issue, though that's not conclusive.

Looking back over this thread we seem to have got side-tracked from checking for errors.

On the problem site, can you check your browser console for JS errors?

Also, check the PHP logs.

If you haven't already, turn on the debug log by editing your wp-config.php file and change the line with WP_DEBUG like so:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

That will create a debug.log file in your /wp-content/ directory which you can examine in any text editor. Try visiting the same page where you observe the problem and then inspect the log. If you don't find the debug.log file it means it didn't generate any warnings or errors.

If you quickly do that to see if it reveals anything useful. If not then you might need to point the URL to the working server while we try to pinpoint the issue.

[valterB]

Below is what Javascript consol says.
Also enclosed as a screen dump.

I changed WP_DEBUG as instructed, but could not find any debug.log in wp-content.

/Valter

Uncaught TypeError: $headers.imagesLoaded is not a function
at HTMLDocument.init (file-wp35.js?ver=0.1.2:14)
at i (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:2)
at Object.fireWith [as resolveWith] (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:2)
at Function.ready (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:2)
at HTMLDocument.K (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:2)
load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:77 Uncaught TypeError: Cannot read property 'bs_component_show_hide_button' of undefined
at QTags.i.getButton (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:77)
at ToolsetCommon.BootstrapCssComponentsQuickTags.self.add_bootstrap_components_buttons (toolset-bs-component-buttons.js?ver=4.9.9:122)
at toolset-bs-component-buttons.js?ver=4.9.9:21
at d (toolset-event-manager.min.js?ver=1.0:1)
at Object.j [as doAction] (toolset-event-manager.min.js?ver=1.0:1)
at HTMLDivElement.<anonymous> (toolset-bs-component-events.js?ver=1:213)
at Function.each (load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:2)
at toolset-bs-component-events.js?ver=1:209
at load-scripts.php?c=1&load[]=jquery-core,jquery-migrate,utils,jquery-ui-core,jquery-ui-widget,jquery-ui-mouse,jquery-ui-sortable,jquery-ui-draggable,jquery-u&load[]=i-tabs,quicktags,suggest,jquery-ui-position,wp-a11y,underscore,shortcode,backbone,wp-util,moxiejs,plupload&ver=4.9.9:96
onloadwff.js:79 Uncaught (in promise) TypeError: Cannot read property 'querySelectorAll' of null
at e.getInputs (onloadwff.js:79)
at e.<anonymous> (onloadwff.js:79)
at onloadwff.js:79
at Object.next (onloadwff.js:79)
at a (onloadwff.js:79)

[Nigel]

Is your WordPress version the same on installations that work vs where they do not?

Can I get a copy of the All in One WP Migration backup archive to test install myself?

You can share a link to dropbox or similar here, it won't be visible to anyone else.

[valterB]

It is WordPress 4.9.9 for both.

I uploaded a copy to Dropbox.
It is taken from heja4.tjanstehotellet.se but I used All In One WP Migration to search/replace url:s to hejalive.hejaolika.se

Link to dropbox (the file is almost 4 GB)
hidden link