lesandles

Sorry, I forgot about this ticket.

Besides delete_all_caches(), it may be useful to log changes in the plugin settings and flushing or completely removing endpoints from the cache. Depends on the complexity to implement each one of them I guess, especially when manipulating the cache in batches.

As for which variables to return, it depends on the event I would say. Some “event ID” for sure. Tentative basic list of additional vars:

• flush all caches: user ID
• update plugin settings: user ID
• flush single cache: user ID, cache ID (rationale: the cache data is still present in the DB if more info needs to be queried for logging)
• delete single cache: user ID, endpoint path (rationale: the path is the only remaining data which can be useful for later reviewing)

For batch events, if possible, each flushed/deleted cache entry could trigger the hook.

In case it’s relevant for the implementation: we use simple-history as WP logger. Returning the vars in associative arrays would be useful in this case (docs for reference: https://simple-history.com/docs/logging-api/#adding-context) and in general for flexible custom logging.

• This reply was modified 1 month, 2 weeks ago by lesandles.

Thanks for the quick answer @hjogiupdraftplus. My question was indeed about OTP login without any additional authentication methods.

Best

Many thanks @mialewp and sorry for the late response. It does indeed solve the issue. From looking at the code I didn’t expect it to work with absolute URLs.

I just used the WP_SITEURL const to keep it portable

add_filter('filebird_json_url', function($url){
    return( WP_SITEURL.'/wp-json/filebird/v1');
});

Oh, now I found the thread for the current implementation
https://ww.wp.xz.cn/support/topic/brute-force-login-url-has-changed/

Problem is, it seems to work for the subdir installation (as in that thread), but breaks the subdomain config (as in my case).

Is there a way to fix it for both cases? Add an “advanced option” to chose between home and siteurl when they differ? Or is this an upstream issue?

• This reply was modified 3 years, 8 months ago by lesandles.

@hjogiupdraftplus

This may be unrelated, but I noticed that the preview version of the plugin breaks wp-cli.

Using the official 4.4.12 release I can execute commands that query the DB, like

$ wp plugin list

But using the preview version I get an “Error: not available”.

I just replaced the plugin, didn’t change any settings. If I disable the “Rename Login Page” feature the issue goes away in the preview version.

@hjogiupdraftplus

In the case of the static site as frontend, we build it using the WP_HOME and permalink structure provided by the backend. The resulting frontend URLs match the ones in the “View” link 1:1, so it’s a perfect fit for our use-case.

Another example I’ve worked with is the frontend being served by WP directly on the main domain but the backend hidden behind a subdomain with basic auth on top of it. In this case it’s also important that the WP_SITEURL and WP_HOME aren’t mixed, because everything under the admin area is re-routed by the webserver and doesn’t exist under the main domain.

Hi @hjogiupdraftplus, thanks for the quick answer.

From what I see, you can reproduce the issue too: the backend URL is replaced with the frontend URL. Only that in your case, the frontend can handle the logout.

Our frontend site doesn’t execute any PHP, it is just a static site generated from the data in the backend. I mentioned it briefly on first post but I should have stated it more clearly. We need to keep the frontend URL as WP_HOME for the static site generation to work correctly and to get the correct links when working on the admin area in the backend.

From the WP documentation I understand that this is the right way to do it:
https://developer.ww.wp.xz.cn/reference/functions/home_url/
https://developer.ww.wp.xz.cn/reference/functions/site_url/

Shouldn’t the WP_SITEURL always be used for login/logout?

Thanks @vupdraft. Let me know if I can be of any help.