donty
Forum Replies Created
-
Just been digging more and found a custom redirect rule in the .htaccess that should not be needed anymore which would have affected all previous attempts! Grrr…
Removing that and trying the previous approaches again I determined that if the URL in the podcast post for the Podcast File is set as the true URL not parsing through index.php on WP then it does work.
ie http://Website.our.domain/wp-content/uploads/sites/12/2016/06/Episode1.mp3
Instead of http://Website.our.domain/podcast-download/100/episode1.mp3
Testing on castfeedvalidator it now works fine.
I also tried changing the custom field entries to match for audio_file and enclosure but that isnt required to pass the validation.
I then tried it on a legacy network using the old MS files redirect and it still works. URL structure is different for old Multisite:
[audio src="http://Website.our.domain/wp-content/blogs.dir/12/files/12/2016/06/Episode1.mp3" /]
(NB in both cases substitute 12 for your blog ID number for the site)
This avoids the use of any re-coding and messing with plugins.
So now iPhones and others will be able to resume downloads and fill in the gaps and there is no more hard work to do.
Not sure about stats yet, will it work still as the podcast feed and other content is the same? What might I miss?
Essentially it is like hosting files externally like soundcloud etc but not sure how the stats will account for things?
D
Thanks Hugh, all good ideas. I think some form of a plugin is an option that we could work with.
Multisite is useful for groups and clusters of people. It is a relatively clean way to keep plugins, themes, users and controls together for connected sites and communities. But it isn’t perfect!
Most of the issues tend to come from short-cuts or short-hand that people use in their code structure that get tripped up with the multisite DB but this problem seems different.
It must be the way the core WP code handles the main redirect for requests for the uploads directory for the sites. I see other code where PHP can make use of the byte range option so it is possible just perhaps not within a plugin!
If I do get any more info or solutions I will drop you a line.
Thanks for the help and a seriously good plugin 😉
D
Hi Hugh
Thanks for getting back to me, but that means each subsite will need child themes for each theme used for all podcasting sites across the network and network groups.
That gets to be a real PITA for managing stuff across sites and servers.
We can apply other stats monitoring for file access to cover that, though the stats plugin is good and convenient it is less of a task than keeping track of patches in multiple child themes as people change them. It would ultimately result in a completely separate set of child themes required for any podcasting site.
Adding an option in the pluign at the Redirection panel to pull off the rewrite for multisite would help. The byte range is the only aspect that wont work but is essential for iTunes so it could be left as a per site option rather than creating a WPMU special?
Do you know of anyone who has multisite offering byte range without the url hack? It is not just us is it? 🙂
Thanks again for getting back to me, it is great when authors engage, but its not quite solved for me yet!
D
Forum: Plugins
In reply to: [Awesome Surveys] Multisite compatible?Hi Will,
Thanks for getting back to me.
No, I can’t do that for all sites on the MS so its per site activation.
Forum: Plugins
In reply to: [Custom Contact Forms] Issue with synchronizing dataThat worked for us. We needed to enable/disable then make a save to the form before it would stop producing the error.
All working well, thanks for the quick response and fallback option. Hope that doesnt make the code too much more of a pain to manage.
Thanks for your help, much appreciated.
NB Small donation made, if everyone does their bit, be it code, test or donate it all gets a bit better.
Forum: Plugins
In reply to: [Custom Contact Forms] Issue with synchronizing dataWe have just got the same problem, the plugin screams the error whenever attempting to edit any page.
Most standard Apache2.2 installs should work unless there is a specific mod-sec rule. Has CCF changed its methods in the last update?
Is it not possible to have any other permalink set than postname? Sure that hasnt been the case before? Could it be that people are coming into contact with apache 2.4 and need to change virtual host conf files?
Disabling plugins and theme changes makes no difference to the outcome for us.
Forum: Plugins
In reply to: [Access Areas for WordPress] disabling commentsYep, that works well! Thanks very much for the quick response and fix. I had a cache issue on the publishing mode which now works fine.
Where should we make suggestions for new features?
I would like to see areas being able to be members of areas – that would make managing things much simpler, ie anyone in a top level area would automatically be in a subordinate/associated areas too.
Anywhere to donate for you?
Forum: Plugins
In reply to: [Access Areas for WordPress] disabling commentsHi
We too cannot remove comments from posts/pages – even tried adding an area called ‘no-one’ and setting that to be the only area with perms to leave comments, but that didn’t work.
No comments/discussion setting is default and also set on the page.
Tried using WP defaults on the Comments option on the Access Areas section on the page, again with no results.
Also found I had to publish the page as private to get the desired control, is that usual?
Any ideas what is hooking comments in?
Currently running multisite, 3.6.1 and basic WP 2012 theme.
Thanks
D
We are not photocrati bods but have seen issues with 2.0.7 and 2.0.10 and Network WP 3.6. We went back to NGG 1.9.13 and all is back and operational.
The same errors have been coming up on various sites and installs for us and others around the net, but there appears to be no fix in view yet.
We will keep trying the betas, but it seems a general issue. If it doesn’t play nicely with other critical plugins these days there are other solutions for most of what we use Nextgen for but we would like to retain it as an option if possible.
The only solution we read of was resetting and removing/installing the plugin and starting again. That would suggest a DB upgrade problem moving from 1.9 to 2.0 but not heard that discussed anywhere else. Also the odd placement of the NGG styles in the root of the wp-plugin directory seems potentially a little odd for a network install of WP as sub sites cannot then have their own child version of the CSS unless I have misread that.
Editing and changing all our sites that use it would be a time consuming task but at some point soon we will need to decide whether to bite the bullet.
Do update if you find a solution!
Have installed wls and got one site to sort of show that it was active by disabling all other plugins, but none of the actual configuration sticks. Ie approval, emails, antispam etc all get removed on visiting the page.
To get this far I disabled the individual plugins on the blog sites, installed the plugin and network activated it. Same with WLS, however WLS is not giving much detail back just reporting notices of installation and then murm_options_page_update begin on the configs changes. On one site there is murm_options_page_update end but as above it does not store the detail of those changes.
As this is an active network I will remove the plugin and clear up anything in the db is I can find it and check back here/plugins when/if there are any new developments.
Just trying this plugin, but activating it on a blog is simply blanking the content panel in admin as soon as I save the setting. Is that what you are seeing?
Same Multisite setup, 3.4.2 and subdomain install. Obviously with a network the idea of disabling all plugins and setting everything back to a base theme is not appealing.
I wondered if in fact it should be network enabled as a plugin rather site enable since you enable the plugin with the individual site plugin but it appears to make no difference.
Forum: Plugins
In reply to: [Plugin: NextGEN Gallery] http upload errorBoringly I am just adding my voice to this. No flash uploader but the other methods (zip and non-flash one by one) work fine.
Is everyone here running WP 3.3.2? Permissions don’t directly seem to be the problem. I have had issues with Flash and HTTPS before but it matters not whether we are using HTTP or HTTPS on this issue.
Surely with html5 and smart java stuff we get rid of Flash for this?
I have the same issue, noticed after we upgraded to 3.3.2 but not sure if it was related. The zip upload works fine as does normal one by one uploading.
All permissions are as before in the upload directory, the top level gallery directory creates fine and the other upload methods create files properly.
I wonder if Alex can use the WP upload code as that works fine on the systems so far.
Ok, thanks, we all commit school-boy errors even if, as in my case, school-days themselves are obscured by a few too many years.
Thanks for the prompt response, we’ll be back on with Yak soon.
Cheers!
We found a clash with another plugin that essentially slowed the slideshow plugin to a crawl.
The slides were loading and showing all at once before the code started to manipulate the content so they all listed below the slideshow frame. Eventually the slide show would load and work, but it took minutes!
We disabled all other plugins and it started working, then started pulling them back in one by one till it died again, to identify the clashing plugin and replace it with something else. Now all works fine, I suspect there are many potential causes of problems – but the process of plugin isolation is a good place to start.