Thanks Nigel. Though I was going mad. Ny bit of styling doesn't seem to stick, only occasionally, but I can work around by setting it each time in Chrome Inspector.
An update on my styling hack. I was adding this into the themes styling which of course has no input on the back end dashboards.
Adding .wp-editor-container textarea.wp-editor-area { visibility: visible !important; } to a styling function does so I will post this to the forum you suggested.
We have a test package for the issue that we can try to install and see if it fixes the issue for you.
For that we will need the staging version of your website.
I'd appreciate it if you could give me the URL/User/Pass of your Staging WordPress dashboard after you make sure that you have a backup of your website.
Make sure you set the next reply as private.
Please do not provide the live website info as we need a website to be able to test stuff and that might break the website.
With all due respect I am not going to spend time setting up a staging site and all the time that it takes to do this with temporary admin accounts for Toolset. The reason for this is because I already reported where the issue lies and how to fix it. For some reason when using the Wysiwyg editor with the block editor there seems to be some conflict whereby the visibility of the html text are is none. Using the following css in a function will force its visibility:
It seems that this is a trivial enough issue for Toolset to fix. I find the tardiness in doing so irritating for a number of reasons.
For the last four or so year we are being told that we must start using the block editor. Fair enough but, while the block editor so far is fairly ok for inline content layout in many other areas it is sub-optimal and one of these areas is a consistency when it comes to responsive design. Before you say that Toolset has addressed this, yes it has and has made commendable efforts, along with other efforts from this parties such as Kadence to address something that should already be implemented in core.
Moving on, I refer you to the post published by Dario in June this year: https://toolset.com/2022/06/whats-next-for-toolset/
On reading, this does not inspire much confidence in the future of Toolset, which by the way is a very powerful piece of software. I recently re-subscribed for another year with Toolset but I note that there have been no plugin updates since May, even to address some of the small bugs like the one I mention above. This is really poor form.
While I appreciate that developing for the block editor has become a bit of a nightmare, that is no reason why ONTGS can't but focus on many other areas of the Toolset suite. Many of us still roll our own templates and views by hand with html, css and js. It's a bit condescending to direct those of us who have well honed skills in this area that we would be better off using blocks. Don't get me wrong block would be great if they really worked properly.
I would appreciate it if you would pass my feedback up the chain of command.
I do understand that you are not willing to create a staging website for a test. So for now I will inform you that a test package is available and after some additional testing a new version with the fix will be there for you to download.
We do not recommend to install the test package on a live website at the time being, that is why I will not share the package.
I will inform management about the feedback that you have mentioned.
A quick update to let you know that we have published Types 3.4.17 that includes a fix for this issue.
If the updates do not show up on your plugin installer page (click the registered link beneath the plugin name to go to the custom installer page) click the the Check for Updates button to update the list.
