Helen Hou-Sandi

Hi @hrizvi – while I imagine you could probably use Restricted Site Access as a part of a solution like that, it doesn’t handle all of that on its own. You would need to find a solution for creating and managing those codes, as well as a place to input them, which is a lot of work basically recreating users and logins, just without usernames.

Hi there – is anything broken in WordPress itself or are you looking for a “tested up to” bump? I can certainly get things re-tested and update that version number but if you’re experiencing a specific bug I’d like to look at that too.

Hi there! I’m guessing you don’t want to try the plugin again, but if there’s any other information you can give me about your setup (for instance, if rewrites were enabled) so I can try to reproduce and see about any necessary fixes, that would be very helpful! It does not actually write a file to the filesystem, so if you were looking for one in a file browser, you would not have seen it.

That’s very odd, I agree that none of those plugins should have anything to do with caching. Perhaps it’s host-level caching? I haven’t come across this bug and we use it across a significant number of projects, so any information you might be able to offer up so we can try to reproduce it reliably and see if there’s anything that can be fixed in the plugin to prevent it would be very helpful.

When you say it wouldn’t let you add your own IP, what do you mean? Did nothing happen when you clicked the button, did it not save, or something else?

Hi @brian-homer – I’m sorry you’re having a bad experience here. Do you by any chance have any other plugins activated, in particular anything around page caching?

Hi everyone – this is a long-standing issue that has a lot to do with how that “simple” message is output by WordPress and what’s expected and allowed while still being secure. I do not recall it working in the past but can’t say for sure, it’s been a long time using it ?? This is being tracked as an issue in GitHub; however, I do not currently have a timeline for shipping changes to this functionality and do not know whether we’d go the direction of allowing more tags or removing the misleading tags from the editor toolbar. Sorry for the inconvenience.

• This reply was modified 5 years, 10 months ago by Helen Hou-Sandi. Reason: clarify first sentence and try to avoid sounding condescending or sarcastic

It is possible to do this via code; however, it’s not something that’s targeted for the admin interface. Totally understand why you’d want to do this, this plugin just has a relatively narrow focus at the moment.

Hi there! We’ve formally bumped the tested-up-to version but yes, it works great!

@alexclassroom Yes, I do know that the string can change eventually and I really do appreciate your detailed attention here. In this specific case, should that core string change, I would prefer to know so we can change the plugin to match whatever core is using to say “Save Changes” (or if it moves away from save buttons entirely).

Hi there – I’m a little confused about this as inc/admin.php is only 232 lines long. That said, the “Save Changes” string was purposefully left without domain because it’s an existing string in the core admin context.

It works for subdomain networks, but not path-based ones, as the ads.txt spec requires that it be served from the root of the (sub)domain.

I think what you’re probably looking for is a full-featured membership plugin. Restricted Site Access is geared toward locking down full sites, for instance when you’re staging a new site and don’t want the general public to see it yet but want to be able to share a preview with others.

I’m sure that is possible but you will want to look for user registration plugins to help with that.

WP CLI requires PHP 5.4 or higher so while the rest of this plugin still retains PHP 5.2 compat for the moment, I don’t see that CLI support needs to be written that way. I’m sorry that Restricted Site Access’s CLI integration happens to be the one that breaks your site – perhaps there’s a way to disable the plugin just during CLI requests? I fear your environment will run into more problems eventually though, given WP CLI’s minimum requirements.

It is possible right now on the code level, there’s an example on GitHub: https://github.com/10up/restricted-site-access/pull/8#issuecomment-355186577

I am open to discussing a UI option for this but my current thought is that it defeats the purpose of the plugin, as opening up the REST API actually does make your site essentially available and possibly in ways that a less technical user might not expect nor appreciate when they go to change the option because another app is asking for unauthenticated access.

In the case of your app, I would suggest you look into authenticating requests, not in a way that requires specific user registration, but using tokens or similar.