Getting user info as early as possible.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting user info as early as possible.

Jamie Talbot
Hi,

Having get_currentuserinfo() as pluggable is nice, but what if I actually want to get the current
user info during plugin setup, without redefining it myself?  The existing function is good for
my purpose, but I need to get current user info before the 'locale' filter is applied for the first
time.  This can potentially occur in another plugin's call load_plugin_textdomain, for example in a
constructor, before pluggable_functions.php is included.

I could alternatively add the locale filter in later, and set it to a really low priority so it runs
last, but get_locale only runs filtered once, after which time it just returns the existing
locale...  I put up a ticket for this a while ago[1], thinking it was only a small issue, but it has
since become pretty important to me.

[1] http://trac.wordpress.org/ticket/2383

Cheers,

Jamie.

--
http://jamietalbot.com
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Getting user info as early as possible.

Andy Skelton
On 3/17/06, Jamie Talbot <[hidden email]> wrote:
> Hi,
>
> Having get_currentuserinfo() as pluggable is nice, but what if I actually want to get the current
> user info during plugin setup, without redefining it myself?

This brings up an important point, one which will be repeated until
the end of time.

Plugin loading time is not the time to execute code. It is the time to
define functions and add actions/filters for later execution.

The reason for this is simple and it will not be argued here: the
program is not completely loaded until after the plugins and pluggable
functions are loaded. Refer to wp-settings.php to see which hooks
happen where.

Most plugins shouldn't actually do anything until init or later.

There are exceptions.

Andy
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Getting user info as early as possible.

Ryan Boren
In reply to this post by Jamie Talbot
Jamie Talbot wrote:
> I could alternatively add the locale filter in later, and set it to a really low priority so it runs
> last, but get_locale only runs filtered once, after which time it just returns the existing
> locale...  I put up a ticket for this a while ago[1], thinking it was only a small issue, but it has
> since become pretty important to me.
>
> [1] http://trac.wordpress.org/ticket/2383

Offhand, that looks okay to me.  I'd like to run it by the wp-polyglots
list before commit though.

Ryan
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Getting user info as early as possible.

Jamie Talbot
In reply to this post by Andy Skelton
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Andy Skelton wrote:
> On 3/17/06, Jamie Talbot <[hidden email]> wrote:
> Plugin loading time is not the time to execute code. It is the time to
> define functions and add actions/filters for later execution.

> The reason for this is simple and it will not be argued here: the
> program is not completely loaded until after the plugins and pluggable
> functions are loaded.

Sure, I can appreciate the logic of that and I agree in the vast majority of cases.

> Refer to wp-settings.php to see which hooks
> happen where.

Yeah, I've almost memorised it I think!  Red Alt's X-Ref is a fantastic programming aid which I'm
referring to constantly.  My question was kind of rhetorical - you can't do guarantee the order in
which plugins are registered, can you? (What would people's thoughts be on allowing this?)

> Most plugins shouldn't actually do anything until init or later.
>
> There are exceptions.

In this case however, I'm dynamically setting the locale based on the current user's preference.
Because the locale filter is only executed the first time get_locale is called, other localised
plugins can potentially cause get_locale to run unfiltered before I register it.

In fact, allowing get_locale to re-run locale filters would allow me to register the filter in the
setup and then cause the locale to be re-evaluated when my own load_plugin_textdomain call runs in
init.  This would be after pluggable_functions has loaded and all would be well.  Of course, there
is the potential that a plugin's high priority locale filter could trump another's, but at least
then it's not a lottery based on which one is registered first.

Cheers,

Jamie.

- --
http://jamietalbot.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEG9cdrovxfShShFARArecAJ4x61RY6880Ecy3ifdCnsCdWPvtNACgj84S
agd7j/VmuCmc1duO159hRYQ=
=hCWL
-----END PGP SIGNATURE-----
_______________________________________________
wp-hackers mailing list
[hidden email]
http://lists.automattic.com/mailman/listinfo/wp-hackers