batteriesInc

Apologies – one post I forgot to update ??

The problem turned out to be an All in one WP Security extra account authorisation check, which hides not in the WP “Users” menu, but inside the All in one “User registration” menu.

In other words, you may not realise a freshly minted user needs an extra step before they are able to access the system and then set themselves up for using Google Authenticator.

Once you work that one out and perform that extra authorisation in All in one, it all works as planned (and very well, I may add, I like the way it is implemented). As a matter of fact, both plugins work rather well together otherwise, as long as you keep that authorisation step in mind. You can also disable that option to allow self-registration, but for the site I’m experimenting with that isn’t an option.

In other words, it was not your plugin, but user error ??

Kind regards, bInc.

I hope nicearma has an answer – I suspect it’ll be using some of the “rewrite” rules that exist but I’ve never used them – better get advice from someone who knows what they’re doing..

Same question as Linda Lee – by using All in one WP Security‘s logon URL changer, this plugin sadly no longer works.

Yep – it was the plugin’s user admin function. Duh. I was looking in the wrong place.

When I disable that function, it all works perfectly. When I enable it, it also works, provided I authorise that users, but inside All in one WP security rather than the site’s normal user admin.

Good, now I just have to add the line ErrorDocument 404 /?page_id=999999 back to the now reconstructed root .htaccess file (so that any attempt to get to the underlying webserver’s 404 page gets bounced back into the WP CMS as well) and I guess we can start adding the weirder stuff to the site ??

As for the function of 2FA, I do understand how it works (I actually do a lot of biometrics based 2FA in other places) but I couldn’t quite find where things meshed.

Thank you both very much for helping out. I’ll mark the thread as “solved”

You lost me slightly there – so if the WP site is set up to generate URLs of the type

https://sitename.com/?page_id=123

you could set up a .htaccess rule that would map a non-existing page to this external page? I presume that doesn’t apply the theme to the page then?

I’m asking this for 2 reasons:

1 – I have a friend who is writing some PHP code which I would love to integrate in a page on my site, and as yet I have absolutely no idea how to do this (but having at least the page accessible would be cool)

2 – I discovered that it was possible to access the raw site 404 page by feeding it a URL in the style of https://sitename.com/blabla.

Adding a statement to the root .htaccess forced that too into the WP site (and theme):

ErrorDocument 404 /?page_id=999999

I presume yours is similar (not a .htaccess specialist myself)?

Hi, thanks for answering, but that’s the one I just switched away from in my battle to get it solved ??

(it was the one I was originally using)

I’ll try again, but I’m not so hopeful now. It appears All in one affects the logon process at a point later than the 2FA plugins, which is where they then clash. Setting up the core admin user always works without any problems, but try adding a new user with 2FA and you see what I mean (maybe I should have made that more clear).

Could I suggest something simple that seems to be a mainstay forum question of practically all WP users?

It would be nice to see some actual control over the meta-data displayed on posts. Worst case it actually exposes the admin name of small site operators. It would be brilliant if this could be configured almost like a header or footer in a word processor document – sequence, content variables so that the site owner has final say over what is on display, not the theme developer.

I see this as part of site configuration data, not something to be left to theme layout.

I may not be a lawyer, but I work in the area of privacy, and the problem with Google is that there is quite a lot of potential of getting yourself into trouble with using their resources.

The problem is that YOU may choose to hand over personally identifiable information, but neither you or Google have the right to decide that for a 3rd party (which is basically everyone who visits your site). You can’t even imply that a visitor gives permission by the act of visiting your site because permission is supposed to be explicit (so not as a consequence of something else) and opt-in..

As a consequence, Google is in the unprecedented and IMHO not so very comfortable position to be the first organisation to have received a letter signed by the regulators of 27 separate countries (yes, 27) that their privacy policy needs improving. Hence that we even worry about the use of Google fonts in WordPress templates..

We are frequently in communication with regulators in various countries and as far as we can tell, 2013 might not be a very pleasant year for Google in Europe..

Hang on – you berate WordPress for tracking and privacy violations and your recommended replacement is Google analytics?

You do realise the irony, no?

I’m using Counterize at the moment, that seems to stay local with its data gathering (having said that, I haven’t stuck an analyser on the traffic yet so it’s “as far as I know” ??

Thnx!