The best way to use variables on all WordPress pages - php

I'm building a custom theme that has a lot of variables that I wish to use throughout.
Example:
$tv = $options['tv'];
$movies = $options['movies'];
$print = $options['print'];
//....and about 50 more.
For this purpose I have been simply placing them all in a file called vars.php and then in header.php of the theme I include it...
require_once('vars.php');
While this does work, it doesn't feel like the best way. I've read on numerous occasions that use global variables (presumably in functions.php) isn't a good idea, but is this true?
But if it's fine to use global variables in functions.php (even lots of them) is this the right way to go about it?:
global $tv;
$tv = $options['tv'];
global $movies
$movies = $options['movies'];
global $print
$print = $options['print'];

The best way for this is to define all the variables explicitly in functions.php or in main plugin file for plugin. I have verified this is the way most popular plugins including akismet use. Specifically you need to do this.
define( MYVAR_TV, $options['tv'] );
define( MYVAR_MOVIES, $options['movies'] );
define( MYVAR_PRINT, $options['print'] );
After these you can just use them whereever you want like
echo MYVAR_TV;
Hope it helps.

It's fine to use global, but it's not encouraged (you can read more here Are global variables in PHP considered bad practice? If so, why?). You may consider Singleton implementation:
<?php
class GlobalVariable {
/**
* #var array
*/
public static $option = [];
}
// You can set the variable using this way
GlobalVariable::$option['movies'] = 1;
// And get the variables using that array
print_r(GlobalVariable::$option);
Hope this can help you.

What about creating a function in functions.php that returns an array of your variables?
Example: $options = get_my_custom_vars();

I'm assuming that you would like global variables, where it makes an array with all your variables. To use it:
$GLOBALS['your-varriable']
Source:
PHP Documentation

I personally like using Acf Options Addon. Altering these and having them translatable via the wpml plugin is useful, too.
These Options will be addable/editable within a "Options Page" in the Backend or as programmed as described in the link.
After initializing the addon via the functions.php
if( function_exists('acf_add_options_page') ) {
acf_add_options_page();
}
simply call these in the template via
<?php the_field('header_title', 'option'); ?>
These examples were taken from the Acf Options Page documentation.
Keep in mind https://www.advancedcustomfields.com/ has to be installed for this to work.

You can implement a custom stream wrapper, too. This way you could access and store data using functions like file_get_contents, file_put_contents, fread, fwrite, etc. Just like reading and writing from a file, or getting info from a remote URL.
Actually there is an example in the PHP manual, using global variables like you ask. But lets pull it from there in order of completeness and adapting it to your use case in WP and examples of use.
<?php
// variable-stream-class.php just this is pulled from the PHP manual
class VariableStream {
var $position;
var $varname;
function stream_open($path, $mode, $options, &$opened_path)
{
$url = parse_url($path);
$this->varname = $url["host"];
$this->position = 0;
return true;
}
function stream_read($count)
{
$ret = substr($GLOBALS[$this->varname], $this->position, $count);
$this->position += strlen($ret);
return $ret;
}
function stream_write($data)
{
$left = substr($GLOBALS[$this->varname], 0, $this->position);
$right = substr($GLOBALS[$this->varname], $this->position + strlen($data));
$GLOBALS[$this->varname] = $left . $data . $right;
$this->position += strlen($data);
return strlen($data);
}
function stream_tell()
{
return $this->position;
}
function stream_eof()
{
return $this->position >= strlen($GLOBALS[$this->varname]);
}
function stream_seek($offset, $whence)
{
switch ($whence) {
case SEEK_SET:
if ($offset < strlen($GLOBALS[$this->varname]) && $offset >= 0) {
$this->position = $offset;
return true;
} else {
return false;
}
break;
case SEEK_CUR:
if ($offset >= 0) {
$this->position += $offset;
return true;
} else {
return false;
}
break;
case SEEK_END:
if (strlen($GLOBALS[$this->varname]) + $offset >= 0) {
$this->position = strlen($GLOBALS[$this->varname]) + $offset;
return true;
} else {
return false;
}
break;
default:
return false;
}
}
function stream_metadata($path, $option, $var)
{
if($option == STREAM_META_TOUCH) {
$url = parse_url($path);
$varname = $url["host"];
if(!isset($GLOBALS[$varname])) {
$GLOBALS[$varname] = '';
}
return true;
}
return false;
}
}
Let's suppose you have a plugin to isolate your functions, being able to deactivate it for debugging and not losing it if you change the active theme. I'd recommend putting something like this in your plugin entrypoint:
<?php
/**
* Plugin Name: Stream Wrapper for global variables
* Plugin URI: https://stackoverflow.com/q/46248656/
* Description: Utility class and functions to enable global data sharing in WordPress
* Author: Jesús E. Franco Martínez and the PHP Documentation Group
* Contributors: tzkmx
* Version: 0.1
* Author URI: https://tzkmx.wordpress.com
*/
require 'variable-stream-class.php';
stream_wrapper_register("var", "VariableStream")
or wp_die("Failed to register protocol", null, ['back_link' => true]);
Then, in your templates or other site plugins you can use the above mentioned functions, or use custom aliases. Let's expand on your request:
// functions.php in your theme or better, in the same plugin.php above
// Using a hook just for frontend in order to get populated
// our variables without require calls in the theme.
add_action('wp_head', 'populate_my_awesome_plugin_options');
function populate_my_awesome_plugin_options() {
// Let's say you get your data from a single get_option call
$options = get_option( 'my_awesome_plugin_options' );
foreach( $options as $key => $value ) {
file_put_contents( 'var://' . $key, $value );
}
}
function pop_get_var( $var_name ) {
return file_get_contents( 'var://' . $var_name );
}
Finally, in the header.php or whatever template file you are going to consume your data, the call is just like this:
<p>TV favorite show: <strong><?= pop_get_var( 'tv' ) ?></strong></p>
<p>Movies I like: <strong><?= pop_get_var( 'movies' ) ?></strong></p>
<p>Impressum: <em><?= pop_get_var( 'print' ) ?></em></p>
I know it may look like a lot of boilerplate at first, but because of separation of concerns, you are not limited only to scalar values like using constants, also your stream wrapper could be an adapter to whatever data store you like and not only in memory or stored in WordPress options table. And using a custom function eases you the hassle of writing such long calls to a singleton class, or calling global wherever you want to access your custom data.
Actually if you read the examples in the PHP manual, you'll find an example of using the wrapper to store an entire text, that you could call with include. There is nothing stopping you from using even serialized data, in example with json_encode/json_decode, and stored with your wrapper, even directly in the database with little effort. There is another example to write/read data from a database with PDO, but is easily ported to use WordPress $wpdb object.

Related

Pass variable to _preprocess_node function for use in node template

I've been racking my brains over this one but I'll do my best to describe the problem as best as possible. I have a custom function written within template.php, with a bunch of conditionals. When a condition is true, I would like to assign a value to a variable, and then pass that variable intro a node preprocess function that allows that variables to be rendered on a node template.
The function containing the condition:
function _mytheme_date_repeat_string($vars) {
$exdate_pos = strpos($rrule['WKST'], 'EXDATE:');
if($exdate_pos > 0) {
$vars['testvar'] = 'abc123';
}
}
The preprocess function that I would like to render the variable in for node template use:
function mytheme_preprocess_node(&$vars, $hook) {
$vars['new_variable'] = $testvar;
}
Intended usage in node.tpl.php:
<?php print $new_variable; ?>
I'm not great with PHP, but I know enough about programming to know that variable scope might be an issue here. What would be the best way to implement this? Any guidance is greatly appreciated.
Thanks,
Mark.
If it is not called, your _mytheme_date_repeat_string() function will never be executed. Preprocess functions (ie. any function starting mytheme_preprocess_, are called automatically by Drupal's theme system.
What you need is either move the code of _mytheme_date_repeat_string() in mytheme_preprocess_node() or refactor it and call it.
function _mytheme_date_repeat_string($rrule) {
$exdate_pos = strpos($rrule['WKST'], 'EXDATE:');
if($exdate_pos > 0) {
return 'abc123';
}
else {
return NULL;
}
}
/**
* Prepares variables for node templates.
*/
function mytheme_preprocess_node(&$variables, $hook) {
// Get $rrule from somewhere
$rrule = ... ;
$testvar = _mytheme_date_repeat_string($rrule);
if ($testvar) {
$variables['new_variable'] = $testvar;
}
}
You code does not show where the $rrule calue comes from. I assume you would get it for $variables['node'].

Wordpress add_rewrite_tag(), add_rewrite_rule(), and post_link()

I am trying to do the following:
Rewrite the URL structure of my WordPress installation so that a language field is in there. E.g. http://www.mydomain.com/lang/
I want to then take the input from /lang/ and use it to display the appropriate content. E.g. if lang is 'en' I will take custom fields in English and display the theme in English.
Here is what I have so far:
<?php
function add_directory_rewrite() {
global $wp_rewrite;
add_rewrite_tag('%lang%', '(.+)');
add_rewrite_rule('^/(.+)/', 'index.php?p=$matches[1]&lang=$matches[2]', 'top');
add_permastruct('lang', '%lang%');
}
add_action( 'init', 'add_directory_rewrite' );
?>
This works as far as getting the language but the problem I am facing is now the_permalink() has "/%lang%/" where /en/ is supposed to be or /fr/ or /de/ or whatever language. To add more detail my permalink structure is /%lang%/%category%/%postname%/ and lets say I have a category called food and a post with the title chicken, the_permalink will generate http://www.mydomain.com/%lang%/food/chicken/
Any idea what I'm doing wrong? Cheers.
You additionally need to add a function that will take the permalink that contains the erroneous '/%lang%/' segment, and replace it with the appropriate default language for the post. Typically you can do this either by the 'pre_post_link' filter, or the 'post_link' filter. If you use the former, you will be creating the permalink from scratch (totally custom urls that use nothing that core WP has to offer). If the latter is use, then you can filter the permalink after WP has done it's magic, but before it is used on the site. Here is an example:
function lou_rewrite_lang_in_permalink($permalink, $post, $leavename) {
// find the default post language via a function you have created to
// determine the default language url. this could be based on the current
// language the user has selected on the frontend, or based on the current
// url, or based on the post itself. it is up to you
$default_post_language = get_default_post_lang($post);
// once you have the default language, it is a simple search and replace
return str_replace('%lang%', $lang, $permalink);
}
add_filter('post_link', 'lou_rewrite_lang_in_permalink', 11, 3);
You don't mention it so I will. With your original solo function, you are gunna have a hard time if it is stand alone. The reason is because, though you have told the rewriter that a new url segment exists, you didn't tell WordPress to expect it as a url param. Thus, even though you have some fancy code to rewrite the url and tell WordPress the fancy lang param, WordPress does not know that it should be looking for it, and thus ignores it. You need to add something like this to rectify that:
function lou_add_lang_query_var($vars) {
// tell WP to expect the lang query_var, which you can then later use
$vars[] = 'lang';
// return the new list of query vars, which includes our lang param
return array_unique($vars);
}
add_filter('query_vars', 'lou_add_lang_query_var', 10, 1);
This will tell the WP() class that it needs to accept the 'lang' instead of just skipping over it. Then later you can do something like this to figure out that the current page sent as it's language:
function lou_somefunction() {
// do stuff
...
// access the $wp object
global $wp;
// determine the language from the query_vars of the current page
$lang = $wp->query_var['lang'];
// do other stuff with $lang
...
}
Hope this helps.
EDIT
First I want to say, this is an absolute travesty that language urls are not natively supported by WordPress. I have honestly never needed to do this, but most of my clients are not international companies, with international needs. I will be submitting something to WordPress in code form to solve this in a later version, but as of now, you will need a plugin like the one I have created below.
So I did a lot of investigation to make this happen. After a short conversation with the questioner, if found that my solution was incomplete. Naturally, I started digging. What seems like it should be an otherwise mediocre task, has turned out to be a VERY-not-mediocre task. The short version is, WordPress simply does not want you to insert extra parts of the url, in the middle or beginning of the url, on every url. You can easily do this with post urls ONLY with the above code, but anything more (pages, attachments, author pages, etc...) you must do something special. You can also add parts to the end of the url (endpoints), but even that is complicated.
I have worked with the WordPress rewriter extensively in the past and present, and I have what is considered Expert knowledge on the topic. Despite that, it still took me 4-5 hours to write something that will allow you to prepend a language indicator to all urls, that can then later be used to determine what language the page should be displayed in, regardless of page type. There is one catch, that I think is acceptable. You must know and specify exactly what language prefixes you want to support. I don't foresee this as a problem for anyone who would make use of this, but none-the-less, it is a limitation, simply because of the way that the rewrite engine works.
At long last, here is a plugin that you can use to accomplish this. I works on a barebone WP install, with a WooTheme as the theme. If you have other third party plugins installed, there is a possibility that this will not work for all their urls, depending on how they added their rewrite rules. In the short term, I will probably be converting this to a plugin for WP, and getting it up on Wordpress.org, but that is several days away, at least. Here is a working prototype of the code in plugin form. Create a new directory in your plugins folder (something like /wp-content/plugins/lou-lang), and then paste this code in a php file inside that folder (something like /wp-content/plugins/lou-lang/lou-lang.php). Then activate the plugin, via your admin dashboard, which will be labeled 'Loushou Language URLs'.
CODE:
<?php (__FILE__ == $_SERVER['SCRIPT_FILENAME']) ? die(header('Location: /')) : null;
/**
* Plugin Name: Loushou Language URLs
* Plugin URI: http://quadshot.com/
* Description: Adding the ability to have language support in your frontend urls.
* Version: 0.1-beta
* Author: Loushou
* Author URI: http://quadshot.com/
*/
class lou_rewrite_takeover {
protected static $add_rules = array();
public static function pre_init() {
// debug
add_action('admin_footer-options-permalink.php', array(__CLASS__, 'qsart_rewrite_debug'));
// add rw tag
add_action('init', array(__CLASS__, 'add_directory_rewrite'));
// rw rule adds
add_filter(is_admin() ? 'setup_theme' : 'do_parse_request', array(__CLASS__, 'do_parse_request'), 0);
add_filter('post_rewrite_rules', array(__CLASS__, 'post_rewrite_rules'));
add_filter('date_rewrite_rules', array(__CLASS__, 'date_rewrite_rules'));
add_filter('root_rewrite_rules', array(__CLASS__, 'root_rewrite_rules'));
add_filter('comments_rewrite_rules', array(__CLASS__, 'comments_rewrite_rules'));
add_filter('search_rewrite_rules', array(__CLASS__, 'search_rewrite_rules'));
add_filter('author_rewrite_rules', array(__CLASS__, 'author_rewrite_rules'));
add_filter('page_rewrite_rules', array(__CLASS__, 'page_rewrite_rules'));
add_filter('rewrite_rules_array', array(__CLASS__, 'final_rules_correction'), PHP_INT_MAX, 1);
// query vars
add_filter('query_vars', array(__CLASS__, 'add_lang_query_var'), 10, 1);
add_filter('request', array(__CLASS__, 'default_language'), 9);
// fix permalinks
$link_filters_needing_rewrite = array(
'post_link',
'post_type_link',
'page_link',
'attachment_link',
'search_link',
'post_type_archive_link',
'year_link',
'month_link',
'day_link',
'feed_link',
'author_link',
'term_link',
'category_feed_link',
'term_feed_link',
'taxonomy_feed_link',
'author_feed_link',
'search_feed_link',
'post_type_archive_feed_link',
);
add_filter('pre_post_link', array(__CLASS__, 'change_permalink_structure'), 10, 3);
foreach ($link_filters_needing_rewrite as $link_filter)
add_filter($link_filter, array(__CLASS__, 'rewrite_lang_in_permalink'), 11, 3);
}
public static function do_parse_request($cur) {
self::get_page_permastruct();
self::get_author_permastruct();
self::correct_extras();
return $cur;
}
public static function get_supported_langs() {
return apply_filters('lou-get-supported-languages', array(
'en',
));
}
public static function add_directory_rewrite() {
global $wp_rewrite;
$supported_languages = self::get_supported_langs();
add_rewrite_tag('%lang%', '('.implode('|', $supported_languages).')');
}
public static function unleadingslashit($str) {
return ltrim($str, '/');
}
public static function final_rules_correction($rules) {
global $wp_rewrite;
$new_rules = array();
$supported_languages = self::get_supported_langs();
$find = implode('|', $supported_languages);
$find_find = '#(?<!\()('.preg_quote($find, '#').')#';
$preg_node = str_replace('%%%', '(\d+)', preg_quote($wp_rewrite->preg_index('%%%'), '#'));
foreach ($rules as $k => $v) {
if (preg_match($find_find, $k)) {
$nk = preg_replace($find_find, '('.$find.')', $k);
$parts = explode('?', $v);
$index = array_shift($parts);
$pv = implode('?', $parts);
$pv = preg_replace_callback('#'.$preg_node.'#', function ($matches) use ($wp_rewrite) {
return $wp_rewrite->preg_index($matches[1]+1);
}, $pv);
$nv = $index.'?lang='.$wp_rewrite->preg_index(1).(!empty($pv) ? '&'.$pv : '');
$new_rules[$nk] = $nv;
} else {
$new_rules[$k] = $v;
}
}
return $new_rules;
}
public static function change_permalink_structure($struct) {
$struct = self::unleadingslashit($struct);
$struct = preg_replace('#^%lang%/?#', '', $struct);
return '/%lang%/'.$struct;
}
public static function extras_rewrite_rules($rules, $struct) {
global $wp_rewrite;
if ( is_array( $struct ) ) {
if ( count( $struct ) == 2 )
$new_rules = $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($struct[0]), $struct[1] );
else
$new_rules = $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($struct['struct']), $struct['ep_mask'], $struct['paged'], $struct['feed'], $struct['forcomments'], $struct['walk_dirs'], $struct['endpoints'] );
} else {
$new_rules = $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($struct) );
}
return $new_rules + $rules;
}
public static function post_rewrite_rules($rules) {
global $wp_rewrite;
// hack to add code for extras type urls (usually created by other plugins)
$func = array(__CLASS__, 'extras_rewrite_rules');
foreach ($wp_rewrite->extra_permastructs as $type => $struct) {
$filter = ($type == 'post_tag' ? 'tag' : $type).'_rewrite_rules';
add_filter($filter, function ($rules) use ($struct, $func) { return call_user_func_array($func, array($rules, $struct)); });
}
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->permalink_structure), EP_PERMALINK ) + $rules;
}
public static function date_rewrite_rules($rules) {
global $wp_rewrite;
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->get_date_permastruct()), EP_DATE) + $rules;
}
public static function root_rewrite_rules($rules) {
global $wp_rewrite;
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->get_date_permastruct()), EP_DATE) + $rules;
}
public static function comments_rewrite_rules($rules) {
global $wp_rewrite;
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->root . $wp_rewrite->comments_base), EP_COMMENTS, false, true, true, false) + $rules;
}
public static function search_rewrite_rules($rules) {
global $wp_rewrite;
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->get_search_permastruct()), EP_SEARCH) + $rules;
}
public static function author_rewrite_rules($rules) {
global $wp_rewrite;
return $wp_rewrite->generate_rewrite_rules( self::change_permalink_structure($wp_rewrite->get_author_permastruct()), EP_AUTHORS) + $rules;
}
public static function page_rewrite_rules($rules) {
global $wp_rewrite;
$page_structure = self::get_page_permastruct();
return $wp_rewrite->generate_rewrite_rules( $page_structure, EP_PAGES, true, true, false, false ) + $rules;
}
protected static function get_page_permastruct() {
global $wp_rewrite;
if (empty($wp_rewrite->permalink_structure)) {
$wp_rewrite->page_structure = '';
return false;
}
$wp_rewrite->page_structure = self::change_permalink_structure($wp_rewrite->root . '%pagename%');
return $wp_rewrite->page_structure;
}
protected static function get_author_permastruct() {
global $wp_rewrite;
if ( empty($wp_rewrite->permalink_structure) ) {
$wp_rewrite->author_structure = '';
return false;
}
$wp_rewrite->author_structure = self::change_permalink_structure($wp_rewrite->front . $wp_rewrite->author_base . '/%author%');
return $wp_rewrite->author_structure;
}
protected static function correct_extras() {
global $wp_rewrite;
foreach ($wp_rewrite->extra_permastructs as $k => $v)
$wp_rewrite->extra_permastructs[$k]['struct'] = self::change_permalink_structure($v['struct']);
}
public static function get_default_post_lang($post) {
return ( $lang = get_query_var('lang') ) ? $lang : 'en';
}
public static function rewrite_lang_in_permalink($permalink, $post=0, $leavename=false) {
// find the default post language via a function you have created to
// determine the default language url. this could be based on the current
// language the user has selected on the frontend, or based on the current
// url, or based on the post itself. it is up to you
$lang = self::get_default_post_lang($post);
// once you have the default language, it is a simple search and replace
return str_replace('%lang%', $lang, $permalink);
}
public static function add_lang_query_var($vars) {
// tell WP to expect the lang query_var, which you can then later use
$vars[] = 'lang';
// return the new list of query vars, which includes our lang param
return array_unique($vars);
}
public static function default_language($vars) {
if (array_diff( array_keys($vars), array('preview', 'page', 'paged', 'cpage') ))
$vars['lang'] = !empty($vars['lang']) ? $vars['lang'] : 'en';
return $vars;
}
public static function qsart_rewrite_debug() {
if (isset($_COOKIE['rwdebug']) && $_COOKIE['rwdebug'] == 1) {
global $wp_rewrite;
echo '<pre style="background-color:#ffffff; font-size:10px;">';
print_r($wp_rewrite->rules);
echo '</pre>';
}
}
}
if (defined('ABSPATH') && function_exists('add_action')) {
lou_rewrite_takeover::pre_init();
}
By default, the only language code supported by this plugin is 'en'. Obviously you need more than just that. Thus, once you have installed the plugin, you can add some code to your <theme>/functions.php file that looks something like this, to add the remainders.
function more_languages($list) {
$my_languages = array(
'de', 'zh', 'bg', 'fr'
);
return array_unique($list + $my_languages);
}
add_filter('lou-get-supported-languages', 'more_languages', 10, 1);
Once you have both installed the plugin and defined your custom languages, then you have one final step. You must save your permalinks. To do this from the admin, go to: Settings -> Permalinks -> Save Changes (button). After all of this, you should be good to go!
Hopefully this helps someone, and hopefully I can block out some time to get this up on wp.org.
The question is old but.. I was working on a lightweight solution for multi-language site and i came across the same problem. There is no easy way to do it with built-in WordPress functions. However (like mentioned by user1254824) there is a really easy trick to achieve it.
You can intercept the $_SERVER['REQUEST_URI'] global var, extract the /lang/ part and remove it before WordPress parsing. WordPress will serve you the regular page, but now you have your lang parameter in a var.
function localization_uri_process() {
global $lang; // then you can access $lang value in your theme's files
if( preg_match("%\A/([a-z]{2})/%", $_SERVER['REQUEST_URI'], $matches) ){
$lang = $matches[1];
$_SERVER['REQUEST_URI'] = preg_replace("%\A/[a-z]{2}/%", '/', $_SERVER['REQUEST_URI'] );
}
else
$lang = 'en'; // your default language
}
add_action( 'plugins_loaded', 'localization_uri_process' );
Then, you can also use filters to automatically rewrite all your links.
PS : The code need to be in a plugin. It won't work in your template php files.
I stumbled across this post while looking for a solution to put a language tag in front of the url path. While the wp_rewrite-solution is pretty much solid it kind of didn't work for my purpose (e.g. not having the language tag in front for the default language etc.).
So I took a closer look at the qTranslate-plugin and after I while I figured out that it uses a very simple and elegant solution:
Basically it does two things:
(Obviously) It changes all the Wordpress generated links (e.g. post_link, post_type_link, page_link etc.) to include the correct language tag in the url.
Instead of manipulating complex rewrite rules to have wordpress accept and correctly handle the language tag, it just hooks into "plugins_loaded" (that's right before Wordpress tries to parse the request) and manipulates $_SERVER['REQUEST_URI'] by cleaning out the language tag.
So if you e.g. call www.example.com/en/myurlpath Wordpress only "sees" www.example.com/myurlpath.
$_SERVER['REQUEST_URI'] = "/en/myurlpath" before the manipulation.
$_SERVER['REQUEST_URI'] = "/myurlpath" after the manipulation.
This way your only "job" is to clean up any urls before Wordpress is parsing them.

PHP static variable, need help counting in a function

I have a function that takes an input variable and outputs a template with the following call:
outputhtml($blue_widget);
outputhtml($red_widget);
outputhtml($green_widget);
And a simplified version of the function:
function outputhtml($type)
{
static $current;
if (isset($current))
{
$current++;
}
else
{
$current = 0;
}
//some logic here to determine template to output
return $widget_template;
}
Now here is my problem. If I call the function in a script three times or more, I want the output to be one way, but if I only call the function twice, then I have some html changes that need to be reflected in the templates that are returned.
So how can I modify this function to determine if there are only two calls for it. I can't go back after the fact and ask "hey function did you only run twice???"
Having trouble getting my head around how I tell a function that it is not going to be used after the second time and the necessary html modifications can be used. How would I go about accomplishing this?
function outputhtml($type)
{
static $current = 0;
$current++;
//some logic here to determine template to output
if ($current === 2) {
// called twice
}
if ($current > 2) {
// called more than twice
}
return $widget_template;
}
That would not be practical using a static $current inside the function; I would suggest using an object to maintain the state instead, like so:
class Something
{
private $current = 0;
function outputhtml($type)
{
// ... whatever
++$this->current;
return $template;
}
function didRunTwice()
{
return $this->current == 2;
}
}
The didRunTwice() method is asking "did you run twice?".
$s = new Something;
$tpl = $s->outputhtml(1);
// some other code here
$tpl2 = $s->outputhtml(2);
// some other code here
if ($s->didRunTwice()) {
// do stuff with $tpl and $tpl2
}
The only way you can find out if a function was only called twice is by putting the test at the end of your code; but perhaps by then the templates are no longer accessible? Can't tell much without seeing more code.

Simple template var replacement, but with a twist

So I'm setting up a system that has a lot of emails, and variable replacement within it, so I'm writing a class to manage some variable replacement for templates stored in the database.
Here's a brief example:
// template is stored in db, so that's how this would get loaded in
$template = "Hello, %customer_name%, thank you for contacting %website_name%";
// The array of replacements is built manually and passed to the class
// with actual values being called from db
$replacements = array('%customer_name%'=>'Bob', '%website_name%'=>'Acme');
$rendered = str_replace(array_keys($replacements), $replacements, $template);
Now, that works well and good for single var replacements, basic stuff. However, there are some places where there should be a for loop, and I'm lost how to implement it.
The idea is there'd be a template like this:
"hello, %customer_name%, thank you for
requesting information on {products}"
Where, {products} would be an array passed to the template, which the is looped over for products requested, with a format like:
Our product %product_name% has a cost
of %product_price%. Learn more at
%product_url%.
So an example rendered version of this would be:
"hello, bob, thank you for requesting
information on:
Our product WidgetA has a cost of $1.
Learn more at example/A
Our product WidgetB has a cost of $2.
Learn more at example/B
Our product WidgetC has a cost of $3.
Learn more at example/C.
What's the best way to accomplish this?
Well, I really dont see the point in a template engine that uses repalcements/regex
PHP Is already a template engine, when you write <?php echo $var?> its just like doing <{$var}> or {$var}
Think of it this way, PHP Already translates <?php echo '<b>hello</b>'?> into <b>hello</b> by its engine, so why make it do everything 2 times over.
The way i would implement a template engine is like so
Firstly create a template class
class Template
{
var $vars = array();
function __set($key,$val)
{
$this->vars[$key] = $val;
}
function __get($key)
{
return isset($this->vars[$key]) ? $this->vars[$key] : false;
}
function output($tpl = false)
{
if($tpl === false)
{
die('No template file selected in Template::output(...)');
}
if(!file_exists(($dir = 'templates/' . $tpl . '.php')))
{
die(sprintf('Tpl file does not exists (%s)',$dir));
}
new TemplateLoader($dir,$this->vars);
return true;
}
}
This is what you use in your login such as index.php, you will set data just like an stdClass just google it if your unsure. and when you run the output command it sends the data and tpl to the next class below.
And then create a standalone class to compile the tpl file within.
class TemplateLoader
{
private $vars = array();
private $_vars = array(); //hold vars set within the tpl file
function __construct($file,$variables)
{
$this->vars = $variables;
//Start the capture;
ob_start();
include $file;
$contents = ob_get_contents();
ob_end_clean(); //Clean it
//Return here if you wish
echo $contents;
}
function __get($key)
{
return isset($this->vars[$key]) ? $this->vars[$key] : (isset($this->_vars[$key]) ? $this->_vars[$key] : false) : false;
}
function __set($key,$val)
{
$this->_vars[$key] = $val;
return true;
}
function bold($key)
{
return '<strong>' . $this->$key . '</string>';
}
}
The reason we keep this seperate is so it has its own space to run in, you just load your tpl file as an include in your constructor so it only can be loaded once, then when the file is included it has access to all the data and methods within TemplateLoader.
Index.php
<?php
require_once 'includes/Template.php';
require_once 'includes/TemplateLoader.php';
$Template = new Template();
$Template->foo = 'somestring';
$Template->bar = array('some' => 'array');
$Template->zed = new stdClass(); // Showing Objects
$Template->output('index'); // loads templates/index.php
?>
Now here we dont really want to mix html with this page because by seperating the php and the view / templates you making sure all your php has completed because when you send html or use html it stops certain aspects of your script from running.
templates/index.php
header
<h1><?php $this->foo;?></h1>
<ul>
<?php foreach($this->bar as $this->_foo):?>
<li><?php echo $this->_foo; ?></li>
<?php endforeach; ?>
</ul>
<p>Testing Objects</p>
<?php $this->sidebar = $this->foo->show_sidebar ? $this->foo->show_sidebar : false;?>
<?php if($this->sidebar):?>
Showing my sidebar.
<?php endif;?>
footer
Now here we can see that were mixing html with php but this is ok because in ehre you should only use basic stuff such as Foreach,For etc. and Variables.
NOTE: IN the TemplateLoader Class you can add a function like..
function bold($key)
{
return '<strong>' . $this->$key . '</string>';
}
This will allow you to increase your actions in your templates so bold,italic,atuoloop,css_secure,stripslashs..
You still have all the normal tools such as stripslashes/htmlentites etc.
Heres a small example of the bold.
$this->bold('foo'); //Returns <strong>somestring</string>
You can add lots of tools into the TempalteLoader class such as inc() to load other tpl files, you can develop a helper system so you can go $this->helpers->jquery->googleSource
If you have any more questions feel free to ask me.
----------
An example of storing in your database.
<?php
if(false != ($data = mysql_query('SELECT * FROM tpl_catch where item_name = \'index\' AND item_save_time > '.time() - 3600 .' LIMIT 1 ORDER BY item_save_time DESC')))
{
if(myslq_num_rows($data) > 0)
{
$row = mysql_fetch_assc($data);
die($row[0]['item_content']);
}else
{
//Compile it with the sample code in first section (index.php)
//Followed by inserting it into the database
then print out the content.
}
}
?>
If you wish to store your tpl files including PHP then that's not a problem, within Template where you passing in the tpl file name just search db instead of the filesystem
$products = array('...');
function parse_products($matches)
{
global $products;
$str = '';
foreach($products as $product) {
$str .= str_replace('%product_name%', $product, $matches[1]); // $matches[1] is whatever is between {products} and {/products}
}
return $str;
}
$str = preg_replace_callback('#\{products}(.*)\{/products}#s', 'parse_products', $str);
The idea is to find string between {products} and {products}, pass it to some function, do whatever you need to do with it, iterating over $products array.
Whatever the function returns replaces whole "{products}[anything here]{/products}".
The input string would look like that:
Requested products: {products}%product_name%{/products}

Output content from wordpress plugin and rewrite rules

I have created a wordpress plugin that has a filter on the_content, looking for a specific tag then outputting the plugin content in place of that tag.
I would now like to use rewrite rules to call the plugin and output the data within the template, but I'm not finding much help.
Can someone provide an example, or some guidance on how to add a rewrite rule using the built in wp methods and calling my methods in the plugin which outputs some content.
Ideally, I would like shop/ to be matched and then pass everything after shop to my dispatch method on my plugin so that I can have shop/category/shirts or shop/product/the-cool-shirt. My dispatch method would handle breaking apart the rest of the url and calling methods accordingly.
This can get rather interesting. I had to do this for a plugin at one point, I don't have it in front of me, so this it out of memory, but the general idea should be correct.
<?php
add_action('init', 'rewrite_rules');
function rewrite_rules() {
global $wp, $wp_rewrite;
$wp_rewrite->add_rule('(widget1|widget2|widget3)/([a-zA-Z0-9_-]{3,50})$', 'index.php?pagename=listing&category=$matches[1]&subcategory=$matches[2]', 'top' );
$wp->add_query_var( 'category' );
$wp->add_query_var( 'subcategory' );
$wp_rewrite->flush_rules();
}
?>
Using regular expressions is a monumental task in itself, I believe I used this site: http://tools.netshiftmedia.com/regexlibrary/ for help.
I also used FakePage plugin to actually display my custom "dynamic" pages, as I called them, but I suppose everything in WP is technically dynamic.
http://scott.sherrillmix.com/blog/blogger/creating-a-better-fake-post-with-a-wordpress-plugin/
Let me know if you need more help.
I did something very similar not long ago, and I did it by cheating.
If you find the built in rewrite rules too complicated or unable to do the job, you may find it easier to catch the request and filter the results. A simplified version:
add_action('parse_request', 'my_parse_request');
function my_parse_request (&$wp) {
$path = $wp->request;
$groups = array();
if (preg_match("%shop/product/([a-zA-Z0-9-]+)%", $path, $groups)) {
$code = $groups[1];
$product = get_product($code); // your own code here
if (isset($product)) {
add_filter('the_posts', 'my_product_filter_posts');
}
}
}
function my_product_filter_posts ($posts) {
ob_start();
echo "stuff goes here"; // your body here
$content = ob_get_contents();
ob_end_clean();
return array(new DummyResult(0, "Product name", $content));
}
To explain:
The action on parse_request is called before the database lookup. Based on the URL, it installs the other actions and filters.
The filter on posts replaces the results of the database lookup with fake results.
DummyResult is a simple class that has the same fields as a post, or just enough of them to get away with it:
class DummyResult {
public $ID;
public $post_title;
public $post_content;
public $post_author;
public $comment_status = "closed";
public $post_status = "publish";
public $ping_status = "closed";
public $post_type = "page";
public $post_date = "";
function __construct ($ID, $title, $content) {
$this->ID = $ID;
$this->post_title = $title;
$this->post_content = $content;
$this->post_author = get_default_author(); // implement this function
}
}
There's a lot of homework left for the reader in the above, but it's an ugly, working approach. You'll probably want to add a filter for template_redirect, to replace the normal page template with a product-specific one. And you may need to adjust the URL regex if you want pretty permalinks.

Categories