Forum Replies Created

Viewing 15 replies - 1 through 15 (of 31 total)
  • Thread Starter mdunham

    (@mdunham)

    Thanks – working again as it should!

    Thread Starter mdunham

    (@mdunham)

    I can confirm – 0.7.4 corrected the problem. Thanks!

    Thread Starter mdunham

    (@mdunham)

    FYI – I have downgraded to V7.1 and the media folder is working again as expected. I still want to be able to keep this up to date, so do let me know if you find a fix.

    Thanks for your help.

    Thread Starter mdunham

    (@mdunham)

    I just see this in the media folder. Instead of pointing to the files on the CDN, it is looking for the content locally.

    Example URL in media folder: http:///wp-content/uploads/sites/2/2017/01/2017-01-14-091.jpg

    That file was uploaded and showed properly before the upgrade. It shows properly on the front end – coming from the CDN. This behavior is only when trying to view uploaded files from the media folder.

    On the front end, URLs look like this: http://fotos.memoriafoto.com/wp-content/uploads/sites/2/2017/01/2017-01-13-086.jpg

    So that is a “custom URL”as I understand it.

    Thread Starter mdunham

    (@mdunham)

    I just want to report that NewStatPress is working fine on Multisite now after the latest updates.

    Implementation and configuration for Multisite is per site instance and not for the entire network. You need to be a network admin to configure the options, but any user can view stats.

    Thanks

    Thread Starter mdunham

    (@mdunham)

    It is not implemented in sub-directories. It is implemented as domains using the network redirect functions of WordPress multisite – so there are multiple domains that are directed to the appropriate subsite, which does not have an actual, corresponding directory – but is called by the documentation a “sub-domain” implementation.

    Thread Starter mdunham

    (@mdunham)

    Looking at your screenshot – I can see the problem. Although this plugin was working fine on multisite implementations before your use of an external API, it is now broken on WordPress Multisite.

    Here are the symptoms:
    – when it is installed and setup to be available to all sites, but not network activated and active only on one or more sites, but not the primary site – the “Option” does not show on the sites where it is activated and the Overview graph does not run. A message shows:
    “Impossible to load the overview: You must activate the external api first (Page Option>Api)”

    – when it is installed and setup to be available to all sites, not network activated, and activated on the primary site – the Option tab shows on the primary site only. When the option tab is selected on the primary site, and the external API is enabled, the Overview tab initially shows that the routine is having trouble parsing the path to plugin assets, but after a second load of the Overview tab, it starts working properly. However, other sites on the network do not run the API successfully and the “impossible to load…” message shows.

    – when it is installed and setup as network activated, the symptoms are exactly the same as when it is available to all sites and activated on the primary site and some other sites. It works on the primary site, but no options or overview on other sites.

    This was one of the few stats plugins that worked well for multisite implementations before the change to an external API. I believe it could be again, a good alternative for multisite, if one of these three alternatives are implemented in the plugin:
    – (Per Site) It can be implemented by site and the options tab shows on all sites and allows each site to implement the external API
    – (Network implementation) The option (and perhaps some of the other settings) would show on the the network dashboard available to the network admin and be used by all sites on the network including the primary.
    – (Controlled by Primary Site – almost no one is going to like this choice, but some plugins do use it) The options tab shows on the primary site only (like it does now) and whatever options are set on that site, including the external API, are used by all sites that have the plugin activated.

    I don’t know the motivation for the external API or how it operates, so I can’t say which option is the least problem to code, but I do know that as it is today, the plugin is no longer multisite compatible.

    We tried wp-control and we’ve got an update to 4.5.2 pending as well as plugin and theme updates pending. We didn’t see anything happen without the plugin turned on after 30 minutes at least. We tried using wp-crontrol to trigger an update to plugins and themes. Cron reported running but nothing happened. We don’t have any other problems with cron that we are aware of – we use it to trigger posts at set times, etc.

    We tried again to reset the plugin and force updates with crontrol running. Nothing. We have logging turned on but no log showing in the log tab.

    I’m thinking it may be a conflict or perhaps a permission error. We disabled Formidable and several other things we weren’t using recently so unless you are aware of a plugin that is a known offender, I’m not sure where to go.

    We also trying to use Easy Updates Manager. We really like the interface and would like it to work but it has not so far.

    We have a locally hosted (our own IT) multisite setup. We have checked the Config file, we can manually initiate an update of any plugin or theme. We have tried resetting the plugin and forcing updates. Nothing happens. Everything is set at default at the moment.

    Where should we look for issues? Not sure where to go now that we have tried the fixes we’re aware of from looking at the forum.

    Yes, I just did that. After the manual delete and reinstall, the plugin is now at the correct level and I checked the previous errors in the editor and URL rewrites – all is well again.

    Thanks

    A couple of notes: I am using WordPress multisite. I have 5 sites using Cloudflare and they all show the same errors. My other sites are fine.

    Before I try to update the plugin, I see:
    CloudFlare
    Network Activate | Edit
    CloudFlare integrates your blog with the CloudFlare platform.

    Version 1.3.21 | By Ian Pye, Jerome Chen, James Greene, Simon Moore, David Fritsch, John Wineman (CloudFlare Team) | View details

    When I run update on the Cloudflare plugin (only), after the update, the exact same version is shown – 1.3.21. The new version is not loaded according to the dialog

    I tried deleting the plugin from the network admin panel so I could reinstall it manually and the panel came back asking to delete all plugins from the multisite installation. Of course, i aborted the attempt.

    I haven’t tried going in to manually delete the plugin yet. That is my next step, but all the errors this is throwing does make me wonder what is up.

    I’m getting similar errors from my sites using CloudFlare and this plugin. The ASCII characters in the editor and in the URLs are being rewritten. I’ve tried updating to the latest version, but 1.3.24 loads but still shows that it needs an update. I’m guessing that the version coding is failing along with the odd character rewrites.

    Please get these cleared up! Thank you.

    I don’t see any problems with the new version at the moment. I haven’t tried posting with it, but I have tried opening a current post and checking the text tab and add media button that were not working before.

    Thanks for working on this – I will let you know if I see any further problems

    I am seconding this with the news it also breaks the media button in the editor

    Thread Starter mdunham

    (@mdunham)

    I have nothing at all in debug.log I mentioned apache errors because that is what I was seeing.

    PHP 5.4.45

Viewing 15 replies - 1 through 15 (of 31 total)