I am trying to add CSS classes to cells in Toolset Layouts grid and they're not being saved. When I save and close, then reopen the grid cell editor, the class appears to have been saved. However, when I refresh the page (either directly or by going elsewhere in wp-admin) and return to that particular layout editor, the CSS classes have disappeared.
Each time this happens, the following two warning lines are produced:
Warning: explode() expects parameter 2 to be string, array given in /home/content/a2pnexwpnas01_data03/41/3614741/html/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 267
Warning: Invalid argument supplied for foreach() in /home/content/a2pnexwpnas01_data03/41/3614741/html/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 268
Please see screenshots for examples. The debug information has been provided for this support request but please let me know any additional information you would need for resolution. Thank you!
NOTE: I've already disabled all other plugins, except Toolset Types, Views & Layouts. We're using a child theme of Toolset Starter, but switching to Twenty Sixteen (with all but those 3 plugins disabled) produces the same issue.
This is urgent, we're quite frustrated, our client project has already been delayed due to the issue here: https://toolset.com/forums/topic/css-not-working/page/2/ which was supposedly resolved. We're experiencing essentially the same problem as in that thread, but with different errors/warnings and I cannot confidently recommend Toolset Layouts at this point. Thanks in advance for your assistance!
I did some further tests and initially thought I could reproduce the problem, but then realised I wasn't entering additional classes as intended, i.e. it was a usability problem rather than a bug.
When you enter an additional class, if you adding a single class name and then hit save or save and close straight away the added class is not saved (see screenshot class-not-added.png).
You need to hit enter (or space) to add the class before saving (see screenshot class-added.png).
A small thing but it tripped me up when I re-tested.
If that doesn't account for your problem then let me know and I will come back to you for credentials to take a copy of your site as I can't reproduce the problem on my own test site.
I am actually experiencing this identical issue right now, using the latest version of Layouts as well a Toolset Starter Child Theme (based on the one from wp-types) with the Select2 fix from Errata applied. Perhaps I can provide some more details as I've been developing themes using Layouts for quite some time now and this is not typical of Layouts in previous versions.
The classes are indeed being added correctly, to a Grid of Cells in my case, and absolutely appears to save correctly. Based on your screenshots, this is the same procedure being followed (and one I have done more times than I can remember).
However:
1) Upon loading a page using this layout, I am presented with the following error:
"Notice: Array to string conversion in /home/XXXX/public_html/XXXX/XXXX/wp-content/plugins/layouts/classes/wpddl.layout-render.class.php on line 285" (I have debug on for development purposes)
2) After setting the class on an element, any other elements you try to edit shows the container type and the class set for the previous element in the edit popup.
3) If you close the Layout editor and attempt to re-open it, you are presented with 4 specific errors and the just added class is missing from the element's edit popup:
Warning: explode() expects parameter 2 to be string, array given in /home/XXXX/public_html/XXXX/XXXX/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 267
Warning: Invalid argument supplied for foreach() in /home/XXXX/public_html/XXXX/XXXX/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 268
Warning: explode() expects parameter 2 to be string, array given in /home/XXXX/public_html/XXXX/XXXX/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 267
Warning: Invalid argument supplied for foreach() in /home/XXXX/public_html/XXXX/XXXX/wp-content/plugins/layouts/inc/gui/CSS/wpddl.css-js-editor.class.php on line 268
Thanks in advance for any support you can provide and I hope has provided some insight into the issues the OP and myself are both experiencing.
Notable debugging update:
After a class is added to a Grid's edit popup, when hitting the 'Save and Close' button for that element, the following error is received in the browser console:
The toolset_select2('destroy') method was called on an element that is not using Select2.
select2.js?ver=4.0.3:5679 The toolset_select2('destroy') method was called on an element that is not using Select2.
I will note that this occurs both with Select2 errata fix applied as well as without it being applied.
Also, to the Mod, Nigel, I notice you're using a Visual Editor element to test this issue - visible errors do not occur on Visual Editor elements, (however the class is lost when the layout editor is reloaded/refreshed after saving). Both the OP and myself are having this issue with the "Grid" or "Grid of Cells" element as it's also known.
I have re-tested this with the Grid of Cells layout cell—thank you for pointing that out Brian—and, yes, I can see and reproduce the problem.
I am getting the PHP warnings, the JS error in the browser console, and I note inspecting the markup in the browser that where I was adding a custom class a class of "Array" has been output.
I am re-opening the internal ticket for this so that it can be worked on further.
Sorry for the continuing problems with this issue. I will let you know when there is anything to report.
I'm glad I was able to assist you, Nigel.
Thank you for your prompt reply and continued support regarding this issue, I can't say enough about the Toolset framework and your entire team's dedication to the Toolset project.
Looking forward to a resolution to this issue, thanks again in advance.
Bravo, Brian! Thank you for being more thorough than I was in debugging.
Nigel (and future Toolset user/readers) — apologies for my statement about not recommending Layouts. Toolset support team has always been very responsive and I'm confident this issue will be resolved in time. I should not have ended my support request on a sour note. The Toolset suite is such an impressive kit, thanks for all you do!
I can corroborate Brian's report of this console error in the Edit Layout page:
The toolset_select2('destroy') method was called on an element that is not using Select2.
But I have not yet encountered the console error of "Notice: Array to string conversion...." when loading a page that uses the buggy layout.
Switching to FirefoxDeveloperEdition I did find this guy in this console, but it applies to load-scripts.php and may not be applicable here?
Use of Mutation Events is deprecated. Use MutationObserver instead. load-scripts.php:3:9644
Regardless, thanks for escalating, Nigel if I can help in any way or if you need login credentials to test with, please let me know. Very much looking forward to the resolution for this. Thanks again 🙂
We recently pushed out an update to Layouts 1.8.8 and I have just been testing it to check that the issue saving custom classes with grid cells is fixed, and it does appear to be in my testing.
Please update to the latest Layouts version and re-test, and if you have any more issues, please report back.
We have been using Layouts 1.8.8 since November 4th but are indeed still are having this issue on grid cells.
Saving a class, reloading the editor and going back to edit that class results in the following warning:
Element.js:158 Uncaught TypeError: this.attributes[attribute].replace is not a function
at n.get (<em><u>hidden link</u></em>)
at DDLayout.ContainerDialog.self.show (<em><u>hidden link</u></em>)
at DDLayout.AdminPage.self.show_container_dialog (<em><u>hidden link</u></em>)
at HTMLElement.<anonymous> (<em><u>hidden link</u></em>)
at HTMLElement.dispatch (<em><u>hidden link</u></em>)
at HTMLElement.r.handle (<em><u>hidden link</u></em> @ Element.js:158self.show @ container-edit-dialog.js:58self.show_container_dialog @ main.js:551(anonymous function) @ ContainerView.js:246dispatch @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,underscore,backbone,jquery-ui-core,jquery-ui…:3r.handle @ load-scripts.php?c=0&load[]=jquery-core,jquery-migrate,underscore,backbone,jquery-ui-core,jquery-ui…:3
When viewing the page with that layout assigned, viewing the source displays "col-sm-2 Array" as the class that was saved.
I was seeing what you describe prior to the Layouts 1.8.8 update (on the front end seeing "Array" as a class) but that has been fixed in my testing.
Sorry for the inconvenience, but could you start a new thread with the issue so that if need be I can get credentials from you etc. and try and identify what is particular to your installation.
(Below has been edited since original posting time:)
Hi Nigel!
Well, after some testing and duplicating, I finally got the classes to "stick" and the errors to stop showing, however reloading these fields to edit the fields is inconsistent and often results in the loss of items, similar to the issue explained in the Select2 errata fix that AnnaB referenced in the original post above.
Initally, it took a few re-saves of the existing layouts and I lost the existing classes on all other types of cells at one point, but since that point it has been mostly responding as expected with the class appearing in the grid cell's column classes in the front end output.
I have however noticed that adding a grid cell, then clicking the edit button to add a class works, then adding another grid and doing the same works, yet once the layout editor page is refreshed or reloaded, clicking the edit button sometimes shows the previously added classes quickly dissappear from the classes field, most typically after editing these repeatedly without reloading the editor page.
I will create a ticket for you once I have the time to provide a debugging environment for you. In the mean time, I will add custom CSS media rules in the Layouts CSS/JS or my child theme rather than using standard bootstrap column classes to modify the responsiveness of the columns in our Toolset layouts.
Thanks,
Cameron
This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.
