<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Anthology of Ideas &#187; HTML</title>
	<atom:link href="http://anthologyoi.com/tag/html/feed" rel="self" type="application/rss+xml" />
	<link>http://anthologyoi.com</link>
	<description>Anthology of Ideas is an archive of thoughts and form.</description>
	<lastBuildDate>Sat, 03 Mar 2012 11:16:55 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>XHTML vs HTML: Round 2</title>
		<link>http://anthologyoi.com/dev/xhtml-vs-html-round-2.html</link>
		<comments>http://anthologyoi.com/dev/xhtml-vs-html-round-2.html#comments</comments>
		<pubDate>Wed, 05 Sep 2007 19:00:21 +0000</pubDate>
		<dc:creator>aaron</dc:creator>
				<category><![CDATA[Web Developing]]></category>
		<category><![CDATA[content type]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[semantic]]></category>
		<category><![CDATA[syntax]]></category>
		<category><![CDATA[xHTML]]></category>
		<category><![CDATA[xml]]></category>

		<guid isPermaLink="false">http://anthologyoi.com/dev/xhtml-vs-html-round-2.html</guid>
		<description><![CDATA[]]></description>
			<content:encoded><![CDATA[<p>When XHTML was first released nearly everyone, myself included, rushed headlong into it. Countless websites were shredded, old HTML code was stripped out and rebuilt using XHTML syntax under the watchful eye of the W3 validators. When it was over, the dust settled and, for a time, everyone tried to pretend HTML no longer existed &#8212; scorning those who had the audacity to still use HTML. </p>
<p>Time passed. People began realizing that XHTML wasn&#8217;t the save all and be all that it was supposed to be: some popular browsers (cough: IE) couldn&#8217;t even properly render its content type of <em>application/xhtml+xml</em>, so developers were stuck calling it XHTML and pretending that it was truly XHTML+XML, but they were really just dishing out HTML that was properly formatted. </p>
<p>This is not to say that the &#8220;XHTML rush&#8221; &#8482; was bad or that it didn&#8217;t advance technologies and the semantic nature of programming: it, with the help of CSS, helped to banish the hack and slash methods that were intrinsic in the 1990&#8242;s because people started realizing what each tag really meant and peer pressure abounded. In the end, however, all it did was make people aware of the rules that were already there, and in the process forced users to break other rules.</p>
<p>Finally the stigma of using semantically-correct HTML, inside the industry, is wearing off (although outside of it XHTML is still a buzz-word) and developers are realizing that XHTML wasn&#8217;t really <em>the</em> thing to use&#8212;instead it was just a good, clean language to use when it was needed, and some are slowly trickling back to serving just plain-ol&#8217; HTML&#8212; albeit it this time with clean markup and remembering the lessons XHTML taught us.</p>
<p>Well it is on the verge of happening again: X/HTML 5.0 and XHTML 2.0 are both in development, and they both are trying to make their own mark on the browser space, but in the process they are just going to cause more trouble because the last time the (X)/HTML wars began XHTML 1.0 was, on the surface, HTML 4.0 with a few more rules. However, this time they are trying to go in separate directions, and the problem is that they both are doing some things correctly. (If you haven&#8217;t been keeping up with developments and want to read a comparison on what is and is not being done correctly read xhtml.com&#8217;s  <a href="http://xhtml.com/en/future/x-html-5-versus-xhtml-2/">X/HTML 5 Versus XHTML 2</a>) </p>
<p>While the competition will be good, in some ways, and the professionals will reason out the best language to use and why, the fame wars are going to start up again, so  be ready for it and get out your favorite fan-boy insults because only one language is going to survive.</p>
<p>This rant was brought to you by the letter <strong>X</strong> and the number <strong>3</strong>. Oh and in case you are wondering, this site is perfectly valid XHTML using the XHTML 1.1 DTD being served as text/html with .html extension.</p>
]]></content:encoded>
			<wfw:commentRss>http://anthologyoi.com/dev/xhtml-vs-html-round-2.html/feed</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Generating Semantic Comment Lists with XHTML</title>
		<link>http://anthologyoi.com/dev/generating-semantic-comment-lists-with-xhtml.html</link>
		<comments>http://anthologyoi.com/dev/generating-semantic-comment-lists-with-xhtml.html#comments</comments>
		<pubDate>Wed, 22 Aug 2007 07:46:49 +0000</pubDate>
		<dc:creator>aaron</dc:creator>
				<category><![CDATA[Web Developing]]></category>
		<category><![CDATA[comments]]></category>
		<category><![CDATA[formating]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[lists]]></category>
		<category><![CDATA[symantic]]></category>
		<category><![CDATA[xHTML]]></category>

		<guid isPermaLink="false">http://anthologyoi.com/dev/generating-symantic-comment-lists-with-xhtml.html</guid>
		<description><![CDATA[XHTML specifications provide three types of lists ordered lists &#60;ol>, unordered lists &#60;ul> and definition lists &#60;dl>. Ordered lists are meant for content that must be arranged in a specific order &#8212; things like instructions, or lines of code. Unordered &#8230; <a href="http://anthologyoi.com/dev/generating-semantic-comment-lists-with-xhtml.html">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>XHTML specifications provide three types of lists ordered lists &lt;ol>, unordered lists &lt;ul> and definition lists &lt;dl>. Ordered lists are meant for content that must be arranged in a specific order &#8212; things like instructions, or lines of code. Unordered lists are meant to be used for content that can reasonably be displayed in any order such as navigation menus or shopping lists. The rarely used definition lists is meant to be used where one list item is logically defined by a subsequent item (a definition term &lt;dt> followed by a definition description &lt;dd>) it functions the same way as a FAQ or glossary. However, when specifically used for comments, the only sure bet is that the unordered list is inappropriate &#8212; because comments require a specific order to make sense &#8212; while the ordered list and definition list vie for being the second worst. (Note I didn&#8217;t say best because neither is really qualified.) So this post will try to iron out the argument a bit.</p>
<p>Some things the remember: all lists are block level elements which means they can contain almost any other element and still retain validity.</p>
<h3>Definition lists</h3>
<p>Definition lists do not seem to be the appropriate element because a comment is not strictly a definition, however, if you take the W3C&#8217;s name for the dd element, (definition description) it appears that it could also be used for comment lists. Structurally, however, the definition list fits perfectly with the standard comment.<br />
<code title="Comment List example"></p>
<dl>
<dt>John posted the following on 12/9/2007</dt>
<dd>
<p>Wow, what a great list example.</p>
</dd>
<dt>Aaron posted the following on 13/9/2007</dt>
<dd>
<p>Why thank you.</p>
</dd>
<dt>John posted the following on 12/9/2007</dt>
<dd>
<p>You are very welcome. The list is flawless.</p>
</dd>
</dl>
<p>[/sourcecode]</p>
<p>Wow, that is almost perfect. The commenter's information is the term and the thoughts are described in the comment. it is almost too perfect, and here is where it breaks down. </p>
<p>1) Structurally, and semantically you can't have the comment on top and the author's information on the bottom. The following is just a pile of invalid tags. It has no semantic meaning, unless you are playing a game of jeopardy, and structurally it is invalid.</p>
<p><code title="Comment List example"></p>
<dl>
<dd>
<p>Wow, what a great list example.</p>
</dd>
<dt>John posted the above on 12/9/2007</dt>
<dd>
<p>Why thank you.</p>
</dd>
<dt>Aaron posted the above on 13/9/2007</dt>
<dd>
<p>You are very welcome. The list is flawless.</p>
</dd>
<dt>John posted the above on 12/9/2007</dt>
</dl>
<p>[/sourcecode]</p>
<p>2) You can't logically nest &lt;dt>/&lt;dd> combinations inside each other, so you can't have threaded comments.</p>
<p>3) The use of &lt;dt> tags to hold citation information is sketchy at best, although the &lt;dd> tag is defined as a description, it is rather a stretch to ignore the definiton part of it. </p>
<p>4) Thee is nothing in the standards that require terms to be in a specific order.</p>
<p>So it isn't possible to use &lt;dl>'s and still retain both structural and semantic validity. However, we do know that comments are a list, so this just leaves unordered lists.</p>
<h3>Ordered Lists</h3>
<p>If your comments are "flat" (only one level of comments, no parent/children pairs)  then the ordered list seems to make the most sense if you want numbers to be automatically generated. However, for sites that allow threading, like this one, the numbers must be hidden.</p>
<p>Now in a typical comment list we have:</p>
<p><code title="Comment List example"></p>
<ol>
<li>
<div>John posted the following on 12/9/2007</div>
<div>
<p>Wow, what a great list example.</p>
</div>
</li>
<li>
<div>Aaron posted the following on 13/9/2007</div>
<div>
<p>Why thank you.</p>
</div>
</li>
<li>
<div>John posted the following on 12/9/2007</div>
<div>
<p>You are very welcome. The list is flawless.</p>
</div>
</li>
</ol>
<p>[/sourcecode]</p>
<p>The greatest strength of using the ordered list is it nests flawlessly: </p>
<p><code title="Comment List example"></p>
<ol>
<li>
<div>John posted the following on 12/9/2007</div>
<div>
<p>Wow, what a great list example.</p>
</div>
<ol>
<li>
<div>Aaron posted the following on 13/9/2007</div>
<div>
<p>Why thank you.</p>
</div>
<ol>
<li>
<div>John posted the following on 12/9/2007</div</p>
<div>
<p>You are very welcome. The list is flawless.</p>
</div>
</li>
</ol>
</li>
</ol>
</li>
</ol>
<p>[/sourcecode]</p>
<p>Although the markup by hand can appear to be a little convoluted, it is a perfect nested list and semantically it demonstrates inheritance and means  exactly what we want it to mean. Now the problem with this, is that semantically the content of the &lt;li>'s don't have any meaning even though the relationship between the two items is defined by using an ordered list. To create a semantically valid ordered list we can replace the two divs with elements that are a little more semantic.</p>
<p><code title="Comment List example"></p>
<ol>
<li>
		<cite>John posted the following on 12/9/2007</cite></p>
<blockquote><p>Wow, what a great list example.</p>
</blockquote>
</li>
<li>
		<cite>Aaron posted the following on 13/9/2007</cite></p>
<blockquote><p>Why thank you.</p>
</blockquote>
</li>
<li>
		<cite>John posted the following on 12/9/2007</cite></p>
<blockquote><p>You are very welcome. The list is flawless.</p>
</blockquote>
</li>
</ol>
<p>[/sourcecode]</p>
<p>Now this version is better: The cite tag works because it is not only citing the person who said it but also <em>when</em> they said it, and no meaning is lost if you move the cite tag below the blockquote, but I think the blockquote may be inappropriate because while the person is saying it, we aren't quoting them.  However if in the example were quoted in the second, the blockquote would be appropriate (although we can ignore the fact that the &lt;q> would have been more appropriate.)  </p>
<p>Now because I hate to introduce presentational elements back into it, I think that if there <em>needs</em> to be an element wrapping the content of the comment, it should be a blockquote because yes technically it is a quote and if the page were to appear in a print edition it would be treated as a quote, but I don't think it isn't seen that way by most people.</p>
<p> However, we still need to format the content inside the li a little better. The previous example gets it almost correct, but the cite element really is being used incorrectly.</p>
<p><code title="Comment List example"></p>
<ol>
<li>
<p><cite>John</cite> posted the following on 12/9/2007</p>
<p>Wow, what a great list example.</p>
</li>
<li>
<p><cite>Aaron</cite> posted the following on 13/9/2007</p>
<p>Why thank you.</p>
</li>
<li>
<p><cite>John</cite> posted the following on 13/9/2007</p>
<p>You are very welcome. The list is flawless.</p>
</li>
</ol>
<p>[/sourcecode]</p>
<p>Much better, theoretically we could be using a &lt;span> tag instead of a &lt;p> tag, but we would have to put the &lt;span> inside of a &#038;ltp> anyway, and with the addition to style information to the &lt;p> tag containing the author information, the content will be both symantically and structurally valid.  As a final note, although  I ragged on using structural elements quite a lot, but they aren't always bad. I do use them on this site to wrap single comments when needed (because comments are nested, so a style applied to one comment applies to all.)</p>
<p>So what did we learn here?</p>
<ol>
<li> Ordered lists should always be used for comments (but dl lists may be valid for other types of dialog)</li>
<li>&lt;div>'s and &lt;span>'s should never be used to hold comment information because there are elements that are much better suited to it.</li>
<li>If you need a block level element to hold your comment text, use a &lt;blockquote> it may require a little extra effort to style correctly, but it is always better to do things the right way.</li>
</ol>
]]></content:encoded>
			<wfw:commentRss>http://anthologyoi.com/dev/generating-semantic-comment-lists-with-xhtml.html/feed</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>WordPress How To:  Easily make an admin panel for a plugin</title>
		<link>http://anthologyoi.com/wordpress/wordpress-how-to-easily-make-an-admin-panel-for-a-plugin.html</link>
		<comments>http://anthologyoi.com/wordpress/wordpress-how-to-easily-make-an-admin-panel-for-a-plugin.html#comments</comments>
		<pubDate>Mon, 19 Mar 2007 16:42:01 +0000</pubDate>
		<dc:creator>aaron</dc:creator>
				<category><![CDATA[WordPress]]></category>
		<category><![CDATA[admin panel]]></category>
		<category><![CDATA[how to]]></category>
		<category><![CDATA[HTML]]></category>
		<category><![CDATA[Plugins]]></category>

		<guid isPermaLink="false">http://anthologyoi.com/wordpress/wordpress-how-to-easily-make-an-admin-panel-for-a-plugin.html</guid>
		<description><![CDATA[I find the Admin panel the most tedious part of plugin development&#8211;even the slightest changes to the plugin requires major changes to the Admin panel, and it can be hard to remember every option you have in your plugin. However &#8230; <a href="http://anthologyoi.com/wordpress/wordpress-how-to-easily-make-an-admin-panel-for-a-plugin.html">Continue reading <span class="meta-nav">&#8594;</span></a>]]></description>
			<content:encoded><![CDATA[<p>I find the Admin panel the most tedious part of plugin development&#8211;even the slightest changes to the plugin requires major changes to the Admin panel, and it can be hard to remember every option you have in your plugin. However by following a few simple rules, your next Admin panel will be a breeze. Once you have the basic parts down, new options are just a cut and past away. One thing to note is that his Admin panel uses a few features that are best if repeated inside your plugin itself. </p>
<p><em>Please note that these same general techniques work outside of WordPress also; the only thing that you would need to do is to change the way options are actually set. Also, I assume you already know HTML; this is not a basic HTML tutorial, but rather is a way to do a specific task. Some basics 	are explained, but if you don&#8217;t already know the difference between a checkbox and radiobox this isn&#8217;t the best place for you to start. </em></p>
<p>There are rules for the easiest Admin panel. </p>
<ol>
<li>Always name your variables the same ways in the form and the database&#8211; there is absolutely no reason to have to change the name&#8217;s assign to variables individually. Especially seeing as this tutorial shows you the easiest ways to set all variables, and it requires the names to be the same. </li>
<li>Always use arrays for your variables in both the form and database&#8211;you don&#8217;t want to spend a lot of time in your code pulling individual items from the database and assigning them to names, nor do you want to fill the users database up with a lot of individual options. You can, however, assign individual options to some variable such as $background inside the functions, but it is easiest just to leave all the options in a single array ($my_plugin['background']) that doesn&#8217;t change from function to function.</li>
<li>Always make your variable names sensible. If you can&#8217;t figure out what it does just by looking at the variable name it is useless. EX. If I want to set an option for the background color any of the following would be good names: background_color, back_color, bkgrnd_clr, backgroundcolor. backcolor etc. These names all make sense however if you were to use back, color, bc, monkeys, x, gqyjkl it is difficult to understand or remmeber exactly what it does. Furthermore, obvious meanings in your options make it easier to update the plugin later with more options. For example, if I set the background color with the option named color what will happen when I decide to give a new option for foreground color, border color, and text color? Not only can you net tell immediately which option color sets, but in CSS color means text color not background color. Why not &#8216;bc&#8217; you may ask, well it is nice to save the shortest abbreviations for other things (as demonstrated in the radio and checkboxes settings), or for inside the actual code.</li>
<li>Never use words as the values for individual checkboxes- individual checkboxes are useful for on or off statements, so it is perfectly simple to use the values 1 and 0 for checked and unchecked respectively.</li>
<li> Try to use numbers as values for radio boxes whenever possible&#8211; sometimes it is too confusing to remember what the difference between 4 and 2 is when it comes to the actual code, so when you have to use strings as the values make them short (use the rules above) but descriptive (ex &#8216;student&#8217;,'teacher&#8217;,'admin&#8217;,'gen_staff&#8217;). </li>
<li>Text boxes are for text &#8212; don&#8217;t expect your user to only input the options you suggest. If you require that one of a few option is selected use a checkbox, radiobox, list or dropdown list, otherwise you will have to perform a check every single time a user inputs a value.</li>
<li>Administrative panels are for administrators; because of this, you don&#8217;t have to worry about abuse usually. If you give a radio box with the options 1, 2, and 3, you don&#8217;t have to check to make sure that only one of those options was selected. However, when using any sort of checks always check for all but one of the possible values (see radio boxes section) and then just use an else statement to default to one. </li>
<li>Unless the option with the value 0 is meant as false, don&#8217;t start radio boxes from 0&#8211; doing this doesn&#8217;t make any sense.</li>
<li>If your Administration panel is more than a few options long, separate it from the rest of the plugin. Otherwise, the entire thing has to be read into memory every time a page is loaded.</li>
</ol>
<p>There are a few basic rules that we use in this Admin panel (and our plugin). </p>
<ol>
<li>Globals are our friend. By using global variables we make it very easy to access information from any part of WordPress, and can even allow other plugins to interact with our variables. Globals also allow us to get the information only a single time from the database and then reuse it over and over<br />
again. Just as a reminder globals should be named uniquely. It may make sense for your plugin to use the global $post, but if you do so neither WordPress or your plugin will work as expected.</li>
<li>This Admin panel uses one global array to store all of the options ($mypluginall) and one array for for the options when submitted (myplugin).</li>
</ol>
<p>Of course we need to tell the plugin that there is an Admin panel. The following is just an example, if you would like to learn what it all means, then please visit <a href="http://codex.wordpress.org/Adding_Administration_Menus">the WordPress Codex page dedicated to it</a>.<br />
<pre class="brush: php">add_action(&#039;admin_menu&#039;, &#039;myplguin_menu&#039;);

function myplugin_menu() {
	// Add a submenu to the Dashboard:
	add_submenu_page(&#039;post.php&#039;, &#039;My Plugin Managment&#039;, &#039;My Plugin Managment&#039;, 8, &#039;myplugin/myplugin_admin.php&#039;);
}</pre></p>
<p>Before we create any options we should create the function that sets them (this way we can test it as we go along). The following function I developed makes it very easy to update the options. There really isn&#8217;t much to explain, but by taking advantage of the rules above, it takes an array of values and their names (keys), and translates it into the options for the plugin. We could have this as part of the admin panel, but ti is much clearner if we seperate it. I&#8217;m not going to go to in depth into how it actually works, but it goes throug hall of the values ($options) we passed to it (the new options) finds the name of the option ($option) and its corresponding value ($value). it then adds these same names and values to our global array of variables. This is the reason why we have the same names in our form and our database. If we didn&#8217;t, we would have to specifically set map each form option to the database option (cat to dog, background_color to back_color etc). The entire array is a global so it automatically updates the options before they go into the database.<br />
<pre class="brush: php">function myplugin_update_options($options){
global $mypluginall;
//This is the section where we add individual rules to single options (see checkbox part.)

// End that section.
	while (list($option, $value) = each($options)) {
// this line here just fixes individual server bugs.
// If our user has magic quotes turned on and then wordpress tries to add slashes to it we will have everything double slashed.
		if( get_magic_quotes_gpc() ) { 
		$value = stripslashes($value);
		}
		$mypluginall[$option] =$value;
	}
return $mypluginall;
}</pre></p>
<p>This part goes at the top of our administration page. It checks if we just set some options (line 1), then passes the new options on to our function above for processing (line 2), and finally updates the options in the database. Because we were smart and used a global array for our values, we can continue loading the form without pulling the new values out of the database again.<br />
<pre class="brush: php">if ($_POST[&quot;action&quot;] == &quot;saveconfiguration&quot;) {
			$mypluginall = myplugin_update_options($_REQUEST[&#039;myplugin&#039;]);
			update_option(&#039;myplugin&#039;,$mypluginall);
			$message .= &#039;My Plugin Options have Been Updated.&lt;br/&gt;&#039;;

		//$mypluginall doesn&#039;t need to be updated because it has the new values added to it immediately

	echo &#039;&lt;div class=&quot;updated&quot;&gt;&lt;p&gt;&lt;strong&gt; Updated &lt;br/&gt; &#039;.$message;
	echo &#039;&lt;/strong&gt;&lt;/p&gt;&lt;/div&gt;&#039;;
}</pre></p>
<p>Now for some things we will need to set default values, or process the values in some way before the form sees them. In these cases we would add them before the form, but after the update option function.</p>
<p>This section is the panel itself. It doesn&#8217;t require much explanation because it is just a basic form, but this is where we will put the actual inputs.<br />
<pre class="brush: php">echo &lt;&lt;&lt;block
	echo &#039;&lt;div class=&quot;wrap&quot;&gt;&lt;fieldset class=&quot;manage&quot; style=&quot;width:100%; text-align:center;&quot;&gt;&#039;;
	echo &#039;&lt;form method=&quot;post&quot;&gt;&#039;;
	echo &#039;&lt;table width=&quot;90%&quot;&gt;&#039;;
	&lt;tr&gt;
		&lt;td colspan=&quot;2&quot;&gt;&lt;strong&gt;Edit My Plugin Configutarion&lt;/strong&gt;&lt;/td&gt;
	&lt;/tr&gt;

	&lt;tr&gt;
		&lt;td colspan=&quot;2&quot;&gt;&lt;p&gt;&lt;strong&gt;Post Options&lt;/strong&gt;&lt;/p&gt;&lt;/td&gt;
	&lt;/tr&gt;
block;

// Inside this block add all of your options.
echo &lt;&lt;&lt;block



block;
	
	echo &#039;	&lt;/table&gt;
			&lt;input type=&quot;hidden&quot; name=&quot;action&quot; value=&quot;saveconfiguration&quot;&gt;
			&lt;input type=&quot;submit&quot; value=&quot;Save&quot;&gt;
		&lt;/form&gt;
	&lt;/fieldset&gt;&#039;;</pre></p>
<p>Setting Default Options</p>
<p>Code to use for checkboxes, radioboxes, textareas, selectboxes and text boxes. </p>
<p><strong>To add a TextBox:</strong></p>
<ol>
<li>The text box is the easiest of all the HTML inputs: (this one is named &#8216;title_text&#8217;)<br />
<pre class="brush: php">&lt;tr&gt;
	&lt;td&gt;My plugins title text:&lt;/td&gt;
	&lt;td&gt;&lt;input type=&quot;text&quot; value=&quot;$mypluginall[title_text]&quot; name=&quot;myplugin[title_text]&quot;&gt;&lt;/td&gt;
&lt;/tr&gt;</pre></li>
<li>Because a user might use a quote (&#8216;) or double quote(&#8220;) we need to add the following text to the &#8216;set options&#8217; portion of the admin panel. This code makes whatever the default value be valid HTMl that won&#8217;t break our plugin by encoding HTML special characters like &amp;, &lt;, $gt; etc.<br />
<span class="inline-code">$mypluginall[&#039;title_text&#039;] = stripslashes(htmlspecialchars($mypluginall[&#039;title_text&#039;],ENT_QUOTES));</span></li>
</ol>
<p><strong>To add a single checkbox: (best for on or off options)</strong></p>
<ol>
<li>We first add a checkbox to the admin panel table with the name &#8220;say_yes&#8221;.<br />
<pre class="brush: php">&lt;tr&gt;
		&lt;td&gt;Would you like me to say yes?:&lt;/td&gt;
		&lt;td&gt;&lt;input type=&quot;checkbox&quot; value=&quot;1&quot; $sy name=&quot;myplugin[say_yes]&quot;&gt;&lt;/td&gt;
	&lt;/tr&gt;</pre><br />
Did you notice the $sy inside the input?  In basic HTML to check a checkbox we have to add the attribute checked=&#8217;checked&#8217;, but if we don&#8217;t want it checked we can&#8217;t add this input. If we were to leave the attribute checked=&#8221;checked&#8221; out the cjkebox would always be blank no matter what option was selected, but this is bad for usability. So to set the default option we do the following:.  </li>
<li>Because the initial value of the checkbox isn&#8217;t as simple to set a textbox, we then add the following in the &#8216;set options&#8217; section of the admin panel. Notice that we set the variable $sy to be  &#8216;checked=&#8221;checked&#8221;&#8216;. As said above this is how we tell the browser that this option should be selected by default. The best thing about this is if the option isn&#8217;t checked (does not evaluate to 1) the $sy is just empty which means the checkbox isn&#8217;t checked .  The name $sy does not mean anything it could just as easily be named $the_monkey, but t makes it a lot easier because it is just an abbreviation of the option name &#8220;say_yes&#8217;.<br />
<pre class="brush: php">if($mypluginall[&#039;say_yes&#039;] == 1){ $sy = &#039;checked=&quot;checked&quot;&#039;; }</pre>
</li>
<li>The checkbox is unique because of the way it sends its data. If the checkbox is selected it sends data, but if it isn&#8217;t selected it doesn&#8217;t send anything. This can cause a problem when we are updating the options if you don&#8217;t check if the option is set first. To fix this behavior we just add the following to the update options function.<br />
<pre class="brush: php">if(!$options[&#039;say_yes&#039;]){$options[&#039;say_yes&#039;] = 0; }</pre></li>
</ol>
<p><strong>To add multiple radioboxes:</strong></p>
<ol>
<li>We first add the radioboxes to the admin panel table with the name &#8220;fav_num&#8221;.<br />
<pre class="brush: php">&lt;tr&gt;
		&lt;td&gt;Which of these is your favorite Number &lt;/td&gt;
		&lt;td&gt;
&lt;label&gt;My Favorite Number is one :&lt;input type=&quot;radio&quot; value=&quot;1&quot; $fn1 name=&quot;inap[fav_num]&quot;/&gt;&lt;/label&gt;&lt;br/&gt; 
&lt;label&gt;My Favorite Number is two :&lt;input type=&quot;radio&quot; value =&quot;2&quot; $fn2 name=&quot;inap[fav_num]&quot;/&gt;&lt;/label&gt; &lt;br/&gt;
&lt;label&gt;My Favorite Number is three :&lt;input type=&quot;radio&quot; value =&quot;3&quot; $fn3 name=&quot;inapfav_num]&quot;/&gt;&lt;/label&gt;
             &lt;/td&gt;
	&lt;/tr&gt;</pre><br />
Did you notice the $fn1,$fn2, $fn3  inside the input? This is done for the same reason as $sy is done above.  As with checkboxes the  In basic HTML the attribute checked=&#8217;checked&#8217; means that that raadio box is the defaut.  So to set the default option we do the following:.  </li>
<li>Because there is are more than one possible initial value for this radiobox (1, 2 or 3) , we have to use a larger statement to decide which one is set. As above we then assign the attribute checked=&#8221;checked&#8221; to one of the three variables and leave the other two blank.<br />
	<pre class="brush: php">if($mypluginall[&#039;fav_num&#039;] == &#039;3&#039;){
		$fn3 = &#039;checked=&quot;checked&quot;&#039;; 
	}elseif($mypluginall[&#039;fav_num&#039;] == &#039;2&#039;){
		$fn2 = &#039;checked=&quot;checked&quot;&#039;; 
	}else{
		$fn = &#039;checked=&quot;checked&quot;&#039;; 
	}</pre><br />
You will notice two things about the above example: the numbers count down and option one is the default. Both are by personal taste. I always have option one be the default so it makes more sense to look for the others first (and coujnting 3,2,1 makes more sense then 2,3,1), so that way if the other values are not found it defaults to one automatically. However, it doesn&#8217;t matter which order you do it it in as long as the default value comes last and is not specifically checked for.
</li>
<li>Because we always set a default value there is always some value sent with a radio box (unless the user specifically tries not to), so we don&#8217;t need to add a check as we did in step three of the checkbox.</li>
</ol>
<p><strong>The Text Area</strong></p>
<ol>
<li>The text are is basically the same as the textbox, but it allows multiple lines of data (this one is named list)<br />
<pre class="brush: php">&lt;tr&gt;
	&lt;td&gt;List of my favorite things:&lt;/td&gt;
	&lt;td&gt;&lt;textarea  name=&quot;myplugin[favthings]&gt;$mypluginall[favthings]&lt;/textarea&gt;&lt;/td&gt;
&lt;/tr&gt;</pre><br />
Notice that the textarea uses a different format for its input. Specifically, it does not start with input and its default value goes between two tags rather than in a attribute named value.</li>
<li>For the same reasons as the textbox we add the following in the set options section of the Admin panel.<br />
<span class="inline-code">$mypluginall[&#039;title_text&#039;] = stripslashes(htmlspecialchars($mypluginall[&#039;title_text&#039;],ENT_QUOTES));</span></li>
</ol>
<p><strong> The Select Box</strong></p>
<ol>
<li>The select or drop down box is the single best argument for using descriptive names.  This is because we can either just add an extra option to it to set the current value, or we can do a loop, and check each option individually before we set them. The latter is a complete waste of coding time and memory and you will have to define an array of possible values etc etc, so I prefer to just add a default option. This is named &#8216;fav_color&#8217;<br />
<pre class="brush: php">&lt;tr&gt;
	&lt;td&gt;What is your Favorite Color:&lt;/td&gt;
	&lt;td&gt;&lt;select name=&quot;myplugin[fav_color]&quot;&gt;
		 $fc
		&lt;option value=&quot;red&quot;&gt;Red&lt;/option&gt;
		&lt;option value=&quot;orange_red&quot;&gt;Orange Red&lt;/option&gt;
		&lt;option value=&quot;orange&quot;&gt;Orange&lt;/option&gt;
		&lt;/select&gt;&lt;/td&gt;
&lt;/tr&gt;</pre><br />
as you can see the values are fairly attractive, with a little manipulation the values can also be used as the displayed text. $fav_color will be our default value.</li>
<li>You get the drill, the following is added to the set options section of the Admin panel. However, we do a few manipulations to the name to make it look good.<br />
<pre class="brush: php">if($mypluginall[&#039;fav_color&#039;] != &#039;&#039;){
	$fc = &#039;&lt;option selected=&quot;selected&quot; value=&quot;&#039;.$mypluginall[&#039;fav_color&#039;].&#039;&quot;&gt;&#039;.ucwords(str_replace(&#039;-&#039;,&#039; &#039;,$mypluginall[fav_color])).&#039;&lt;/option&gt;&#039;;
}</pre><br />
No matter what value is set we a re going to have a duplicate value, so the least we can do is make it look nice, but this part is optional. The str_replace removes any underscores in the values and males it a space and then the ucwords makes the first letter of each word uppercase to make it match the preset values&#8211;we could also use ucfirst to make only the first letter an uppercase. </ol>
<p>That is pretty much it. As a final note this administration panel isn&#8217;t perfect, but ti will make your life a lot easier. Before developing this system it was extremely irritating to add  even a single option. I wouldn&#8217;t do it unless I had no other choice, but now it literally takes a few seconds to add 3 or 4 new options by using the same templates and just changing their names and descriptions.</p>
]]></content:encoded>
			<wfw:commentRss>http://anthologyoi.com/wordpress/wordpress-how-to-easily-make-an-admin-panel-for-a-plugin.html/feed</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>

