Add custom javascript and CSS to WordPress admin

A conceptual example of how you could add css or javascript to your ”edit post” page in the WordPress dashboard.
I included an example of how you can ”send parameters” to the javascript file.

<?php
class MyClass {
	function admin_init() {
		wp_register_style( 'my_css', get_stylesheet_directory_uri() . 
			'/css/my_class.css' );
		wp_register_script( 'my_js', get_stylesheet_directory_uri() . 
			'/js/my_class.js', 'jquery', '1.0.6', true );
	}
 
	function enqueue_css() {
		wp_enqueue_style( 'my_css' );
	}
 
	function enqueue_js() {
		wp_enqueue_script( 'my_js' );
 
		// Add current post id as a javascript variable.
		global $post;
		$current_id = empty( $post ) ? '' : $post->ID;
		$my_params = array(
		  'postid' => $current_id,
		);
		wp_localize_script( 'my_js', 'MyParams', $my_params );
	}
}
 
if ( class_exists( "MyClass" ) ) 
	$my_class = new MyClass();
else
	error_log( "MyClass missing" );
 
add_action( 'admin_init', array(&$my_class, 'admin_init') );
add_action( 'admin_print_styles-post.php', array(&$my_class, 'enqueue_css') );
add_action( 'admin_print_scripts-post.php', array(&$my_class, 'enqueue_js') );

TextMate snippet for PRG-pattern in WordPress

This is free TextMate snippet day here at jonasnordstrom.se. Enjoy, and please let me know if there are any errors.


From wikipedia:

Post/Redirect/Get (PRG) is a web development design pattern that prevents 
some duplicate form submissions, creating a more intuitive interface for 
user agents (users). PRG implements bookmarks and the refresh button in a 
predictable way that does not create duplicate form submissions. 

image from wikipedia

PRG is the pattern to aim for when creating functionality for the WordPress backend (wp-admin). But it’s a pain to keep track of which hooks to use, how the redirection works and stuff like that.
Here’s a TextMate snippet that hopefully will be of some help.

Note: I will add nonce and update this post, just wanted to save the code somewhere when it was in front of me, you know how it is …

<?php 
function ${1:function_name}_page() {

    if ( isset( $POST['action'] ) && !current_user_can( '${2:edit_page}' ) ) {
        return;
    } ?>

    <form action="edit.php" method="post">
        <input type="hidden" name="page" value="${1/\_/-/}-page" />
        <input type="hidden" name="action" value="${3:action-name}" />
        <input type="submit" value="${4:Button Text}" />
    </form>
    <?php
}
function $1() {
    if ( isset(\$_POST['action']) && \$_POST['action'] == '$3') {
        // Do your magic here
        $0;

        \$location = admin_url() . "edit.php?page=" . $_POST['page'] . "&feedback=${5:Feedback+here}";

        \$status = 302;
        wp_redirect( \$location, \$status );
        exit;
    }
}
function add_$1_page() {
    add_management_page( '${6:Page Title}', '${7:Menu Title}', '${8:manage_options}', 
                  '${9:menu-slug}', '${1:function_name}_page' );
}

add_action( 'admin_init', '$1' );
add_action( 'admin_menu', 'add_$1_page' );

wpdb->delete() i WordPress 3.4

En av nyheterna i WordPress 3.4 är att metoden delete har tillkommit till wpdb-klassen. Tidigare fanns av någon anledning bara insert och update.
Enkelt exempel på hur den kan användas:
Vad jag vet finns det ingen inbyggd funktion för att ta bort alla förekomster av ett custom field, före WordPress 3.4 var man tvungen att göra en query direkt i databasen för att få till den funktionaliteten.

  function delete_post_meta_for_all( $meta_key ) {  
     global $wpdb; 
     return $wpdb->query( 
        $wpdb->prepare( "DELETE FROM $wpdb->postmeta WHERE meta_key = %s ",
           $meta_key ) ); 
  } 

Tyvärr måste man fortfarande göra något liknande, men syntaxen är lite mer ”WordPress”:

function delete_post_meta_for_all( $meta_key ) { 
   global $wpdb; 
   $result = $wpdb->delete( "$wpdb->postmeta" , 
      array( "meta_key" => $meta_key) , array( '%s' ) ); 
}

Syntax:

function delete( $table, $where, $where_format = null )
$table: table name
$where: A named array of WHERE clauses (in column => value pairs). Multiple clauses will be joined with ANDs. Both $where columns and $where values should be ”raw”.
$where_format Optional: An array of formats to be mapped to each of the values in $where. If string, that format will be used for all of the items in $where. A format is one of ‘%d’, ‘%f’, ‘%s’ (integer, float, string). If omitted, all values in $where will be treated as strings unless otherwise specified in wpdb::$field_types.
return int|false The number of rows updated, or false on error.

Mer info här

Snabbare WordPress på egen server

Sen jag bytte till Tilaa, där jag sköter webbserver och databas själv, har svarstiderna förbättrats avsevärt.

Pingdom rapporterar:

 

Jag kör Gentoo Linux, nginx, php-fpm, fastcgi-cache, apc och mysql med query cache.

 

jonasnordstrom.se har flyttat från Binero till Tilaa

Igår flyttade jag hela sajten till Tilaa, som är en holländsk VPS, där jag kör nginx och php-fpm på Gentoo Linux.

Även Topp30 och Fredagswhisky (två mycket små sajter)  ligger numera på Tilaa. Orsaken till flytten är förstås att jag vill ha full koll på mina WordPress-installationer. Jag vill kunna prova olika tekniker, mäta prestanda, göra lite okonventionella prestandaoptimerimeringar, få SSH-access(!) och framförallt lära mig mer om serversidan av webbprojekt.

Jag har inget otalt med Binero, de har alltid (nästan …) fungerat bra, även om jag fortfarande låg på old.binero.com!

Om sajten svajar lite den här första tiden så vet ni alltså vad det beror på. Lite vägarbete.

 

Unrecognized exception: [href=edit-comments.php?page=disqus]

I senaste WordPress-betan, 3.2 beta 1, används jQuery 1.5.2. Den versionen tillåter inte längre css-selektorer som inte sätter attributvärden inom citationstecken.
Om man, som jag, kör Disqus som kommentarsystem så uppstår ett problem, eftersom Disqus använder [property=value]-metoden vilket gör att jag får javascriptfel i admin vilket gör att de flesta menyknappar etc. är helt döda. Firebug visar det här felet:


Som tur är är det lätt att ordna, det är bara att gå in i plugin-filen disqus-comment-system/disqus.php och ändra:

mc.find('a.wp-has-submenu').attr('href', 'edit-comments.php?page=disqus').end()
   .find('.wp-submenu  li:has(a[href=edit-comments.php?page=disqus])')
   .prependTo(mc.find('.wp-submenu ul'));

till

mc.find('a.wp-has-submenu').attr('href', 'edit-comments.php?page=disqus').end()
   .find('.wp-submenu  li:has(a[href="edit-comments.php?page=disqus"])')
   .prependTo(mc.find('.wp-submenu ul'));

(det är alltså [href=edit-comments.php?page=disqus] som behöver attributfnuttar: [href=”edit-comments.php?page=disqus”])

Mer info här.

Jag gissar att Disqus lagar den här buggen väldigt snart.