Digital Ramble » design

growing a database

Cindy — Sat, 12 Aug 2006 01:42:03 +0000

I’ve been doing database driven websites for about seven years now, some of my own and some at work. Below I list some tips that have saved me a lot of trouble. Nothing complicated, and generally intended for small to medium sized databases…

Break up the tables

I have a database that stores information about dogs taken into a rescue group. Of course it started out with the basic information: name of dog, where obtained (shelter, owner, etc), who is fostering the dog, where a picture of the dog is, a descriptive “biography” of the dog, and a comment log noting things about the dog, or other relevant information. Something like:


CREATE TABLE Foster_Dogs (
  id MEDIUMINT(8) NOT NULL AUTO_INCREMENT,
  name CHAR(30) NOT NULL,
  source ENUM ("Shelter", "Owner", "Stray", "Vet", "Rescue"),
  intake DATE,
  foster_home MEDIUMINT(8),
  picture VARCHAR(60),
  bio TEXT,
  comments TEXT
  /* and actually much, much more...sigh */
);

Of course all kinds of situations have come up that I never thought of when first putting this together. The group started kenneling some dogs in addition to fostering them. Polls, vet bills, sponsorships, etc. In short, more information as time went on.

The first few times, I modified the entire “Foster dog” table to add on new fields, crossing my fingers each time that I woudn’t honk the database. Of course I always backed things up, but restoring in the case of mistakes was always a time consuming chore.

Then I hit on a much better solution. I already had a unique ID for each foster dog, because I knew I could not guarantee unique names for each dog (indeed the first two years alone saw over 20 dogs named “Buddy”). So I created a new table altogether.

As a simple example, some of the fostered dogs are cross indexed with a free advertising group to look for more potential adoptors. But the group wants to be able to remove such dogs from the other group when they have been adopted. So the simplest solution is a new table, consisting of two columns: the dog’s ID, and the name of the group it is cross-listed with. The original foster table is absolutely untouched. And it’s a snap to add this information to the edit pages seamlessly. The volunteers don’t know how the structure is underneath, it all comes up on the display pages, plus they can search on “which dogs are currently listed in which groups” and get the list — quickly.

Quantify select fields!

This bit me in the butt several times. Not so much now with the new tables approach above, but sometimes a table really needs to be altered in some way. In which case, a SELECT statement of the form:


SELECT * FROM Foster_Dogs...

is going to hurt when the wrong values are shoved into the wrong fields. No matter how painful it is to list (although yet again with the micro table method above, this is also alleviated), list them explicitly! That way even if the columns are reordered, the results from the query are always ordered the same way.

No, I don’t know why I didn’t always add new fields at the ends of records Some things are best forgotten, I think…

Use ID’s Everywhere

When coming up with some object on which data will be stored, always set up unique ID’s for the table. Both MySQL and Postgresql have functions for unique, autoincrementing numbers so that I never even have to try and track or generate the numbers. With the unique ID’s I can then mix and match other items.

For example a table that pairs up volunteer and foster dog ID’s along with start/end timestamps might be all I need at this stage to have complete records of who has fostered which dog when (even multiple times, if I consider each element in this table to be a “Foster_Interval” and give this a unique ID.

To recap, that would be a definition something like this:


CREATE TABLE Foster_Intervals (
  id MEDIUMINT(8) NOT NULL AUTO_INCREMENT,
  dog_id MEDIUMINT(8) NOT NULL,
  vol_id MEDIUMINT(8) NOT NULL,
  start_time TIMESTAMP NOT NULL,
  end_time TIMESTAMP
);

The unique id guarantees that any instance of a volunteer fostering a dog will be retained. If the same volunteer were to foster the same dog multiple times, that could overwrite the record so I only had information on the latest fostering stint, not all of them.

Now the query to pull out currently fostered dogs might be done this way:

A simple table, but pulling together a good deal of info on top of other already constructed tables.

Record those tables

Yes, a dump is generally a good way to get the structures back and both MySQL and Postgresql have ways for doing that. But I’ve had a few occasions where a table got deleted and then good luck with reconstructing the table. So for convenience’s sake and for backup purposes, I maintain a file with the original table declarations in it. In some cases, I’ve even written scripts that automatically dump table declarations and check them into a version control system. I run these scripts before doing anything with the database and this way I have a record of the changes over time to the database.

Other ideas?

I find that sitting down and mapping things out helps me to form a good database structure. Of coruse, there will be different considerations depending on the (eventual) size of the database: much larger structures may start to slow down too much with too many small tables but tables with too much aggregated information are at risk of becoming corrupted over time.

I’d be curious to hear of any other tips folks have acquired from their experience, too.

Copyright © 2010 Digital Ramble. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact legal@www.digitalramble.com so we can take legal action immediately.
Plugin by Taragana

detouring css through php

Cindy — Wed, 05 Jul 2006 19:11:18 +0000

One thing that tends to drive me nuts when putting a css file together is repetition of the colours. CSS has no mechanism to define constants or variables and it can be pretty tiresome playing around with resetting the colours and such when tweaking a web page.

So I made mine into a php file. There’s a few tricks, but it’s very straightforward. First, you call it in your main html file (or output) as with any other css file, only with it’s name:

Now here’s the fun part. The first line in the php file must now be:

Otherwise the file is sent as text/html and I get unhappy junk printed out. With that out of the way, the top of the file can contain something like this:

Now I proceed with the rest of the css definitions as usual, but when I want to use a defintion, I pop it in like this:


a:hover {
        color: ;
        text-decoration: underline;
}

Looks like someone else (actually many people; try googling on “variables in css”) was addressing the same problem. My solution is pretty straightforward, although it does require access to php, etc. This solution hides it but amounts to using php to parse and replace behind the scenes, so I think my solution is at least more direct…

rethinking form/post conventions

Cindy — Mon, 03 Jul 2006 23:39:05 +0000

Ever since I first started scripting cgi to process forms I’ve used the two file format: the first file puts up the form and such and calls the second file to process the results of the form.

But it really doesn’t have to be like that. At work, I have a single program that lets you search through our database and display things, setting options and so on, and paging through the results. It only uses one executable (well there are a few more, but each one encapsulates a certain kind of function and as long as you’re doing that, you stay within that executable). Now admittedly I’ve torn my hair out more than once debugging this thing, so this idea can go too far in the other direction, but keep it to simple pairs of form/post and I’m liking it.

So I’ve started looking at my old sites and in particular the old one of mine that was offline for six years and rethinking how I did this stuff. And I’m thinking the single file form/post is a much better way to go. It’s fewer files for one thing. I’m not left having to grep through the file to see what it calls to trace down problems. They’re all there in one spot.

So for example I just redid the mail form which started out in mail.php that called sendemail.php (that’s another thing, it simplifies naming conventions — at another site of mine I’ve been trying to standardize to action_form.cgi and action_post.cgi but still it’s all a mess.

But this comes out nice and slick in one file. Start up the headers, check whether it’s a submit and the form goes in the first half the if statement, the post in the second half. Close off with the footers and it’s all set.

Now, let’s see, just how many more files are lurking around on this site? Sigh…

theme-a-thon!

Cindy — Fri, 16 Jun 2006 20:29:59 +0000

Having MUCH too much fun with theme rotation…

Actually though, I think every theme developer should play around with something like this. Because I’m starting to develop some very strong preferences for basic setups, such as:

always package up your theme in a directory so when I unzip it, it keeps everything tidy in it’s own directory, ‘k?
don’t make your sidebars (or other .php files) so weird I can’t drop in copies of my already tweaked sidebars in! (I found one theme that closed off a div before starting the sidebar div — which meant it didn’t play well with anyone else!)
make sure they use the right hooks and such…I found some that didn’t incorporate some of my auto-plugins (ones that didn’t need stuff added to files in the theme directories) — those went buh-bye though I liked them…

Note that the only mods I did to these themes was to ensure that they all had a theme handler in the side bar so that no one gets stuck in a theme with no exit. But in the longer run, I want to set them all up with soft links to the same sidebar.php file. I’ll also need to tweak some a bit for the category/technorati tags to come out right and such. But this is fun…

Okay, enough lunch time play…back to work!

anatomy of a new plugin

Cindy — Tue, 06 Jun 2006 23:45:22 +0000

Update:
Italian translation appended 31 Oct 06

English

Overview

Well I dove deeper into the WordPress documentation since this plugin I wanted to do several things with this one: I wanted it to have an administration panel to enter information, and I did NOT want to make anyone using the plugin have to do anything more than set options through the panel. In other words, no more code tweaking.

Several reasons for that. In the first place, not everyone using WordPress is a geeky hacker like myself. In the second place, it’s annoying even for a geeky hacker like myself to move around themes or update WordPress and have to re-do all the little hacks and edits. So I’m becoming a bigger fan of plug’n'play plugins.

Now to be fair, this isn’t always avoidable. In particular, sidebar elements aren’t easily hooked in (I think this is the idea behind the sidebar widgets project, but I haven’t looked deeply enough into that to be sure). But I’ve already seen some interesting workarounds by other plugin authors and I think it’s possible to avoid many of these problems.

In any case, this plugin is about favicons. Here was my wish list:

To enter an arbitrary image for the favicon
Specify the image relevant to my WordPress directory or as absolute URI
To change it whenever I wanted
To use gif/icon/png files for the favicon
Optionally use it in my rss2 feed
Optionally use it in my atom feed
Everything configurable from the admin panel
A “plug and play” plugin — install and activate, nothing more

To my surprise, this was pretty easy. Perhaps an hour or so of reading the relevant documentation, about 15 minutes coding, another hour or so testing it, and about two hours of writing up and documentation. That’s a pretty typical ratio…

Update: the completed plugin is available at http://www.digitalramble.com/favicon-manager-wordpress-plugin/ (take a peek at the sidebar).

Header Hooks

In order to add something to the headers, without requiring the user to edit their WordPress files, you use


// insert favicon into header using hooks
add_action('wp_head', 'add_favicon_to_headers');

where add_favicon_to_headers is a simple parameterless function that prints out what you want added into the headers. It’s that simple. The first cut at the function does what it’s supposed to do, upon testing:


function add_favicon_to_headers()
{
  $favicon_location="http://example.com/example.ico";
  $favicon_type="x-icon";
  print ' ';
  print "\n";
  print ' ';
  print "\n";
}

Of course this is only the first crack at it, just to make sure it works. As it does indeed, if you were to drop the above (encapsulated in the does just that but of course it’s not configurable as per my wish list .

Database

In order to have persistent, retrievable values, I had to make use of the database utilities offered in WordPress. There’s add_option, update_option and get_option for a very simple interface. So I make sure there’s a database entry for the favicon’s location:


// add the saved items to the database if not already there
function favicon_mgr_add_options()
{
        add_option('fm_favicon_location', '');
}

favicon_mgr_add_options();

At this point the database now has a new item with an empty string value for this plugin to use. I tried to use long descriptive names to reduce the possibliity of name space collision. It would have been easier on my fingers to just use “favicon” but of course the possiblity is higher that sooner or later it will run into someone else with the same brilliant idea.

This means that the hook should now retrieve the value from the database:


function add_favicon_to_headers()
{
  $favicon_location=get_option('fm_favicon_location');
  $favicon_type=get_favicon_type($favicon_location);
  print ' ';
  print "\n";
  print ' ';
  print "\n";
}

Now you see why I used variables to begin with . The get_favicon_type is another function I wrote (but didn’t include for clarity above) that returns the correct type (x-icon, gif, jpg, png) depending on the favicon’s name. So now I’m set regardless of what the user enters (I do need to add a check in case the extension is unknown, but again I’m keeping things as short as I can).

Admin panel

Wordpress also provides a pretty straightforward set of functions for creating an admin panel. It was actually pretty easy. First there’s the hook to put a new menu item under Options (you can do more, but for basic stuff like this, Option’s fine).


// create hook for new submenu
add_action('admin_menu', 'favicon_mgr_admin_menu');

// title of page, name of option in menu bar, which function lays out the html
function favicon_mgr_admin_menu()
{
        add_options_page(__('Favicon Manager Options'), __('Favicons'), 5, basename(__FILE__), 'favicon_mgr_options_page');
}

// html layout for option page, plus detection/update on new settings
function favicon_mgr_options_page()
{
  ...
}

So what this all does is first a menu item is added in. The menu item in turn specifies the function that lays out its page. So then that function prints out the html necessary to allow input, etc. That page will also have to update the database entries so that the header hook retrieves the correct value to drop into the headers. So it’s starting to come together. Here’s the first cut at the options page:


function favicon_mgr_options_page()
{
        $updated = false;

        if (isset($_POST['fm_favicon_location']))
        {
                $fm_favicon_location = $_POST['fm_favicon_location'];
                update_option('fm_favicon_location', $fm_favicon_location);
                $updated = true;
        }
        $fm_favicon_location = get_option('fm_favicon_location');
        if ($updated)
        {
                ?>
                Options saved.



Let’s take the pause that refreshes.  Remember that this page can be used when the user first enters the option page, or after they’ve hit the submit button.  So the first thing to check is to see if this is on submission.  isset provides a way of checking to see if that form input element has been set or not.  If it has, I drop it into the database, and set update to true.


        ?>
        
                Favicon Settings
                

                        

                                Favicon in WordPress Pages
                                
                                
                                        
                                        
                                
                                Location: 
                                        

                        

                        
                          
                        
                

        

        


This part prints out the actual form page, with values in the input field if any exist.  The layout is already controlled via the stylesheets and classes used here, so the familiar blue and white theme layout comes right up.
That’s it!  Pretty much the only items left are the arbitrary or relative locations for the favicon (I want the users to be able to enter the location either way) and the RSS2/Atom options.  The former is easily resolved with one more function:



And now I update instances where I get the favicon_location to run the results through this before using it.  I do not use this before storing the location into the database, though.  To avoid user confusion, I prefer to retain what they actually entered.
The Feed Options
I’m only going to describe the RSS2 additions here.  The Atom is exactly the same other than the actual output in the hook.
As of WordPress 2.0, hooks are provided for RSS2:


function add_image_to_rss2_feed()
{
  // do this or not depending on user settings in panel!
  if (get_option('fm_rss2_feed_option')=="Y")
  {
        $favicon_location=create_favicon_uri(get_option('fm_favicon_location'));
        echo "\n";
        echo "  ". get_bloginfo_rss('url') ."\n";
        echo "  ". $favicon_location ."\n";
        echo "  ". get_bloginfo_rss('name') ."\n";
        echo "\n";
  }
}

// insert image into rss2 feed
add_action('rss2_head', 'add_image_to_rss2_feed');


So now I add it to my database:


// add the saved items to the database if not already there
function favicon_mgr_add_options()
{
        add_option('fm_favicon_location', '');
        add_option('fm_rss2_feed_option', '');
}


This gets added to the option page function before printing out whether or not new options have been saved:


        // checkboxes flip on/off
        if ($_POST['fm_rss2_feed_option']!=get_option('fm_rss2_feed_option'))
        {
                $fm_rss2_feed_option = $_POST['fm_rss2_feed_option'];
                update_option('fm_rss2_feed_option', $fm_rss2_feed_option);
                $updated = true;
        }
        $fm_rss2_feed_option = get_option('fm_rss2_feed_option');


The checkboxes work a little bit differently than text input boxes.  If you uncheck a checkbox, you do NOT get input.  Since this is an on/off switch, the fix is to simple check if the value is the same as what is stored since only two values are possible.
Now I add in the bit of HTML to ask the user to check off whether they want the favicon added to their RSS2 feed:


                                Images in Feeds
                                
                                
                                        
                                        
                                
                                Add to RSS2 Feed?  >
                                        


This is put into the fieldset wrapper of the options page.
Atom is identical, but the image is added through an <icon> marker and the value is simply the location of the favicon.
The feed images are handled a little differently from the header favicons.  They don’t actually have to be 16×16, they can be a little bit larger.  Traditionally they appear along the header field in an aggregator, and if you look at a wunderground.com weather feed in Bloglines, you’ll notice a relatively large rainstorm/weather icon at the top of its articles.  But (using Bloglines for reference again), the images can also be used on the left in Blogline’s “bookmarks” tree.  It may be worthwhile giving an optional image field for the feeds: if it’s left empty use the favicon, otherwise use the image for the feeds only.  I haven’t decided…  
Support Files
Although the code is written up and tested, I’m not yet finished.  I need to put together a couple more things:

A readme.txt file to be bundled with the favicon manager php file
A zipped version with the correct directory, etc to be put out in the public directory
A help/support page where potential users can read about the plugin, find directions for installing, and find the bundle itself

There’s a few other more optional actions to take as well, such as whether to register the plugin with Codex, WP Plugins Database, and other forums that collect plugin info.
Some Thoughts
I might be able to make this plugin work for earlier versions of WordPress by protecting the feed options with a check for the existence of the feed hooks.  If they’re not there, then skip all the feed elements.  Thus the plugin would degrade to favicons-in-headers-only mode, provided none of the other function calls or hooks have changed substantially.  But given that I have written this well after the 2.0 upgrade, I’m not particularly inclined to do this…especially since I don’t have the means for testing it anyway.
Italian

Panoramica
Ho scavato più in profondità nella documentazione di WordPress, perchè volevo che il mio plugin rispettasse alcuni criteri: volevo che avesse un pannello di amministrazione perchè NON volevo che chiunque lo usasse fosse obbligato a fare altro che impostare opzioni tramite il pannello. In altre parole, basta modifiche al codice.
Diverse ragioni per questo. Primo, non tutti gli utenti WordPress sono smanettoni come me. Secondo, è noioso anche per gli smanettoni come me cambiare temi o aggiornare WordPress e dover riapplicare tutte le piccole modifiche. Per questo motivo sto diventando la più grande fan dei plugin plug’n’play.
Per essere onesti, non sempre questo è evitabile. In particolare, gli elementi delle barre laterali non sono facilmente integrabili (credo sia questa l’idea alle spalle dei widget, ma non ho ancora approfondito abbastanza da esserne certa). In ogni caso ho già visto diversi metodi interessanti nel lavoro di altri autori di plugin, e credo sia possibile evitare molti di questi problemi.
Comunque sia, questo plugin riguarda le favicons. Questa era la mia lista dei desideri:

Poter inserire una immagine arbitraria come favicon
Poter specificare l’immagine rilevante nella mia cartella WordPress anzichè come URI assoluta.
Poter modificare questa immagine in qualunque momento.
Poter usare files gif/icon/png per la favicon
Eventualmente usare l’immagine nel mio feed rss2
Eventualmente usare l’immagine nel mio feed atom
Tutto questo configurabile nel pannello di amministrazione
Un plugin “plug and play” – da installare e attivare, null’altro.

Con mia sorpresa, questo è stato abbastanza semplice. Più o meno un ora per leggere la documentazione rilevante, circa 15 minuti per programmare, un’altra ora per il collaudo, e quasi due ore di scrittura e documentazione  Questa è un proporzione abbastanza tipica…
Il plugin completo è disponibile all’indirizzo

http://www.digitalramble.com/favicon-manager-wordpress-plugin/

(date un’occhiata sul lato).
Agganci agli header
Per aggiungere qualcosa agli header, senza obbligare l’utente a modificare i propri files di WordPress, potete usare

// insert favicon into header using hooks
add_action('wp_head', 'add_favicon_to_headers');

dove add_favicon_to_headers è una semplice funzione senza parametri che inserisce ciò che volete all’interno degli header. E’ molto semplice. La prima bozza della funzione è in grado di fare ciò che vorremmo facesse, durante i test:

function add_favicon_to_headers()
{
  $favicon_location="http://example.com/example.ico";
  $favicon_type="x-icon";
  print ' ';
  print "n";
  print ' ';
  print "n";
}

Ovviamente questa è solo una prima stesura, giusto per essere certi che funzioni. E può funzionare, se inserite il codice qui sopra (all’interno dei codici ?php e con un indirizzo corretto al posto di example.ico) in un file con estensione .php nella vostra cartella dei plugin. Esiste infatti un semplice favicon plugin che fa esattamente questo ma non è configurabile come ho detto nella mia lista dei desideri 
Database
Per avere valori persistenti e recuperabili, ho dovuto fare uso delle utilità a livello database offerte in WordPress. Ci sono add_option, update_option e get_option per un interfacciamento semplice. Quindi farò in modo di verificare che sia presente un dato nel database con l’indirizzo della favicon:

// add the saved items to the database if not already there
function favicon_mgr_add_options()
{
        add_option('fm_favicon_location', '');
}

favicon_mgr_add_options();

A questo punto il database ha ora un nuovo elemento, con un valore vuoto (una stringa di testo) disponibile per questo plugin. Ho provato a usare nomi lunghi e descrittivi (nelle funzioni, N.d.T.) per ridurre l’eventualità di una collisione di name space. Sarebbe stato più semplice per le mie dita usare solo “favicon”, ma ovviamente sarebbe stata più alta la possibilità che qualcuno abbia avuto prima o poi la mia stessa brillante idea.
Questo significa che l’aggancio ora può recuperare valori dal database:

function add_favicon_to_headers()
{
  $favicon_location=get_option('fm_favicon_location');
  $favicon_type=get_favicon_type($favicon_location);
  print ' ';
  print "n";
  print ' ';
  print "n";
}

Ora potete vedere perchè ho usato le variabili fino ad ora . La funzione get_favicon_type è un’altra funzione che ho scritto (e non ho incluso sopra per chiarezza) che restituisce il tipo corretto (x-icon, gif, jpg, png) a seconda del nome della favicon. In questo modo la funzione è pronta qualunque sia l’input dell’utente (dovrei aggiungere un controllo nel caso l’estensione sia sconosciuta, ma ancora una volta sto cercando di rendere le cose più semplici possibile).
Pannello di amministrazione
WordPress offre anche un set diretto di funzioni per crare un pannello di amministrazione. E’ stato decisamente semplice. Per prima cosa è presente un aggancio per inserire un nuovo menù sotto il menu Opzioni (potete fare anche altro, ma per cose basilari come queste, Opzioni è più che sufficiente).

// create hook for new submenu
add_action('admin_menu', 'favicon_mgr_admin_menu');

// title of page, name of option in menu bar, which function lays out the html
function favicon_mgr_admin_menu()
{
        add_options_page(__('Favicon Manager Options'), __('Favicons'), 5, basename(__FILE__), 'favicon_mgr_options_page');
}

// html layout for option page, plus detection/update on new settings
function favicon_mgr_options_page()
{
  ...
}

Quindi, tutto ciò che questo produce è l’inserimento di un oggetto menu. L’oggetto specifica a sua volta la funzione che definirà la pagina. Quindi, la funzione inserirà il codice necessario a permettere gli input e il resto. Questa pagina dovrà inoltre poter aggiornare i record nel database in modo che gli agganci della testata possano ricevere i valori corretti da inserire nella stessa. In questo modo le cose iniziano a essere collegate. Una prima stesura della pagina di opzioni:

function favicon_mgr_options_page()
{
        $updated = false;

        if (isset($_POST['fm_favicon_location']))
        {
                $fm_favicon_location = $_POST['fm_favicon_location'];
                update_option('fm_favicon_location', $fm_favicon_location);
                $updated = true;
        }
        $fm_favicon_location = get_option('fm_favicon_location');
        if ($updated)
        {
                ?>
                
Options saved.
                

Prendiamo una pausa rinfrescante. Ricordiamoci che questa pagina verrà mostrata solo quando l’utente entrerà nella pagina di opzioni, oppure dopo aver modificato le opzioni stesse. Quindi la prima cosa da verificare è se l’elemento input del modulo è stato modificato o meno. Nel primo caso, verrà inserito nel database, e verrà impostato update su true.

        ?>
        
                Favicon Settings
                

                        

                                Favicon in WordPress Pages
                                
                                
                                        
                                        
                                
                                Location: 
                                        

                        

                        
                          

                

        
        

Questa parte restituisce la pagina del modulo, con i valori nel campo imput se sono già impostati. La presentazione è già controllata tramite i fogli di stile e le classi usate, quindi verrà usato il familiare tema bianco e blu.
E’ tutto qui! In pratica gli unici elementi non inseriti sono la posizione abitraria o relativa della favicon (voglio che gli utenti abbiano la possibilità di inserire entrambe) e l’opzione RSS2/Atom. La prima è risolta facilmente con una ulteriore funzione:

Ora aggiornerò le istanze in cui richiamo $favicon_location per processare i risultati tramite questa funzione prima di usarli. Non userò comunque questa funzione prima di memorizzare la posizione nel database. Per evitare confusioni da parte dell’utente, preferisco tenere ciò che hanno inserito.
L’opzione Feed
Spiegherò solamente l’aggiunta per RSS, in quanto l’opzione Atom è identica, eccetto l’output nell’aggancio.
A partire da WordPress 2.0, sono forniti agganci per gli RSS2:

function add_image_to_rss2_feed()
{
  // do this or not depending on user settings in panel!
  if (get_option('fm_rss2_feed_option')=="Y")
  {
        $favicon_location=create_favicon_uri(get_option('fm_favicon_location'));
        echo "n";
        echo "  ". get_bloginfo_rss('url') ."n";
        echo "  ". $favicon_location ."n";
        echo "  ". get_bloginfo_rss('name') ."n";
        echo "n";
  }
}

// insert image into rss2 feed
add_action('rss2_head', 'add_image_to_rss2_feed');

Quindi inserirò nel mio database:

// add the saved items to the database if not already there
function favicon_mgr_add_options()
{
        add_option('fm_favicon_location', '');
        add_option('fm_rss2_feed_option', '');
}

Questo verrà aggiunto alla pagina di opzioni prima dell’output, a prescindere dal fatto che le nuove opzioni siano già salvate.

        // checkboxes flip on/off
        if ($_POST['fm_rss2_feed_option']!=get_option('fm_rss2_feed_option'))
        {
                $fm_rss2_feed_option = $_POST['fm_rss2_feed_option'];
                update_option('fm_rss2_feed_option', $fm_rss2_feed_option);
                $updated = true;
        }
        $fm_rss2_feed_option = get_option('fm_rss2_feed_option');

Le caselle di selezione funzionano in modo leggermente differente dai campi di input testuale. Se deselezionate una casella, NON avrete un input. Dal momento che è un selettore acceso/spento, la soluzione è controllare se il valore è lo stesso di quello memorizzato, dal momento che solo due valori sono possibili.
Ora aggiungerò del codice HTML per chiedere all’utente di scegliere se usare la favicon nei propri feed RSS2:

                               Images in Feeds
                                
                                
                                        
                                        
                                
                                Add to RSS2 Feed?  >
                                        

Questo è inserito nel contenitore fieldset della pagina di opzioni.
Atom è identico, ma l’immagine è inserita tramite un tag e il valore è semplicemente l’indirizzo della favicon.
Le immagini dei feed sono gestite in modo differente dalle favicon della testata. Non devono essere per forza 16×16, ma possono essere un po’ più grandi. Di solito appaiono accanto al campo della testata in un aggregatore, e se date un’occhiata al feed delle previsioni del tempo su Bloglines, potrete notare una icona relativamente grande in cima ai suoi articoli. Ma (usando per esempio ancor Bloglines), le immagini possono anche essere usate sulla destra, nei bookmarks di Bloglines (le informazioni su Bloglines possono essere variate, N.d.T. ). Può valere la pena offrire un campo opzionale per l’immagine dei feed: se è lasciato vuoto verrà usata la favicon, altrimenti verrà usata questa immagine solo per i feed. Non ho ancora deciso…
Files di supporto
Anche se il codice è scritto e collaudato, non ho ancora finito. Devo aggiungere a questo alcune cose:
    * Un file readme.txt da allegare con il file php del plugin

    * Una versione compressa con le cartelle e i files corretti da mettere nella mia cartella pubblica

    * Una pagina di aiuto e supporto dove i potenziali utenti potranno trovare informazioni sul plugin, istruzioni per l’installazione, e dove sarà disponibile l’archivio stesso.
Ci sono alcune azioni facoltative che potreste voler intraprendere, come registrare il plugin su Codex, nel database dei plugin WP, e in altri forum che raccolgono informazioni sui plugin.
Alcuni pensieri
Potrei essere in grado di rendere questo plugin funzionante con versioni precedenti di WordPress, proteggendo l’opzione dei feed con un controllo sulll’esistenza dell’aggancio ai feed. Se non è presente, allora evita tutti gli elementi feed. In questo modo il plugin dovrebbe degradare in modalità favicon-solo-header, tenendo conto che nessuna delle altre funzioni è stata modificata. Ma dato che ho scritto questo ben dopo l’aggiornamento alla versione 2.0, non sono particolarmente invogliata a farlo… specialmente visto che non ho i mezzi necessari per fare i test.
Copyright © 2010 Digital Ramble. This Feed is for personal non-commercial use only. If you are not reading this material in your news aggregator, the site you are looking at is guilty of copyright infringement. Please contact legal@www.digitalramble.com so we can take legal action immediately.
Plugin by Taragana