Availability of the post object in theme.php or plugin?

[Rienk Doetjes]

Briefly

How can I get access to the post object while setting up a theme or plugin hook?

---

Extensive Explanation

I have a rather complex website design in which I use individual stylesheets and javascript files (even appcache manifests and dynamically added homescreen icons in some future cases) to create single, unique pages. For this to work I have created a plugin that inserts a textarea in the entry editor where I add my files, one per line. The script assumes that I've generated a folder named as the slug using the Habari Silo (I might automate this, one day), and that if the file is not given as an absolute url, it must just prepend "Site::get_url('habari') . '/user/files/' . $post->slug . '/' . $filename".

I'm currently also implementing an external file editor (though with login through Habari) which is nearing completion.

Long story short... currently, I just check $post->info->[name of the custom textarea] and loop through all the entries in my main theme template files. I wanted to remove this and add everything to either the theme file or a plugin (I have to run both, since extensive modification of the atom feed, which my site requires, must use the plugin class). For one, I cannot use Stacks (not enough control over what is and what isn't added to the header or footer, and some other issues) so I'm trying to set my own variables. I have tried many different things, but my problem is that I seem to be unable to either pass $post->info->[custom field] and $post->slug to the theme/plugin extension, or grant the function access to these vars. Adding $post to the function params, setting $post global, or even explicitly passing the values to a function. It just doesn't work for me.

Does anyone have an idea how to get around this problem?

---

Last Thing I Tried

class StereoDax extends Theme

{

/**

* Adding my own functions because I'm not happy with

* all the stuff Habari automagically adds to the header/footer

* Not using Stacks because regular vars give me more control

* with less code (including adding appcache manifests).

*/

public function theme_files( $post ) // tried $theme, etc... also tried setting global

{

// Create the new variables

$this->header = '';

$this->footer = '';

$this->head   = '';

// Get all the files from the custom post element

$files = preg_split('/(\r?\n)+/', $post->info->custom_files);

 

// Split the files and check if they're local

foreach($files as $f)

{

if (strpos($f, '://') === false)

{

$f = Site::get_url('habari') . '/user/files/' . $post->slug . '/' . $f;

}

// CSS Files

if(stripos($f,'.css') !== false)

{

$this->header .= "\t<link rel=\"stylesheet\" type=\"text/css\" media=\"all\" href=\"$f\" />\n";

}

 

// Appcache manifest

else if(stripos($f,'.appcache') !== false)

{

$this->head = " manifest=\"$f\"";

}

   

// JS (assumed, if not CSS or appcache)

else

{

$this->footer .= "\t<script type=\"text/javascript\" src=\"$f\"></script>\n";

}

}

}

}

[Konzertheld]

Long question simple answer: You should be able to access the current post(s) everywhere in your theme class with $this->post or $this->posts. $this->post will be the first post for multiple pages. $theme->post should also work outside of the class in your templates.

[Chris Meller]

I would simply implement add_template_vars in my theme and do all the work there (ala [1]). In any event, your theme is extending the core Theme class, so you have access to all the other theme properties in any method of the class, meaning the posts being displayed are always available [2].

I would also highly encourage using Stacks for this. Keep in mind that that's how other plugins add things as well, so you're potentially breaking things by getting rid of them. I find it greatly helps clean up everything - no more manual string concatenation, no quote escaping hell, etc. You can see in the Sparse example that I add a ton of stack items with dependencies at the top. It's awesome.

You can remove anything you like that is added by default with Stack::remove( 'template_atom', 'app' ), for instance. Or remove it all by omitting the second parameter. The defaults are added in Theme::theme_header and Theme::theme_footer [3].

[1]: https://github.com/chrismeller/sparse/blob/master/theme.php#L45

[2]: https://github.com/chrismeller/sparse/blob/master/theme.php#L61

[3]: https://github.com/habari/system/blob/master/classes/theme.php#L620

--
--
To post to this group, send email to habari...@googlegroups.com
To unsubscribe from this group, send email to habari-users...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/habari-users
---
You received this message because you are subscribed to the Google Groups "habari-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to habari-users...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Rienk Doetjes]

See, this is why I love Habari! It's lightweight, even with a zillion classes added through files, and you can tinker with it anyway you want. That... and you get helpful responses from others in the Habari Groups. Thanks to both of you! I knew it was going to be something simple!

I wish I could contribute to Habari, too, but as you can tell, my PHP skills have been frozen in time for the last few years: never really got with the transfer from function-oriented to Object/Class oriented programming in the later versions of php4 and now in php5. I'm learning though, so maybe one day I'll have enough skills to contribute. For now, I just keep telling everyone to ditch WordPress and go with Habari.

Again, thanks!