Dan Collis-Puro

I pointed this a month back and the devs haven’t fixed it yet. Sigh.

A fix is here.

Thanks. The issue is pretty clear.

WP_PLUGIN_URL is not https:// versus https:// aware. The function plugin_dir_url() is. So, change:

define( 'SOCIABLE_HTTP_PATH' , WP_PLUGIN_URL . '/' . str_replace(basename( __FILE__) , "" , plugin_basename(__FILE__) ) );

to

define( 'SOCIABLE_HTTP_PATH' , plugin_dir_url() . str_replace(basename( __FILE__) , "" , plugin_basename(__FILE__) ) );

and the plugin javascript/css embeds should be https aware and you will no longer have mixed content errors.

It would appear that the linkedin embed is improperly emitting https:// embeds under https, though. It’d be great to either use schemaless URLs or just always use https:// embeds, as including https:// embeds doesn’t generate mixed content errors on an https:// page.

Also, with a recent update to chrome mixed content errors are much more prominent. Again: happy to fix it if you just tell me you’ll accept a patch.

Nevermind, I don’t need the plugin. I fixed this with the new “wpmu_validate_user_signup” hook. This allows superadmins to bypass email rules everywhere and ignores the limited email domain settings entirely. The preg_match() sets the pattern of allowed email addresses.

In a network activated plugin:
[Code moderated as per the Forum Rules. Please use the pastebin]

@dgilmour – What did you turn up for plugins? This change is kicking my butt right now.

Here’s a patch to fix it:

https://pastebin.com/D6RcmVPY

@charliem – I abandoned subscribe2 and wrote my own plugin to handle category level subscriptions.

For one, I wasn’t happy with how subscribe2 looked under the covers (very messy code), for two I wasn’t sure the feature enhancements I was proposing to write would get accepted – so the LAST thing I wanted to do was pour a bunch of effort into a codebase I wasn’t happy with when I wasn’t even sure it’d get accepted by the subscribe2 maintainer. For three, paying extra to send HTML annoyed me. No offense to the plugin author, I know many folks have benefited from subscribe2 and you have a right to make money however you see fit.

You can bulk edit subscription prefs from the user list in my plugin, and I’ve made a bunch of fixes to the Simple Import Users plugin to allow for more intelligent, de-duplicated bulk user imports. I haven’t issued a pull request yet for Boone to merge it, but he’s given a preliminary OK to my changes.

My plugin does not have the concept of “public subscribers” – every user has a real wordpress account. Next up is taking some of the auto account generating / importing code from simple-import-users and merging it into my Category Subscriptions plugins. I would like to say that’ll happen sometime in the next month.

Sorry for the non-answer.

That sounded like I said it with a sneer – sorry. No offense intended.

@bigsite: you must mean something other than APC, because APC works great with an apache backend and it’s a big part of our infrastructure.

I stand by my “simpler is better” assertion. We host around 5 million page views a month on https://blogs.law.harvard.edu with one app server and one DB server because of our nginx proxy cache.

I really don’t trust spawn_fcgi (search for “spawn_fcgi crash”). Plus it doesn’t have enough knobs and buttons when compared to just using an apache backend. If you’ve got nginx caching for you in front of apache, factoring the well known, stable, flexible, highly tunable apache out of the equation seems premature.

This looks much, much more complicated than the solution we’ve been running at blogs.law.harvard.edu for a long time now.

The short version:

Nginx sits in front of apache, caching based on simple regex patterns: instructions and my (very simple) plugin here.

Apache runs wordpress essentially unmodified, except it binds to an internal IP or alternate port. It uses mod_rpaf to see client requests transparently, allowing you to apply ip access controls (LDAP is a biggie for us) at the apache / wordpress level. It knows nothing of the cache, really, except that it should tell the upstream nginx cache to not cache authenticated page requests. We use apc and the apc object cache on the backend wordpress apache with 256meg of shared apc RAM.

That’s pretty much it. nginx handles caching and serving from the cache. There’s no rewriting trickery, nginx handles compression, cache reaping, flood protection and you can easily mix content from other apps via separate proxy rules.

Apache is a great app server, easy to tweak, tons of features and when fronted with a lightweight caching proxy like nginx it’s a killer combo. Once you’ve got nginx caching for you, I just can’t see where factoring apache out of the equation is going to get you much. In our setup, apache pretty much just stitches dynamic PHP together when needed – it’s great at that.

Ah well, different strokes. I’m a big fan of reducing moving parts, though.

Actually, I am a dumbass. I have to add the custom action via add_action() and then wp_schedule_single_event() refers to the action name that I register. Quite elegant, actually, meaning I can use an instance method without issue.

Thanks for the response.

On 1) – I don’t see where I get the ability to manage category subscriptions in that list. I have to click each individual user to do that, I can’t do it in bulk. My proposal is to add a set of checkboxes (or possibly a multiselect when there would be too many categories) to allow for the bulk management of category subscriptions.

2) That was the plan – to give the option to create real user accounts and the subsequent ability to manage category subscriptions.

3) Understandable. I’m not keen on the feature anyway (mail filters anyone?)

Let me describe why these features are needed for us: A department here posts all their administrative updates to a wordpress blog, categorizing them logically. They would like to – each semester – load a list of students / faculty into category subscriptions so they can just post to their administrative blog and know everyone is getting the relevant messages.

So a more flexible bulk editing and import feature would get them 99% of the way there, and I’m tasked with getting it to happen. Ideally, I wouldn’t have to fork my work into a separate plugin given that subscribe2 does most of what we need already.

So – if these features sound like something you’d be willing to accept as a patch to subscribe2, I’m happy to do the work and submit them. If not, I’ll just fork it and/or write my own plugin.

If you’re interested, we should probably talk off-list to discuss how we’ll collaborate.

Thanks! Let me know either way.

–DJCP

Sorry for the slow response – for some reason, I don’t get notification of these posts.

If you look through the docs, it tells you where to put the nginx configs pretty clearly, check out the comments. Basically, the vhost directives go into an included file.

It doesn’t look like the guide you posted is complete – and really, once you’ve got a caching nginx proxy in front of your wordpress, squeezing (say) 10% more out of your backend becomes a lot less important.

Plus we use apache with wordpress for much more than just PHP interpolation – we use it for ldap auth to restrict certain blogs entirely from those without proper credentials, and have an absolute ton of rewrite rules to maintain legacy URLs. It’d be difficult if not impossible to move away from apache on the backend for us.