MKSnMKS

Hi Joy,

Thanks for that.
I had made fairly good description of the concept at the Trac ticket at
https://core.trac.www.ads-software.com/ticket/44458

I had got the impression that these forums have a few forums which get perused by development teams for wordpress, including ;
a) the “Everything else” forum at https://www.ads-software.com/support/forum/miscellaneous/ and
b) the “Requests and Feddback forum at https://www.ads-software.com/support/forum/requests-and-feedback/, and
c) possibly the “Alpha/Beta/RC” forum at https://www.ads-software.com/support/forum/alphabeta/

I have made gone to the effort to make suggestions for improvements in these forums in the knowledge of that, and have even been informed by some moderators that the developers scan these topics, and that one of their methods of searching for topics is based on them not having had a reply (which was learnt when I would add after thoughts to initial comments, and be told that this was called ‘bumping’ and is considered as something that should not be done – for the very reason that developers and other interested parties would be less likely to find it).
Now , thanks to your happening to find this topic, and having replied, I learn that there is very little chance that the kind of people that I was under the impression scan these topics for new ideas, actually will do so.

Please may I ask you to communicate with any developers you wish (as many as possible), and please ask them to consider doing searches in these forums (3 above) for topics set as “this topic is not a support question”.
They will find plenty of suggestions made by run of the mill users, that are made to make WordPress more useable in the user’s hands.

One of the suggestions (if I remember rightly) that I have made is to have a ‘redirection’ or ‘copy to’ function, that basically automates the process that you and I have just gone through here.
That is “Developer searches forum, spots interesting topic, and notifies related developers who might be interested”. The topic author does not need to know the ins and outs of where the topic needs to go, they do not need to understand technical matters, who does what, the who’s who politik, some sort of submission system.
This function would allow developers to do a scan search of topics in forums, looking for related topics, and mark them (click a button), to copy the information to a developer related topic/discussion. That process may include an automatic placing of a post in the forum topic, to request permission to forward the topic to another developer discussion, and when the topic author clicks an approval button, then the copy takes place.
This process cuts down on the writing of custom messages each time, and facilitates the collection and collation of (what may be a vast) resource of suggestions and ideas.
A similar process could also be used to identify forum topics that have already begun work on a similar concept, duplicate suggestions and suggestions that are closely related (without deleting them), and other management that be be useful.
This suggestion is not intended to imply or force an obligatory function for the developer teams that would distract them away from their core (and enjoyed) tasks.
The suggestion is made, so that a possibly (very?) useful additional tool is available for supplying information from users to developers, that may be helpful for feeding in to the decisions for direction of development (where common pitfalls are, insights that could same time or effort in future, etc).

metaphor ;
This is a bit like “letters to Santa”
Lots of letters get sent to Santa, and we all know Santa does not exist (at least not as a real person, but some may be of that heart).
So many might think the letters are of no value.
That’s ok.
But if Santas postal address happens to be at one of the department stores or toy companies, then some serious market intelligence is gained, for free, prior to the impending time of it being most valuable.
(kind of funny how the items that run out first, are the items that had the biggest piles in front displays)

And somebody had to make them all (Santa’s helpers – some of us would have some others of us, believe).

So (call to action),
Joy, if you can, could you please communicate with the developers and
to the developers (Santa’s helpers) that read this ;

Please try an (even just cursory) scan search
of the topics in these forums for topics of interest to you, and set as “this topic is not a support question” (irrespective of how many replies they have),
to see if there are or might be some topics of interest that are worth disseminating in developer forums.

Thank you

Hi Joy,

I did that.
But I am not too keen to get into the nitty gritty (websites, forums, chit and chat) of the development team, as I want to avoid more technical problems than the ones I have experienced in this main site.
metaphorically ;
If somebody slaps one’s hand, then one is not likely to accept that person’s invitation to dinner (though one may choose to maintain a cordial relationship in the street)(one may even accept in future, after time or changes).

Please follow this topic, to help ensure that it gets to the people that would be interested in reading it.

I have also started other topics related to plugin handling, update, and unified approaches that might make WordPress plugin system more robust.

Thank you for helping.

Hi Stephencottontail,

re

“without having to make a post in the thread”

Is that the reason why the suggestion for “mark as” (ie an easy automated system) is not done? that is how the decision makers want the process to work.

A user that is concerned about the nature of a topic, who makes a comment in the topic, might be viewed by other users, and held to be by the moderators, as attempting to be a mini-mod with their intervention comment.

The alternative suggested “mark as” above has the advantage that the matter is more directly referred to the moderators, without intervention comment(s) which may lead to digression from the main topic, and nothing actually appears in the topic, until a moderator has decided that something needs to be done.
If the moderator considers that nothing needs to be done, then the topic is undisturbed, and its content is more to the point.

The inclusion of any information that the reporting user under the present method, places in their post (within the topic forum), would alternatively be included in the “mark as” report sent to the moderator.
If the moderator thinks there is no problem, then this report can be kept out of the topic.
If the moderator thinks there is a problem, then there are options for what happens after that (e.g. the report then gets inserted into the topic, or the moderator requests an explanation from the offending topic author or poster, or what ever else may be considered sensible).

But in any case,
the information and ability to carry out these actions is moved into the user interface, rather than further away in some help document, or after they have been informed through their own enquiry (as Kartik16 has been in this case).

The present approach is ;

All you need to do is reply to that with “spam” and add the modlook tag to the topic.

https://www.ads-software.com/support/guidelines/#contacting-the-moderators

The modlook tag does get looked at an resolved when seen by a moderator.

The request is for ;

a “Mark As” Feature on the Support Forums

So it seems that convenience of the present method would be improved by automating this present method, and putting that at the user’s ready access in the forum (what ever it is called, and what ever form it may take e.g. button, drop down list, link, etc).

This is a good matter to think about.
There may not be an immediate solution, but that doesn’t mean there isn’t one.

There are some important statements being made ;

1) locations;
the admin bar, other under Settings, Tools, Appearance, while for some access it only from its listing on the installed Plugin page itself.

2) adverse effect
a) irksome trying
b) to hunt

3) location not indicated to user during installation
a) often have to search for plugin options after installing a new plugin.

4) Level of User Capability
a) Some options you want to be accessible via a filter only, which is “If you don’t know what you are doing then don’t mess with this.”

5) Advantage of having a ‘convention’
a) It’s a style/choice thing. While I do wish there was consistency as to where that menu option is on the dashboard,

6) Choice
a) it’s up to the developer and WordPress shouldn’t force authors to make a choice as to where.

As initial work-arounds,
a) it is possible to install a plugin that allows the customization of the dashboard menu system (but probably does not include the menu in the list of plugins).
b) You can use your browser to save bookmarks to the settings, and then save them in a bookmarks folder (in your browser) called “WordPress Settings”.
So for the WordPress users, those options are available right now.

Thing is, computers and software are (supposedly) very good for making these adjustments (as is already exampled in the work-arounds above), so are probably capable of being designed to allow this flexibility.

To examine the elasticity (give and take) of this part (i.e. plugin settings) of the system;
a) it might be useful to have all plugins, put all their settings, in all locations, so a user does not need to guess, and can find them close at hand.
b) a request from a user for an improvement in convention, is understood, and the choice made by the plugin author is respected.
c) the user, makes use of the plugin that the author has designed, and (presumably) the plugin author designs a plugin that they want the users to enjoy using.
d) the experience from plugin to plugin, within the wordpress platform is allowed to vary according to authors wishes, and may possibly approximate what some user want in many cases.
e) the functionality, degree of control of a plugin, and its technical features, place requirements for skill of the user, in order to maintain proper function of the plugin, and reliable performance of the plugin, and in combination with the system.

One can image more considerations, but the above is an example of a few considerations which contribute towards the balance of ‘what is designed for use’ and ‘how it actually used’.
One method of creating a solution, is to make one solution, and everybody then follows that state of working.
Another is to allow flexibility.
The present system is flexible, and that is (very) good.
This is because there is more than one way to work, and more than one way to have problems, but there is usually at least one way (even under failure) to get the work done.
Single solutions are alright while they work well, but when they fail, everybody and everything is effected.
So flexibility is good.
As notable from above, the choice is made by the author as to where the settings are placed, and there are hopes that these are placed in locations that imply a level of expertise required to make adjustments to the settings (and it might be helpful to have some clear form of identifying which are considered to be the more expert and more simple places to locate the settings).

The suggestion that has been made, is to have these settings in one place.
This is the type of solution that has one uniform state for everybody.

It is good for those that want that.
With a slight re-arrangement of outlook, this can be considered as “an option” for the layout (one option).
Another option for the layout, might be “separate zones for settings based on expertise (e.g. Advanced,Proficient,Beginner)”, or some other forms of layout that might be designed to cope with balancing the objectives.

So this matter can be considered to be an ability to “select the layout” of some portion of the dashboard.
This is a bit like themes for websites, but for the dashboard.

Plugin authors could have their ‘recommended’ locations, and it might be possible for the users to have their ‘preferred locations’ for the settings, and those choices could be made separately for settings of each level of expertise.

There is no time constraint on when this needs to be done by.
At least one user has suggested this, as others may have done at earlier times.
This may not be considered an important matter to any of the designers, and the WordPress system that the plugins are used within.
This is a feature request that at least a minority of users may appreciate, when ever it may be permitted.

a Note on assessing the value to a user, as an estimate for the user-ship population ;
The value of this suggestion can be easily estimated, by summing up the time spent trying to find the settings (scrolling, clicking, etc) and valuing that.
“irk” is more difficult to quantify, but instead analyze what it is that is causing the irk and quantify that (e.g. non-intuitive, ‘hidden or as good as to the user’, settings for plugin in more than one place, overlap of settings for one plugin in more than one place but not obvious which settings are particular to only one of those places, not like most of the other plugins a user has).
Benefits may be estimated, e.g. time saved, keenness to embark on previously protracted tasks, better regulation of exposure to risk of faulty operation, maintain desirable freedom for both authors and users, workflow processes are streamlined.

• This reply was modified 6 years, 5 months ago by MKSnMKS. Reason: improved to format

Hi Caleb,

Thanks for the thanks, and for the link.
I prefer to keep comms at WP, otherwise I’d be all over the place with different plugins.

But please, feel free to copy and paste – no accreditation needed – just aim for getting what is helpful, through to where it needs to go – probably the dev team.

How does pull requests work?

Thanks

Hi pavloborysenko,

I activated “autoptimize” and it fixes the issue with the last js scripts.
But it looks like it is adding an additional cache folder, and possibly an additional caching system.

Thanks

Hi Caleb,

1) Re

it shouldn’t really be common to have deactivated plugins on a live site

This may have been what was previously normal, though even then – not the only operational situation especially for smaller users.
But nor has it been previously normal to have plugins that require declarations of compatibility such as WooCommerce now does.

So, especially during the change in the resulting operational environment, there should be many users that are disabling plugins of “unknown” compatibility, so they can update WooCommerce.

If you are suggesting that they then go on to delete these plugins that they have had to disable (temporarily till the plugins get updated), then WooCommerce is having a greater effect by this new requirement.

This situation therefore has a significant effect on plugins which are ill informed about the new requirement to declare compatibility, compared to those select plugins which are informed. So there is a biased outcome for plugin projects which is based on the information they are provided, rather than their programming proficiency or popularity of product.

2) Re

It “isn’t good” to duplicate “such” behaviors

There are many situations where behaviors are duplicated – the programming is not duplicated, just the same function is presented elsewhere. One example (using WordPress), is plugins that place their “settings” in the “Settings” menu on the left side of the dashboard, and “settings” under the plugin in the plugin listing, and “settings” within the plugin. This is up to three places that the same function is presented.
So it is not a big ask to repeat the same function, in locations where it is convenient to have it available to the user.

Instituting this feature will help the typical user help clean up problems with uncompatible plugins. There may not be many WooCommerce users presently reporting uncompatibilities to plugin authors, so one might conclude “therefore methods to assist the user to report are not needed because not many do”. But is is also possible to conclude “therefore the user needs to have better assistance to make a report, so that many more can and do make reports”.

What might be important to consider is ; “Due to WooCommerce’s actions, how many plugins are likely to be adversely effected and possibly dropped from popular usage?” – I don’t need to know the answer to that, but I do hope that it is being considered.

Thank you for continued discussion on this topic.
Appreciated.

Hi Caleb,

Thanks for that info.

What I notice though, is that the Status lists “all” the “Active” Plugins.

Whereas WooCommerce’s Update Compatibility Checker looks for all the “installed WooCommerce plugins” both “Active and De-Active”.
The WC Update Checker is not interested in other plugins, only the WooCommerce related plugins.

Additional Suggestions ;
a) What is also useful, is that Status list shows the plugin names with links to their plugin site. If this was done on the WooCommerce Compatibility Checker list, then it would make it much easier for users to report incompatibility to the respective plugins.

b) The Status list could be a good place to show all WooCommerce plugins, and whether they are Active/De-Active, and Compatible/InCompatible.

Thanks

• This reply was modified 6 years, 8 months ago by Jan Dembowski.
• This reply was modified 6 years, 8 months ago by MKSnMKS. Reason: improved formatting and layout

Hi pavloborysenko,

Also
1) might need to flush the cache.

2) These scripts are now showing;

*** Web Address ***/wp-content/plugins/woocommerce-products-filter/js/chosen/chosen.jquery.min.js
*** Web Address ***/wp-content/plugins/woocommerce-products-filter/js/front_comprssd.js
*** Web Address ***/wp-content/plugins/woocommerce-products-filter/js/easy-autocomplete/jquery.easy-autocomplete.min.js
*** Web Address ***/wp-content/plugins/woocommerce-products-filter/ext/by_text/js/by_text.js

Thanks

Hi pavloborysenko,

Thank you. I found it.

It is also available at;
Left Dashboard Menu => WooCoomerce => Settings
=> Products Filter (tab) => code/Options (click on “Options” to highlight)
scroll down to “Optimize loading of WOOF JavaScript files” and select “Yes” .

Done
not difficult when you know how.

Thank you for including this important feature in the plugin.

I noticed its description, which is pretty good ;

This option place WOOF JavaScript files on the site footer. Use it for page loading optimization. Be care with this option, and always after enabling of it test your site frontend!

a couple of finer points =
a) place => places or “will place”
b) “after enabling of it test your site frontend!” => “test your website frontend, after enabling it!”
c) “on footer” => “in footer”
d) could add mention of “blocking script” to make it apparent what it relates to, such as ; “in the site footer, so it does not act as blocking script in the site header.”

Slight corrections in other descriptions;
1) “terms is in: russian” => “terms are in: russian”
2) there are others – Q would you like me to do a more extensive check?

Thank you for your help.

Hi Andrew,

2) Sub-Topic – “mess”
2-pii) “apologies”
Wow – great words!
Please continue to be (relatively) fearless.
It is better to apologize for honest truths, than to not apologize for other truths, though its good to apologize for all types of truths.
2-pi) “mess”
General approach to “mess”es

try to compartmentalize.
break the situation down to smaller manageable situations.
avoid compounding and mixing up.
see which sub-messes are least problematic (or even are okay).
address the sub-messes which are most critical.
put things back together and test.
repeat to refine.

2-piii) I can only image the difficulties with compatibilities with themes (and possibly other plugins). It might be possible to collect information from users who have tested it with their theme, to build a list of themes that it works well/okay/partially with and those that it does not.
This becomes very easy to collect if the user can just click a button to send the details direct to database list, rather than compose emails that need custom handling.

Some thoughts;
a) the decision process could be treated like a module, that is known to handle certain situations, so the main plugin is installed, the user theme is detected (or list of themes entered), then the plugin installs the decision module.
b) a generic module could be used to test theme of unknown compatibility, and problems can be reported back to a database (similar to above). So eventually somebody (other team member?) can compose a module that works.
c) theme creators might be interested in writing a module specifically for their own theme(s).
d) consider page builders that can work with very minimal themes, as a recommendable environment for this plugin.

1) Main Topic – unknown compatibility with WooCommerce (latest versions)
The plugin can work well or only in some circumstances, with WooCommerce.
But that is not the problem.
The problem is that it is not “declaring” that it works with WooCommerce, by using the header tags that the latest versions of WC require.

There have been quite number of other plugins that have had the same problem, and fortunately KaggDesign was kind enough to let me know what the fix is so I can let the other plugins know.
See Below.

Thanks for getting back to me on this.
A bit slow, but better late than never.
I hope things have been alright, and that this fixes the problem.
Keep up the good work.

Please can you let me know if this helps?

Thanks

========================================

The fix for this is provided below, by
kaggdesign author of WOOF by Category,
which had alerted to the same problem,
and they found the fix.
So thanks Kaggdesign

Hi,

It is very simple. Open main plugin file /wp-content/plugins/woof-by-category/woof-by-category.php and in the first lines you can see the plugin header

/**
* Plugin Name: WOOF by Category
* Plugin URI: https://www.ads-software.com/plugins/woof-by-category/
* Description: WooCommerce Product Filter (WOOF) extension to display set of filters depending on current product category page.
* Author: KAGG Design
* Version: 1.5
* Author URI: https://kagg.eu/en/
* Requires at least: 4.4
* Tested up to: 5.0
* WC requires at least: 3.0
* WC tested up to: 3.3
*
* Text Domain: woof-by-category
* Domain Path: /languages/
*
* @package WOOF by Category
* @author KAGG Design
*/

Lines (bold-ed above)

* WC requires at least: 3.0
* WC tested up to: 3.3

are responsible to reflect compatibility with WooCommerce.

Hi Andrew,

The plugin can work well with WooCommerce.
But that is not the problem.
The problem is that it is not “declaring” that it works with WooCommerce, by using the header tags that the latest versions of WC require.

There have been quite number of other plugins that have had the same problem, and fortunately KaggDesign was kind enough to let me know what the fix is so I can let the other plugins know.
See Below.

Thanks for getting back to me on this.
A bit slow, but better late than never.
I hope things have been alright, and that this fixes the problem.
Keep up the good work.

Please can you let me know if this helps?

Thanks

========================================

The fix for this is provided below, by
kaggdesign author of WOOF by Category,
which had alerted to the same problem,
and they found the fix.
So thanks Kagdesign

Hi,

It is very simple. Open main plugin file /wp-content/plugins/woof-by-category/woof-by-category.php and in the first lines you can see the plugin header

/**
* Plugin Name: WOOF by Category
* Plugin URI: https://www.ads-software.com/plugins/woof-by-category/
* Description: WooCommerce Product Filter (WOOF) extension to display set of filters depending on current product category page.
* Author: KAGG Design
* Version: 1.5
* Author URI: https://kagg.eu/en/
* Requires at least: 4.4
* Tested up to: 5.0
* WC requires at least: 3.0
* WC tested up to: 3.3
*
* Text Domain: woof-by-category
* Domain Path: /languages/
*
* @package WOOF by Category
* @author KAGG Design
*/

Lines (bold-ed above)

* WC requires at least: 3.0
* WC tested up to: 3.3

are responsible to reflect compatibility with WooCommerce.

• This reply was modified 6 years, 8 months ago by MKSnMKS. Reason: typo and formatting

Hi Adnan,

I tried it about 4 or 5 times before writing this topic.

Then afterwards, I updated a theme, and thought I’d give a second batch of tries, and it worked not the first, but the second try in the second batch.

Yes, I am inclined to agree that it may have been something to do with the www.ads-software.com server – possibly heavy loading at the time – not something I’ve ever experienced before.

But it is odd that the site did not “find” the file – it’s not doing a search, it’s just direct access.

So yes, this topic is resolved.
But it might be prudent just to keep an eye out for any re-occurrence of this error.

Thanks

Hi Caleb,

Thanks for the reply.

Yes, (2) was an optional extra (just as 1 is an optional first).
But although the uninstall is just a click (or two) away, they are also page reloads, and scrolls. This list that is presented by WooCommerce is specifically only those which need to be handled.
On the other hand, if WooCommerce was able to have some hightlighted way to display the plugins which are on this list, in the plugins list, or make a submenu (on the left sidebar) for these plugins – then that would help the user decide how they want to process the plugins.

(1) is especially handy, in the case that it helps show if “all” the plugins are of unknown compatibility are inactive, then there is no immediately reason to prevent the update. It would continue to be useful, if it detected the activation or installation of plugins of unknown compatibility, after the update of WooCommerce.

Qa) Does WooCommerce continue to check plugins installed after the update?

Qb) Does WooCommerce continue to check plugins installed before, but activated after the update?

(1) is handy, in any case because the user can then deal with the plugins which are active.

Presently the method requires making a mental note, or jotting down the list, or copy and paste to notepad. In order to cross reference while on the plugins list. This is the kind of task, which computers are very good at doing. Every time a pen is needed, is time to ask if this is the best way (it may be the best way, but it is worth checking).

A bit of an extra understanding
The approach of uninstalling unused plugins, is good, but it is based on the proviso that if it is unused then it it is not going to be used.
This is not the case, when a user is trying out different options of plugins that cover the same needed functions – something which needs to be done when previously used plugins are either out of date, or become incompatible with the system.
The problem with plugins is that many have significant overlaps in function, with other plugins that may not be very closely related in their core function, which causes interference.

I have provided feedback to at least one plugin management plugin, with these processes in mind, and currently can do swap in/out tests more easier.

Thanks for forwarding to the product team.