ade11
Forum Replies Created
-
Imagely,
We note you have added a new filter ‘ngg_default_global_settings’ in your latest release so that theme developers may change the path, but the method used to initially set the path is still the same
implode(DIRECTORY_SEPARATOR ...method.Surely you should _default_ to the correct
wp_upload_dirmethod, which would be correct then in all cases, but in case it really wasn’t they can use your new filter?Whilst we like the idea of filters, many of our sites are built by people without programming skills, which is the strength of WordPress, so though we appreciate you have _addressed_ the problem, we still do not believe you have _fixed_ it.
It is a very tiny change to make your plugin fully WordPress compliant, please can you ask your developers to reconsider implementing
wp_upload_dirin all places where the path is needed ?To note, your plugin uses this implode method in 2 places, but uses wp_upload_dir in 4, so it seems inconsistent?
We look forward to your next release !
Many thanks.
Imagely,
Thanks for attending to this so quickly, we are most appreciative!
Sadly, the line #49 of the mentioned
module.nextgen_settings.phpis unchanged and still contains that incorrect method. That function there appears to set the path going forward for all gallery creating so is fundamental.If we change your line to for instance;
'gallerypath' => @wp_upload_dir()['path'], just as an example, then it creates galleries in the correct location.For legacy + security issues on our multisite, wp-content/uploads doesn’t exist and can’t be created by plugins (not owned by apache).
We have seen other servers also where the whole wp-content directory is moved, it is allowed, so your method effectively hard-codes an error.
On the other hand, if you use the WordPress-provided
wp_upload_dir()function then that will always return the correct value regardless of environmental and server settings and the benefit will be your plugin can work in all situations. Please could you consider using the WordPress method instead?Many thanks!
- This reply was modified 6 years, 1 month ago by ade11.
Forum: Plugins
In reply to: [Quiz Cat - WordPress Quiz Plugin] Issue on multisite with unfiltered-muWe found adding the kses filter wasn’t enough, we also needed to whitelist iframes in the wysihtml component. We dequeued wysi.min.js, copied wysi.js to the theme, and modified the ‘tags’ array to include iframes;
iframe: { 'check_attributes': { 'src': 'url', 'height': 'dimension', 'width': 'dimension', }, 'set_attributes': { 'frameborder': '0' } },It now works, albeit with a different kses filter, but we would regard this as a bug in the plugin, as it should take account of likely multisite use, and presently it does not.
Also we note the wysihtml component has a more recent version available, not sure if that offers any advantages here though.
a.
- This reply was modified 8 years, 6 months ago by ade11.
Sirs, wondering if there is any update on if the plugin can be repaired to work in multisite again?
We need a position to tell our users, whether they need to wait for your update or if we need to find alternative plugins for them instead?
Please let us know, soon as you have a moment, many thanks !
a.
We have a problem with this approach to storing settings in top-level (non-blog-level) tables.
We run a stage-production system, so sites are developed in one platform, then exported to another. Only site-level tables can be exported, so then this plugin won’t work for them.
Consider also working with wp-cli’s db export –tables scope function, the normal for multisite exports. It means sites are not self-contained, and cannot be exported/imported through standard WordPress methods if using this plugin.
In our opinion, the plugin should store all settings to do with the site in the site’s own tables to make it fully compatible with all types of WordPress multisites.
Please can you point this out to your developer?
Many thanks!
As per your good suggestion, we temporarily network-activated the plugin to change the path, then de-activated it again. We note that network activating your plugin also activates it on the top-level site, an unwanted side-effect, so we had to go and de-activate it there also.
Our network people don’t want us to keep this plugin network activated, on account of the number of sites we have, and only a minority want to use NextGEN, and we cannot be certain what other side-effects your code will introduce. It does not behave the same as other plugins when they are network activated (viz. the above).
We do still however feel that hard-coding the uploads path is wrong, note this interesting quote from the official WordPress codex here;
https://codex.ww.wp.xz.cn/Determining_Plugin_and_Content_Directories#MultisiteIt’s important to remember that WordPress allows users to place their wp-content directory anywhere they want, so you must never assume that plugins will be in wp-content/plugins, or that uploads will be in wp-content/uploads, or that themes will be in wp-content/themes.
Thanks for all your help!
We don’t have the plugin network activated, it is activated as needed per site.
How can we access this field without the plugin being network-activated ?
Thanks!
VHX, apologies for late reply here!
I think there are 2 approaches to multisite, the one would be maybe where all the sites were connected in some way, owned by one organization perhaps, and the other where all sites were separate, as in a hosting situation, each site wanting different plugins. We have the latter, so for us, ‘admin_menu’ is what we need, whereas others may like the convenience of setting things once for their whole network.
This would be a philosophical choice for you though, as I could only speak for our multisite use which may be very different to others.
Also, should mention our client moved on and implemented a link with a script in one of their posts instead, so won’t be using the plugin after all.
Forum: Plugins
In reply to: [Custom Post Type UI] Updated and now 404This 404 issue seems to be to do with the creation of automatic rewrite_slugs, or more accurately, the value that tells it to do so.
In the old values for instance for ‘rewrite’, it is 1 or 0, and the new ones want to be true or false, and the check to decide whether to do a rewrite_slug seems to fail?
Simply going in the backend and saving the options corrected it for us, ie. it puts a ‘true’ in the field instead of a ‘1’ so the get_disp_boolean() function can evaluate it correctly?
Hopefully this will help others experiencing this issue.
Forum: Plugins
In reply to: [Custom Post Type UI] Incoming version 1.0.2We had this same problem.
It may be to do with your old values for instance for ‘rewrite’ being 1 or 0, and the new ones being true or false, and the check to decide whether to do a rewrite_slug?
Simply going in the backend and saving the options seems to correct it, ie. it puts a ‘true’ in the field instead of a ‘1’ for the get_disp_boolean() function to evaluate correctly?
a.
Thomas, apologies also for my even later response, I had a week off.
Our client activated the plugin on 2 other sites and did not experience the error, so I’m happy to concur with your opinion this was a false positive, due most likely to me testing the plugin in isolation, and not having other bits in place.
Many thanks!
a.
Forum: Plugins
In reply to: [The Events Calendar] Events Links Not Working+ me
Thanks for the workaround from srfrmac87 above, but can the plugin author fix this? It is a definate bug, I get it in the venues website field. Maybe other places, not had a deep look yet.
views/modules/meta/venues.php, line #38,
esc_html_e($website)should probably be just_e($website)or some other form of that? But notesc_htmlis the point here.**Update:
Also, since we can now see the link code,
target="self"will open in a new window, which I actually prefer (is this an option?), but anyhows the target should be_self??Forum: Plugins
In reply to: [Timber] TimberPost:: errors on live machinesThanks for the quick response, and apologies for my much slower one, things have been busy in our enterprise, and that particular development needed completing quickly so I didn’t get a chance to implement your check above.
I will try put this on another site next week, as I am also keen to see what the issue might be? I imagine that object is empty.
We’re running PHP 5.3.3 and WP 3.7.1 on all machines, the network chaps will be upgrading to 3.8.x in couple of weeks I think. That’s the policy!
Unfortunately we can’t generally give SFTP access, that’s also policy!
a.
To add to this, basically all the menu options (except the “import”, for some reason) are being drawn with the wrong capabilities for multisite use.
Administrators and Editors need to be able to change the plugin’s options, “manage_options” and “activate_plugins” are the ones used currently, on multisite that means only super-admins have access.
In our case (and probably most others) super admins manage the network, not individual sites, individual sites have ordinary administrators or editors.
This is an extremely simple fix, please can you incorporate it into the next update?
Forum: Plugins
In reply to: [Magic Fields] Undefined variable: result RCCWP_Menu.php on line 208me too!
WP 3.4.2 + WP 3.5.1, both multi-site
Unmodified TwentyEleven, NO OTHER PLUGINS ACTIVATED
Means though the plugin loads, it doesn’t create anything. Clicking the “create” on the first magic fields screen gives us many more errors, and nothing in the dropdown (nothing was created in the tables).
However, on WP 3.4.2 single install, we get no such error and can add things.
We conclude therefore that this is to do with plugin incompatibility with WordPress multi-site ??