MKSnMKS

Hi Jan Dembowski (@jdembowski),
Thank you for your reply.
Re

As you are aware the original poster can always mark their topic as resolved or not resolved.

Your first premise, though flattering by assuming possession of awareness is inaccurate. This is because as has been explained, there is no such function presenting itself for this user to actually be aware of. What this user is aware of experiencing, is that lack of it.
So for the purposes of diagnosing the problem, Andrew Nevins
proposition of it being a bug sounds reasonably practical and probable.

Apart from whether it is a bug or not,
from a user friendly experience, there is no additional hint, prompt, notice to even suggest that such functions are available. Having any of these would improve the useability.

You have made additional comments, which are addressed below;

a)

Why? Some people (well, lots of them really) post a topic and get a solution and never reply. It is prudent to permit the plugin author to mark topic resolved for that reason.

In answer to you question “Why”.
This is quite correct. It is not clear why you have raised this, as nothing in what I have said, or intended, was to prevent the plugin author from acting this way.
So just to clarify, in order to avoid future confusion.
The suggestion made (whether or not presently available, or functional, or bug free), is that “the thread/topic author can have some input into the decision process.”

b)

Plugin and theme authors are like mini-moderators for their own support sub-forum on www.ads-software.com.

Thank you for confirming this.
This is exactly why the following suggestion was made;

3) Topic Author may contest the “resolved” setting, first with the Plugin Author, and lastly with some arbitrator/admin at WordPress.

The reason being is that it is respectful of the plugin author, and establishes sensible channels of addressing an issue and redress.

c1)

These are volunteer support forums and the “volunteer” part is important. There’s no such thing as contesting a topic here, users are not customers and that’s not the model here.

Quite correct also.
There are many many volunteers, and that includes the users of the plugins that contribute to these forums, and come up with ideas for improvements, and help test and debug. It’s all part of the huge community. (and some might observe how this is incrementally influencing the world).

c2) You have made two particular statements ;

There’s no such thing as contesting a topic here.

As you are aware the original poster can always mark their topic as resolved or not resolved.

You can contest it by un-resolving it and replying.

Is there some difference between “the original poster” be able to “mark their topis as … not resolved”, and “contesting a topic”?
If there is a difference, then would it not be sensible to have a process of sorting out the differences?
Please can you clarify what you understand the situation “to be” and what you intend the situation “to be in future”.

d1)

If an author replies or not then either case is fine. That includes if the author chooses to resolve a topic or not. You can contest it by un-resolving it and replying. If you feel so inclined you can also leave a review in that plugin or theme’s review section.

This again is quite correct.
The plugin author, and the topic/thread author are both under no obligation to reply.
But just to be clear, there has been no suggestion made that either of them “should” reply.
But since you mention it, several people might consider it rude, for a plugin author to mark an issue as resolved, without even making a simple comment. But that is not a point I am intending to raise, as just about everybody is willing to engage in dialogue, and it goes without saying.

d2) Thank you for suggesting the option of “leaving a review”, which is an option that most user are made well aware of.
One of the reasons why the options that have been suggested above were made was that a review is much more permanent, even though it may have been relevant at an earlier point in time.
The above suggestions were made so the plugin author has more opportunity to respond to issues that any user considers important, even though the plugin author may have initially under estimated the importance (sometimes based on false assumptions). With this flexibility in communication, there is much less chance of issues “going amiss” or un-noticed.
The aim is to avoid a more permanent negative portrayal of a plugin by recourse to “leaving a (negative) review”.
And of course, there may be other avenues for improving dialogue, feedback, suggestions, complaints, user surveys, participation, etc, but these may only come with time, and further discussion as to the possibilities.

In summation
Thank you for your elucidation.

As of yet, I still am not experiencing a way to mark this topic as “Un-Resolved”, so it remains entirely in the hands of the support crew (this is not a plugin suggestion), to mark this topic as un-resolved, because I can not, and you have been informed that I can not.

Nobody has yet explained where the option(s) are actually accessible for the topic author to un-resolve the topic. It might be expectable that it be in menu on the right hand side of the topic display, and/or next to the submit button, and/or able to be activated by the green “resolved” rectangle, or other (multiple) methods. So far there has been no illumination.

Thank you

Hi Andrew Nevins (@anevins),

Possibly it is a bug.
Where is the way to change the “Resolved” setting, (so I can check if it works)?

Intuitively, it might be expected that the “Resolved” green rectangle would be the place to go, but it doesn’t work, nad there is no obvious menu link.

Observed behaviour
Hovering over the “Resolved” green rectangle does not indicate a link.
Hovering over the “Resolved” green rectangle changes the cursor from an arrow to “insertion” (as in text edit) mode.

Are you saying that it is already compatible “with” PHP7, or “up to but not including” PHP7 ?

PHP 7 provides noticeable speed increases for WordPress, and plugins that are PHP 7 compatible will carry sites on to better performance.

Thanks

Thank you for the work around.

In the coding sense, the functionality is almost there.
The “turn option on/off” function is present,
but it is presently not sensitive to back/front end user.

So you may interpret the above suggestion as;
It would be helpful to have this very option available to control the front and back ends independently.

Just a little more work on the coding, and saves a little extra time and effort (problem solving) for “all” the users.

Thank You

JamesBates (@jamesbates)
WebHunt Infotech (@webhuntinfotech)

A word of caution for deliberation

;

The link at
https://www.ads-software.com/support/topic/visual-editor-not-working-in-wordpress-46-on-my-laptop/page/5/
says ;

”

Open wp-config.php on your computer.
Search for:
define('DISALLOW_FILE_EDIT', true);
and change it to false.

”

It also talks about security risks.

I have iThemes Security installed, but presently de-activated after having had it activated many months ago.
It has left the following code in the wp-config.php file ;

”

// BEGIN iThemes Security - Do not modify or remove this line
// iThemes Security Config Details: 2
define( 'DISALLOW_FILE_EDIT', true ); // Disable File Editor - Security > Settings > WordPress Tweaks > File Editor
// END iThemes Security - Do not modify or remove this line

”

So it looks like iThemes Security was used to make the change which has caused the problem with the visual editor. But this change was made by iThemes Security to help avoid the security problem that is mentioned in the link above.
The permanent security risk is the price that is paid for the ability to use Visual Editor without needing to make any adjustments prior to editing.

This “may“ be regarded as a “solution” to the visual editor problem.
But then it opens up the security risk as another problem.

There is no way that in order to use the visual editor, that it should be acceptable to also let the plugins and other features be edited.

If any security risk is to be tolerated then ;
What is needed, is the ability to reduce the security risk to only being present when the Visual Editor is needed. And that is if such a security risk is to be tolerated at all.
That is why I will prefer the work around of de-activating the Page Builder plugin.

Try using the “Plugin Toggle’ plugin which makes this very easy.
https://www.ads-software.com/plugins/plugin-toggle/

Solution

What is needed, is to be able to do the switching automatically at the time the Visual Editor is used.
The switching can be either or both of
a) the ‘DISALLOW_FILE_EDIT’ setting in wp-config.php , or
b) the page builder plugin.
The switching can be done either by WordPress or the Visual Editor.

The user can be given the choice as to which method they would prefer.
They can therefore choose which compromise they would prefer during their visual editing session ;
a) reduced security
or
b) temporary loss of pagebuilder functions on the web site front end.

In the meantime

,
if the method of de-activating the Page Builder is found to work in use,
then it does not require any additional risk to security to use the visual editor.

Hi,
Thank you for the information on customisations for date and time formats.
I had happened to have looked at that already.

But the “format” of the date and time, does not effect whether it is correct or not.
At least, it “should not” effect the date and time.
But maybe it does, maybe that could be where the problem is.
Maybe there are some date/time formats or combinations of them, that cause miscalculations.
What date and time formats have you found it to work with?
I can try those, and let you know if it works on my system.

Thanks

I have checked that. It is correctly set to the local time zone.
Are you saying that since WordPress resets the server time to UTC, that I should also check the server time.

The server time has been (originally) set, so other scripts, etc are correctly set up. If wordpress is making adjustments to the server, then one would expect that it make the user far more aware of these modifications that it appears to at present.

Are there other possibilities for this error?

Thanks

Hi,

I’m not sure if you are talking to me or michelberdyn.
But in any case,
In answer to “You need to access my admin panel to check” – I prefer to decline that offer, thankyou.

As I said above, it worked and then it didn’t, with no other changes on this PC. So javascript errors that appear now, and may even existed at the time that the plugin worked, are a red herring/distraction.
And I expect there to be some javascript errors, since as I have said, I have not updated anything on this system. But any new problems are therefore due to external changes.
Have you made the plugin dependent on a more recent version of javascript, or more dependent on a particular javascript engine (as used by particular browsers)?

Though, there is the third factor of the server the website is on.
The changes that have been made, are to the plugin and other updates to wordpress, and other system software on the server that hosts the website.

I am running a hole bunch of other plugins, not all of them activated at any one time, and I can switch them in/out. I have not noticed any problem like this with these others (except for a partial problem in just one small part of woocommerce, which looks more like a template problem with “z index” numbers, and another with pagebuilder interfering with the display of visual editor which happens on a range of PCs).

Thanks

Just to note.
It wasn’t me that marked this issue as resolved.
Replied to – yes.
Resolved – mmm.
Bit like the shop attendant filling in the customer satisfaction survey.

Lets keep on plugging on (so to speak).

Hi,

My screen looks just like that of
michelberdyn (@michelberdyn) above.

I installed this plugin months ago, and it worked as far as this screen goes.
I deactivated it for other reasons (including where to display yet to be decided). I may have gone so far as to uninstall it.

But about a month ago (maybe more), I updated it.
Then thought I’d have another look at where to place it.
It was then that I noticed that it was not displaying all the options for choices of languages (i.e. checkboxes for each language), that it had done before.

I thought this might have been due to the previous version, leaving its settings intact when either deactivated, and/or uninstalled, but then they were getting in the way, or not functioning after the re-activation and/or re-install. This may be caused by a change in the structure of how nthe settings are stored, so the plugins thinks the data is there, but can not access it. Just one possibility.

But I have not updated or changed the browser (nor the whole operating system) between the installation of the functional plugin, and the activation of the problematic plugin.

So this suggests that (as you have referred to) if there is a problem with javascript, then it is due to an alteration of the plugin, and not something inherent in the users system.
The alteration to the plugin may well work just fine on a browser with updated javascript features, but that means the alteration had been made and also that it depends on a more recent version of javascript (even though it originally worked well enough with older versions of javascript).

I hope this information helps in diagnosing the problem.
Thank you

Jake,

That’s caused an idea;
If the system disables the tab for any reason (e.g. “disabled for user setting”),then if it could display the information about why say by hovering over it, or a question mark help icon, then users would have little trouble in trying to rectify some of these problems.

This approach could be applied to many other conditions that are set by user settings, or plugin settings.

Thanks

Observation of buttons in Visual Editor

With (Aqua) Page Builder active, the button set that is shown in the Visual Editor are colourful.

With (Aqua) Page Builder de-active, the button set that is shown in the Visual Editor are less colourful.

This suggests that the page builder is swapping the button set.

Hi razvanimal (@razvanimal),

Thank you for getting back to me. I understand that now time is of the essence for you getting your business up and running.
Any further help you can give will be appreciated, not just by me, but by (many/any) others who benefit from the removal of this inherent latent problem.
I have redone my previous message to address remaining options;

Q1) This is good news to hear that the problem is no longer a problem.
But hopefully the adventure is not over.

Q2) We have not found the jump point yet.
Are you still willing to help?
I need to clarify what you have done, and get to the cause of this problem.
When you use the word “using” for your plugins, it is ambiguous as to whether you mean “now”, or “recently”, or “recently up till now”, or “continuously from before,now, and future”. (e.g. “Ultimate social media plus“).
Can you please lay it out similar to this;

i) Prior to problem – plugins and suspects (versions) that were installed, plugins that were active
ii) During the problem – plugins and suspects (versions) that were installed, plugins that were active
iii) After the problem – plugins and suspects (versions) that were installed, plugins that were active

So, can you please restate the plugins, widgets, etc that you are talking about above but be more specific as to the timing. Such as previously, and as you are now planning to run.

For example, it is not clear at what time you added Jetpack, and begun using its facebook widget.

Q3) As you do not have time, and you are running a business on your site, then we won’t do this option.
But as a note,

Ways to Recreate the problem on the/a server

The previous state could have been recreated is by using a backup of the site.
This could be restored to you live site, or more safely, be installed on a server on your PC (either as a virtual machine, or as a LAMP server).
Another (possibly simpler) way is that the specific plugin could in effect be “rolled back” to a previous version, if you have a copy of the previous install (zip) file, by uninstalling the updated version, then installing the older version by upload.
If you didn’t have a copy of the old file, then you might be able to request one from the developer.

Independently of the above

, re ;
”

I was able to locate the file leading to the Facebook-y page: wp-content/plugins/facebook-pagelike-widget/fb_class.php

with the following related plugin: https://www.ads-software.com/plugins/facebook-pagelike-widget/

”

As you have noted -that is what calls the facebook-y page, and that is part of the widget.
The widgets can be assembled in to the page by the Page Builder.
We need to find the location in the page builder and associated files, where that widget is called up.
That location will be near the jump point.
So,

Q4) Can you please look for that widget name in files on the server?
And we will possibly look at their text contents.
You may have a text “viewer” and possibly a “text editor”, and maybe a “code editor” on your server. You can safely use the viewer to read the text, and use it’s search function to search for places in the file the text actually appears.
(Q4b) Do you use cPanel or something like that on your server?)

Note

as with all problems,
just because the problem has gone away,
doesn’t mean the cause has been removed.

In this case

the jump point is still there,
just not being a problem at the moment.
Some other plugin may cause the same problem to recur in future.

Also of help to all,
is to report your finding to the plugin author team,
and to the page builder team.
Try to use a title that includes “Visual Editor not shown” and possibly “text” and “buttons” as appropriate.
So this will be easily found as part of this problem genre.

Thank you

Hi razvanimal (@razvanimal),

It sounds like your problem is completely fixed;
Q1) Is that true?
If it is true, then this is good news to hear.
But hopefully the adventure is not over.

Q2) We have not found the jump point yet.
Are you still willing to help?
I need to clarify what you have done, and get to the cause of this problem.
When you use the word “using” for you plugins, it is a bit ambiguous as to whether you mean “now”, or “recently”, or “recently up till now”, or “continuously from before,now, and future”.

So, can you please restate the plugins, widgets, etc that you are talking about above but be more specific as to the timing. Such as previously, and as you are now planning to run.

For example, it is not clear at what time you added Jetpack, and begun using its facebook widget.

Q3) As I had not asked you to change the state of your server for this diagnosis, any change (such as updating a plugin so it no longer creates the problem) makes it a bit more difficult to recreate the problem.
Would you be willing to return your server to the problematic state (if needed) so we can find the jump point?

Independently of the above

, re ;
”

I was able to locate the file leading to the Facebook-y page: wp-content/plugins/facebook-pagelike-widget/fb_class.php

with the following related plugin: https://www.ads-software.com/plugins/facebook-pagelike-widget/

”

As you have noted -that is what calls the facebook-y page, and that is part of the widget.
The widgets can be assembled in to the page by the Page Builder.
We need to find the location in the page builder and associated files, where that widget is called up.
That location will be near the jump point.
So,
Can you please look for that widget name in files on the server?
And we will possibly look at their text contents.
You may have a text “viewer” and possibly a “text editor”, and maybe a “code editor” on your server. You can safely use the viewer to read the text, and use it’s search function to search for places in the file the text actually appears.
(Do you use cPanel or something like that on your server?)

Note

as with all problems,
just because the problem has gone away,
doesn’t mean the cause has been removed.

In this case

the jump point is still there,
just not being a problem at the moment.
Some other plugin may cause the same problem to recur in future.

Also of help to all,
is to report your finding to the plugin author team,
and to the page builder team.
Try to use a title that includes “Visual Editor not shown” and possibly “text” and “buttons” as appropriate.
So this will be easily found as part of this problem genre.

Thank you

Hi razvanimal (@razvanimal),

Q1) Did you find the plugin to be an improvement on the ease of use?
and does it help reduce the frustration significantly (or not) for you?

Q2) Can you try de-activating the Social Media plugin, and then see if the visual editor works ,
a) with the page builder activated, and again
b) with it de-activated?

Q3) Can you please confirm that that is the correct name of the social media plugin? and also let me know the author’s name, or include the link to it on the WordPress plugin site?

Q4) To search for specific text;
a) If you have ftp to your site, then you could try FileZilla.
b) But it is convenient to log in to you main web server control panel.
That is the main server space, not the WordPress dashboard.
If you have got a typical hoster, then you will very likely have a “file manager” type utility in the menu system, and use that.
I would probably go for a search in the folder where the plugins are, to find the text within the plugins. But the text may also appear in logs of errors, or logs in general. It could be in themes. But it also is appearing in the administration screens so you’d need to look in that area too.
But I think the best and easiest way is to do a complete search of just about everything, so there’s no chance that you can miss out on any possible location.
We don’t exactly know what the problem is, and we don’t know exactly what is causing it, so we don’t need to go making assumptions on “where” the possible problem code is. (good thing the search is automated).

Make list of all the places that the various texts appear in.
Then we will look for where “those places” (files) get called from.
And those “calls” are probably just after where the decision to show the facebook-y thing is made.
And hopefully that is the very same (or nearby) place where the same decision is made to show the visual editor with the white text on white background and hidden buttons.

Thank you for your help.
We have a few more turns before the home straight.