Support Forum
Tricky. It depends how early you need to know this. When plugins are initialised we do not yet know if the current request is for a forum page so anything that needs that will have to tie it into a hook for when we do know.
So - with the possible exception of doing a sledgehammer check on the http request url - it has to wait. If you can tell me at what stage in the whole process you need to know the answer I can probably advise you as to when and how to make the check.
YELLOW
SWORDFISH
|
I just came back to say I think I figured it out. Sort of.
This is a SP plugin that will add a sidebar widget to a WP theme. My goal was only have the widget visible in the sidebar on forum pages.
I did get the $ISFORUM condition to work within the widget function that makes the output. So this can work.
I was hoping however to use $ISFORUM (or something else) to only add_action('widgets_init', 'my_test_sp_widget', 5) when actually on a forum page to save a few processor cycles.
Understood.
This question has actually prompted me to write a task report to place a few filters and actions at appropriate places in the startup sequence. We have a few in place but not enough.
As always - if you identify a need then shout. Actually - put a filter/action into the core code to see if it does what you want and if so then shout and we will make it legitimate.
if you look at the file sp-control.php (the actual plugin file itself) then at the bottom you will see how early we are able to set the $ISFORUM global. This function is itself called from the 'wp' action.
YELLOW
SWORDFISH
|
Thanks for the info and advice.
My little workaround works, but unfortunately means the widget is created, but not outputting anything if not on forum page. So for WP themes that have built in widgets until the user adds them, the theme see's my empty widget and doesn't output the built ins... so sidebar is blank. Not so pretty lol
I'll play later and see what I come up with or can suggest. For now have "real life" to log in to for a while.
dont forget about the function
sp_is_forumpage()
which returns true if on forum page... still has the limitations of when its available for use like $ISFORUM... great for widgets and template tags, but not good for the plugin main code...
Please remember that when writing a plugin, you want to do as little as possible in the main plugin file... that is, the one we load up very early... this is just like wp loading of plugins... you really want to base as much code as possible in the plugin off of actions and filters so you know things are set up...
we do have some actions fired as we progress through the startup process... such as sph_plugins_loaded, sph_head_start or sph_setup_forum... but as Andy says, we could use with a few more so plugins can no more of the startup process...
will help a lot when we get the codex fired up and put up a hook reference...
Visit Cruise Talk Central and Mr Papa's World
Sheesh! I read this a few days ago and meant to acknowledge it a bit later as time allowed... I forgot [Image Can Not Be Found]
I was needing to know if a page was a forum page no later then the "init" or "widgets_init" hooks but couldn't figure out a clean way. SP's determines that by the "wp" hook and I couldn't get "is_page(sp_get_option('sfpage'))" to work any earlier.
So I'm doing something like this for now:
if (strpos($_SERVER['REQUEST_URI'], sp_get_option('sfslug'), 0)){ add_action('init', 'my_sp_widget', 1); }
I may attempt to use sp_get_option('sfpermalink') for reliability when I get further along with polishing.
I have been using tons of filters (love this version!) that are added and later removed with SPv5's new hooks. sph_HeaderBegin and sph_HeaderEnd have proven perfectly placed for this approach [Image Can Not Be Found]
The plugin brainstorm I'm playing with is a sidebar widget that only appears on a forum page that has a sidebar. When on a forum page, the idea is to display the admin bar there, and all labels, buttons and the avatar within the widget to free up space. Then the widget will uses filters and voodoo to remove all the above mentioned items from the SP theme head so they aren't duplicated.
So far so good, although ugly since it needs styled, and the javascript is goofy now since locations have changed. But I'm chipping away at it as time allows.
Our problem is hitting a balance about what and when things are loaded - and it is very delicate balance regarding loading the right support and data that is needed at any given time.
I don't believe we can reliably bring that forward at the moment but I would welcome you taking a look to see if you can figure getting the information earlier in the sequence. Every time I start to make changes in that area I end up with a headache!
YELLOW
SWORDFISH
|
Yellow Swordfish said:
I would welcome you taking a look to see if you can figure getting the information earlier in the sequence.
But that's just it. Using WP's methods of determining what the page ID is, doesn't seem to work any earlier either. "is_page()" for example according to the codex should work on or after the init hook. But either that's incorrect, or I'm doing something wrong as I can't detect until a hook or two before the "wp" hook. I can't remember exactly which one it was.
So the best I can come up with is checking the $_SERVER['REQUEST_URI'] with the forum slug, or permalink, or against a hardcoded value. And a hardcoded value wouldn't make it portable.
just a word of warning there... request_uri is not required by user agents and is easily spoofed...so be careful what you do with it...
Visit Cruise Talk Central and Mr Papa's World
1 Guest(s)