Category: Managed Services

Here’s a WordPress plugin that will allow you to feature a single item in a widget, until you tell it to automatically expire.

As taken from the readme file:

Description

Simple widget to display (promote) a specific post/page. Provides a list of from all public post types to choose an entry to promote until a specified date. When this “promotion” expires, you can either display a static message or use another post/page instead.

Installation

1. Upload the plugin folder to your plugins directory /content/plugins/ directory
2. Activate the plugin through the ‘Plugins’ menu in WordPress
3. Add the Widget “Promoted Content” to a sidebar

Frequently Asked Questions

What are the options?

• Title: The displayed widget title – leaving it blank will use the post title (if you override the default, see Hooks)
• Feature Expires: until what date (YYYY-MM-DD) to show the promoted post; after which fall back to the default
• Feature Post: choose from the dropdown of public post types to promote
• Default: display this entry instead after the expiration
• Trim summary to: if no excerpt is provided, shorten the post content to this number of words

Note that you can select the most recent post from the dropdown options.

How can I change the defaults?

If you don’t specify certain options, the widget will use builtin defaults. Override these with the following hook:
[php]
add_filter(‘abt_promo_post_defaults’, ‘YOUR_HOOK’);
[/php]

where YOUR_HOOK is a function that takes an array and returns the following settings:

[php]
function promo_widget_defaults($settings){
return array(
#’title’ => ‘Latest From MY SITE’, // disable to use post title
‘display’ => ‘Check out our new video! Credit goes to … <p><a class=”archive” href=”/category/news”>News Archive</a></p>’,
‘url’ => ‘#’,
‘image’ => ‘<img src=”‘ . get_stylesheet_directory_uri() . ‘/images/g_video.jpg” alt=”Latest from MY SITE”>’,
);
}
[/php]

What else can I use?

Two static methods are available for “embedding” the widget in code – basically just the internal processing used by the widget function.

abtcore_feature_widget::display_promo($args, $before_title, $after_title) 

which uses the following

abtcore_feature_widget::get_promo($args) 

to get either the promoted post or the default. $args will contain an array of the widget options (title, expire, promo, default, trim).

Function get_promo will return an array of (title, display, url, and image) to display_promo where it gets combined with the defaults from the hook to output the widget HTML.

If you run PHP locally on a Windows machine, you’re probably using XAMPP.  By default, you put all your files in the xampp directory (htdocs) to make things work.  However, if want a different directory structure (i.e. under “My Documents”) you can set up domain or subdirectory aliases.

The following steps are the mostly-complete guide to setting up XAMPP: set alternate folders/domains/subdirectories, enable “missing” extensions, and let it play nicely with VisualStudio’s local IIS.

1. Download zip version
2. run setup_xampp.bat to fix directories
3. to access your local dev like `http://ALIAS.localhost:81/whatever.php`, in apacheconfextrahttpd-vhosts.conf add your custom directories like: (note port 81 from step 7)
   [php htmlscript=”true”]

   <VirtualHost *:81>
   ServerAdmin YOUR@EMAIL.COM
   DocumentRoot “/Relative/Path/To/LocalFiles”
   ServerName ALIAS.localhost
   ServerAlias www.ALIAS.localhost
   ErrorLog “logs/ALIAS.localhost-error.log”
   CustomLog “logs/ALIAS.localhost-access.log” combined

   <Directory “/Relative/Path/To/LocalFiles”>
   Options Indexes FollowSymLinks
   AllowOverride All
   Order allow,deny
   Allow from all
   </Directory>
   </VirtualHost>
   [/php]

    

4. Update your hosts file (C:WindowsSystem32driversetchosts) accordingly: 127.0.0.1 ALIAS.localhost
   (added bonus: wildcards in hosts file (untested))
5. OR, instead of #3 and #4, configure subdirectory aliases in xamppapacheconfextrahttpd-userdir.conf, which will let you access your local dev like `http://localhost/ALIAS/whatever.php`
   [php htmlscript=”true”]
   <IfModule alias_module>
   # ===== Description of the following
   Alias /ALIAS “/Relative/Path/To/LocalFiles”
   # Access control, etc
   <Directory “/Relative/Path/To/LocalFiles”>
   AllowOverride All
   Options Indexes FollowSymLinks
   Order allow,deny
   Allow from all
   </Directory>
   </IfModule>
   [/php]
6. Allow “missing” extensions by uncommenting dll line in xamppphpphp.ini
7. If also have IIS (VisualStudio) on same computer, you’ll need to change the ports (you can use other numbers)
   1. in xamppapacheconfhttpd.conf — change `Listen *:80` to `Listen: *.81`, `ServerName localhost:80` to `ServerName localhost:81`
   2. in xamppapacheconfextrahttpd-ssl.conf — change `Listen 443` to `Listen 442`
   3. ignore the message in xampp-control that says it started on port 80 (that’s hardcoded)

WordPress recently added some “helpful” error messages warning you when you’re not doing certain things correctly. Specifically, adding scripts and/or styles incorrectly using the wp_enqueue_* function.

However, even though it appears they tell you where things went wrong (via trigger_error), it actually just points you to the _doing_it_wrong function.

Fortunately, those hook-crazy developers threw us a bone in that function:
[php]
do_action( ‘doing_it_wrong_run’, $function, $message, $version );
//
[/php]

Now we can figure out the offender ourselves with a hook:
[php highlight=”13″]
/**
* Because new WP 3.3 “doing it wrong” warnings don’t really tell you where you screwed up…
* @param string $function The function that was called.
* @param string $message A message explaining what has been done incorrectly.
* @param string $version The version of WordPress where the message was added.
*/
function abt_doing_it_wrong_helper($function, $message, $version){
$before = <<<EOD
<strong>$function:</strong> v$version
EOD;
debug_whereat(3, 5, $before);
}
add_action( ‘doing_it_wrong_run’, ‘abt_doing_it_wrong_helper’, 10, 3 );
//
[/php]

And the helper function for printing debug_backtrace (use your own flavor):
[php]
/**
* Pretty-print debug_backtrace()
* @param int $limit {optional} when to stop printing – how many recursions up/down
* @param int $skip {optional} when to start printing – how many calls to skip over
* @param string $before {optional} extra html to print before the table, inside debug container
* @param string $after {optional} extra html to print before the table, inside debug container
* */
function debug_whereat($limit = false, $skip = false, $before = ”, $after = ”){
static $debug_whereat_counter; if( !$debug_whereat_counter) $debug_whereat_counter = 0;
$uid = $debug_whereat_counter++;
?>
<div class=”debug trace”>
<?php echo $before; ?>
<table>
<thead><tr>
<th id=”th-index-<?=$uid?>”><i>nth</i></th>
<th id=”th-line-<?=$uid?>”>Line</th>
<th id=”th-file-<?=$uid?>”>File</th>
<th id=”th-method-<?=$uid?>”>Method</th>
</tr></thead>
<tbody>
<?php

$backtrace = debug_backtrace();
if( $skip ) $backtrace = array_slice($backtrace, $skip);

foreach($backtrace as $index => $trace){
//force quit
if($limit !== false && $index == $limit){
?>
<tr><td colspan=”4″><em>—– FORCE STOP RECURSION —–</em></td></tr>
<?php
break;
}

?>
<tr class=”trace-item”>
<th headers=”th-index-<?=$uid?>”><?=$index?></th>
<td headers=”th-line-<?=$uid?>” class=”line”><?=$trace[‘line’]?></td>
<td headers=”th-file-<?=$uid?>” class=”file”><?=$trace[‘file’]?></td>
<td headers=”th-method-<?=$uid?>” class=”method”>
<code><?=$trace[‘function’]?></code>
<?php
if(!empty($trace[‘args’])){
echo ‘<br />’;
while(!empty($trace[‘args’])){
?> {<i><?php print_r(array_shift($trace[‘args’]) ); ?></i>} <?php
}// while !empty $trace[‘args’]
}
?>
</td>
</tr>
<?php
}
?>
</tbody></table><?php echo $after; ?></div>
<?php

}// function debug_whereat
[/php]

If you find yourself scratching your head over why your shortcodes have stopped working in WordPress 3.3, we’ve discovered a funny quirk. Granted, this fix may actually be the right way to call all shortcodes, but previously we’ve been able to lazily call it directly from our functions.php file and no one cared. But, now it seems, with the upgrade, that WordPress 3.3 does care. It requires your add_shortcode() function to be called within their init() hook. Calling it directly after your newly declared shortcode function won’t work anymore.

The lazy method we got away with before:

[php]
function abtcore_shortcode_button( $atts, $content = null ) {
extract( shortcode_atts( array(
‘color’ => ‘blue’
), $atts ) );
return ‘<p>’ . $content . ‘</p>’;
}

add_shortcode( ‘button’, ‘abtcore_shortcode_button’ );
[/php]

The better way that is now required by WordPress 3.3:

[php highlight=”7″]
function abtcore_shortcode_button( $atts, $content = null ) {
extract( shortcode_atts( array(
‘color’ => ‘blue’
), $atts ) );
return ‘<p>’ . $content . ‘</p>’;
}
add_action(‘init’, ‘abtcore_register_my_shortcodes’, 100);
function abtcore_register_my_shortcodes() {
add_shortcode( ‘button’, ‘abtcore_shortcode_button’ );
}
[/php]

Notice the add_action() call on the ‘init’ on line 7. This will properly register your shortcode function when WordPress initiates.

I hope this helps.