Skip Navigation

[Resolved] network activated types on multisite but no toolset plugin updates

This thread is resolved. Here is a description of the problem and solution.

Problem:
On Network installs the Update and Commerical Tab (Installer) are different than on Single Installs.
Can you explain how to use it on Networks?

Solution:
1. Upload (first time) all Toolset Plugins to your FTP

2. Network Activate them

3. Register them

4. Update (via the Installer/Commercial Tab) Types, then all other Plugins

Note that without Types, the installer menu is not provided.

You can activate types either on subsite and access installer on Dashboard > Settings, or network wide and access installer on Dashboard > Plugins > New

This support ticket is created 7 years, 5 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 10 replies, has 2 voices.

Last updated by jimP 7 years, 4 months ago.

Assisted by: Beda.

Author
Posts
#446770

Please see previous support thread post for summary description/images:

https://toolset.com/forums/topic/toolset-updates-do-not-show-up-on-multisite-no-commercial-tab/#post-442890

I was told to start a new thread, as there may possibly be PHP errors.

My goal is for us to be able to readily update Toolset plugins on a multisite. I have network activated Types in order to get Installer to work, but it reports errors when attempting to update, as suggested in the screenshots on that post.

The site debug info I provided is for a sample site on our multisite that uses Toolset; this behavior is true across all sites (Installer can only be seen on a site, not on network admin, where plugins are typically updated). As you'll see, when I attempt to update via network admin, that fails as well.

I've reported this problem for some time, and hope we can resolve it.

Thanks,

Jim P.

#447098

Let me go over some details that Luo did not pas to you, as it seems.

1. Types is 100% required, if you want to use the Commercial and Automatic updates
So, if Types is not active, this feature is not present.

I was the 2nd Tier handling this issue, and I still await confirmation for somehting I requested:
- Enable Installer (the Commercial Tab) on all our Plugins, and not only Types

2. You should activate Types either on subsites, and access installer on Dashboard > Settings, or network wide, and access installer on Dashboard > Plugins > New

The major problem is we force you (our users) to use Types if you want to register Toolset.
And this is a problem, since Registerign is mandatory to receive Updates and support.

But if you do not activate Types, you will not see any way to register the product.

With that I refer again to #1, where I state, that I pushed DEV to "fix" this, although it will be handled as a Feature Request for now.

Now regarding the issue itself.

I tested this back then on MS (Multisite) and was able to update the Plugins, or Register them, following the above restrictive options.

It worked.

On your end it seems to have some problems with the copying of a file.

This seems to be a edge case (exception) as I was not seeing that problem on our own MS Test Install.

I would like to help you solve this problem.

1. Can we gain access to the Site where this happens - please aknowledge that it should be a Test Site, becuase we might need to debug on there.

2. What I can also offer (perhaps much better and safer for you too) is a Test MS Site that lives on our Server.
This would be a temporary Test Site, where we can try to replicate this problem.

The Process woudl be that I pass you the Login details, and you populate the Site so to reproduce this issue.

Then, we would debug in there, if the issue is reproducible.
But I suspect, it could be due to some Righs on your Server.

Can you ask your Server Admin for a Server log, to see if any related errors appear in there?

#447283

Thank you; all makes sense. To be clear, we do use Types on all Toolset-based sites, of course, as it is basic to the process. We have also attempted to network activate Types, but still encountered update error.

I think I will try to duplicate on our end, then ask WPEngine host to check error logs for the time in which write error appears.

Will be in touch when I can do this next wk.

Jim P.

#447310

I see that you use WP-Engine.

This Hosting service is known to us, it often creates some troubles (that's not baliming them, it's just a fact)

In most cases, the issue where due to Caching Services (which are excellent, but also very tricky and kind of "aggressive")

It would be very good to know if the Error Log says something, we want you to be able to use this feature at it's provided possibilities.

Please keep me updated, I will also update you here on the process I outlined above (integration of the Installer in other Paid components)

#448582
20.27.05-20.27.11.png

Okay, I did the following:

(1) I network activated Types.

(2) Then, upon refreshing the plugins display via network admin (on our multisite), I saw that two Toolset plugins had updates.

(3) I then attempted to update Toolset Layouts, and received the error you'll see in the attached. The filename is the approximate start and end time (in Pacific time; to convert to UTC you'd add 7 hr) of the process.

(4) I then checked the error log, both the one available to me and the one the WPEngine person provided, and don't find any errors during this time period at all...none.

So, I believe I am following your recommended procedure (i.e., to network activate Types), and I do then see Toolset plugins that require updating upon doing this, but I cannot update them, for whatever reason (e.g., write permissions error) that does not show up in the error log.

I'm happy to further diagnose.

Jim P.

#450072

I re-tested this on our Servers on a Multisite and our Update mechanisms work fine.

1. Upload (first time) all Toolset Plugins in a outdated version

2. Network Activate them

3. Register them

4. Update (via the Installer/Commercial Tab) Types, then all other Plugins

This works fine.

Two issues that can happen here are:
- Toolset Layouts is the largest Plugin on Toolset. It might time out. You can try again, or contact the server Admin to check if the Update process is timed out by the server
- Cache issues (related to the WP Engine Server)
- wrong or corrupt subscription Regstration Code (could be solved by delete/re-register the Plugins)

This issue is due to one of above points. Most likely it's due to WP Engine Cache or timeout settings, which I can not control or reccomend of, since I do not have a WP Engine access.

Can you provide a full clean and fresh Test Install, where we have Database, SFTP and WP Admin Access, and the issue is reproducible?

#450208

Okay, thanks. I will test your theories with WPEngine support staff, and will be in touch in a few days, hopefully.

Jim P.

#450438

Yes, please let me know.

WP Engine is a big service provider, and we can not neglect compatibility with them.

I do not see any other tickets with this issue, but then it's also not the large bulk that uses MultiSites and on WP Engine, so it might very well be that there are no reports becuase there are not so many sites of this kind.

With a definite Error Log or any other information the Server Admins can deliver, we will have more chances to spot the problems.

#452737

Quick update: we are still waiting for WPEngine clarification, and will be in touch as soon as we can.

Jim P.

#452937

OK, thank you for this update.

Please let me know as soon you have some news.

#454491

Okay, we have this one fixed now! It was a WPEngine thing...see below, from their support staff...I've verified that it now works...Jim P.

***

Thanks for your patience here while we looked into this further. After further investigation, I have found and removed the rule that was causing this problem. It appears that you had this nginx rule on this install:

location ~* (xmlrpc.php|admin-ajax.php) {
add_header X-Type "nocachearg";
proxy_pass hidden link;
break;
}
This was most likely implemented in a previous encounter with our support team but it was preventing the updates from working properly. Since removing that rule, I have been able to successfully update several items through the settings -> installer tab.

This ticket is now closed. If you're a WPML client and need related help, please open a new support ticket.