jon

Re-reading your question, I realize now that you may actually be writing your own shortcodes.

If so, what I’m talking about is a shortcode that requires an [/shortcode] end tag and returns $content as a parameter. First thing to do with $content is $content = do_shortcodes( $content );

“Should I give him that main account?? Should I create a new account with admin privileges?” – there is a definitive answer to this that is not related to WordPress.

Long established fundamentals of Computer Security tell you to never share usernames. Doing so really reduces your ability to diagnose and control a security breach. In fact, at my last employer before retiring 10 years ago, an excellent person was fired on the spot when her manager found out she had used someone else’s username while “someone else” was on vacation. Just once! That is how important the folks in charge of Computer Security considered the one person/one username rule was.

In WordPress terms, it is the difference between shutting down your entire site versus disabling one username if a security issue occurs. It is a lot easier to figure out what happened, too.

This is not really an issue of Trust. Bad things happen to good people, including infected computers. Even the best antimalware software occasionally misses a brand new piece of malware.

Nightly backups are essential. I do incremental backups of my entire Linux server to Cloud storage using (open source) Duplicity, which allows me to turn the time machine back to any date (but always the same time, in the middle of the night) since I first built the server. For commercial shared hosting, I cannot run Duplicity directly, so I plan to use (open source) sftp on my Linux server to copy the shared hosting files and database each night, then use Duplicity to incrementally backup to Cloud storage from my Linux server copy. I’ve been pleasantly surprised at just how small the nightly incremental is.

In general, I would treat the developer like a well meaning human being — being human means mistakes and external factors can happen — just as you should an employee, and help your developer deal with potential issues. As well as backup, you should be doing monitoring to detect when something goes wrong.

No, I have not seen anything specific to your problem. In general, here are some general things that might or might not apply in your case:

1. AJAX is not handled correctly in the current version of the plugin; all AJAX requests go to the Active Theme, no matter where they come from
2. I have seen a lot of problems that only exist for the Admin who is testing, but things work fine for any Site Visitor, especially if the Site Visitor is not logged in to WordPress
3. Caching, both browser caching, and server-side caching by a plugin, is often a problem, especially after changes are made to the Multiple Themes plugin settings that change what Theme is displayed for a given URL (that is cached)

Hope you get it figured out.

I was unable to find any way to directly do what you are looking for, so I suspect that the most efficient way to do this is to get all the Posts at once, by dropping the ‘category’ entry in the $args array.

Then there are two approaches to consider, to process the array:

1. use PHP array function(s) to do the counts for you
2. have get_posts() sort by category, and use a foreach loop to display a count whenever the category changes

The feasibility of Option 2 is dependent on what order you want the Category counts to appear.

Let me know if you need more details on actually coding this.

I would recommend re-posting this on https://wordpress.org/support/plugin/woocommerce

Reason: woocommerce experts are there, and probably won’t see your question here.

It has been too long since I was involved with this plugin for me to give you “best possible support” type answers, but this is my best shot. I know it sounds stupid, but I have seen it fix otherwise impossible errors:

Make notes of all your settings, double checking that the URLs are correct. Then deactivate and delete the plugin, and reinstall it, and re-enter all the settings.

The reason that this might work is if the plugin stored any Site URL-related info in its settings that are not visible on the settings pages.

Not sure how much this will help you, i.e. – you probably already know this, but….

In the PHP code you displayed, the function groups_get_groupmeta() is returning a string, rather than an array, value.

Although the entry says that, this post leads me to believe that it worked properly as of 4.5.3:
https://wordpress.org/support/topic/issues-with-latest-wp-update?replies=2

I think it is worth trying, especially given the 20,000+ active installations using it.