If you deactivate that plugin, activate TML and then reactivate that plugin, what happens?
Thread Starter
o2rr
(@orosanoff)
Same results, whatever the activation order as soon as both TML/FSQM are activated the back-end goes to a white screen.
Enable debugging to figure out what is the error message.
Hello,
Sorry to dig up this old thread. Actually I am the author of FSQM Pro and I had reported back this issue https://ww.wp.xz.cn/support/topic/fatal-error-when-wp_login_url-is-called-from-admin-backend
If there is anything I can do from my end to make TML work, I would be glad to.
Thanks, Swashata. I have just opened a new thread also, to try and resolve this.
So, somewhere, the FSQM plugin is calling wp_login_url before permalinks are registered (i.e. before the init action has been fired).
@jeff, yes that is correct. It is calling wp_login_url in the admin backend, where libraries for get_permalink aren’t loaded (I am not sure here).
If you need to take a look at the plugin, I would be happy to provide you access to our gitlab. Please let me know your email at {swashata} {at} {ipanelthemes.com}.
jeff at jfarthing dot com.
In your original thread, you mentioned $wp_rewrite being null. At what action was this? Your own admin ajax action?
It is not admin ajax, rather coded directly in my plugin. The flow is something like this:
1. IPT_FSQM_Loader::init_admin_menus is called during plugins_loaded.
2. init_admin_menus instantiates a class IPT_FSQM_Form_Elements_Admin.
3. During instantiation the class IPT_FSQM_Form_Elements_Admin calls wp_login_url.
So, when wp_login_url is called at plugins_loaded it is rendering the error.
Do note that it happens only when is_admin returns true, i.e, in the backend only. When the class IPT_FSQM_Form_Elements_Front calls wp_login_url in the frontend, it works just fine (but the call is at a later stage of plugins_loaded).
WP does not instantiate the $wp_rewrite instance until after plugins_loaded, regardless of whether is_admin() true or not.
That bneing said, I’m not sure of the way around this, other than instantiating $wp_rewrite manually within the plugins_loaded action only for it to be instantiated again when WP core does it.
Very true. So what do you suggest? Instantiating $wp_rewrite is a bad approach. Maybe tml can add the filters after plugins_loaded or maybe I do not call wp_login_url at all. Since calling wp_login_url at plugins_loaded work from core, so I though tml should take care of this.
But WP core knows the URL will always be wp-login.php. It’s an actual file. TML relies on rewrite rules like regular WP pages.
That is correct. The issue is rewrite rules are not instantiated when I am calling wp_login_url. So when TML functions are calling get_permalink to override the output of wp_login_url it is causing a fatal error. Right now, I will find a workaround to fix from FSQM itself, since many of the customers want to use both. But I think, this may cause issues with other functions (trying to call wp_login_url directly from a plugin file rather than some hook).
Bdw, If I call home_url( 'wp-login.php' ) instead of wp_login_url then the system works.
So I implemented this system: add_query_arg( 'redirect_to', '_self_', ( $wp_rewrite ? wp_login_url() : home_url( 'wp-login.php' ) ) )
