Two issues still remain that could, and will most likely, be handled differently, but it is believed that the current methods of dealing with them should suffice for the time being.

One relatively rare problem is in dealing with rows in the wp_options table that do not have option_name values. Although it is possible that some plugins or themes create options without a name, it is more likely that they alter the row’s values incorrectly at some point in their code. Currently the Clean Options plugin uses the option_name values when first displaying the rows, then, if selected, the row contents, and, if again selected, deletes them. When a row in the wp_options table does not have an option_name value an error message is displayed to alert the user of the problem, but does not provide any further information about them or provide a way to remove them from the table.

TO DO: Find a way to at least display whatever information is available about these rows.

Another more common problem occurs when the wp_options table contains an extreme number of “rss_hash” rows. These rows are entered when RSS feeds are cached. Unfortunately, although WordPress does well at entering them into the table, it does not remove them. As the Clean Options plugin gathers the names of every row to display them, this can cause memory and timeout problems when there are an extreme number of them. Earlier changes added code to increase both the time limit and the memory limit, but the plugin author does not believe that simply “throwing more memory at it” is the best solution. The Clean Options Release Candidate version 1.0.0 deals with this problem by providing a way to “blind delete” them. Whereas deleting option rows that a plugin or theme might require is a very bad idea, deleting the RSS cache rows does not appear to cause any problems other than WordPress needing to reload the RSS feed content and re-add those that the blog is currently displaying back into the wp_options table. In this version, the “blind delete”, i.e. “Delete ALL ‘rss’ Options”, is not shown unless the wp_option table contains more than 250 rows total, including both plugin and theme options, and the “rss_hash” options.

TO DO: Find a way to minimize risk of any possible problems that might be caused by the removal of currently active RSS feed rows.
Possible solution 1: Find a way to “batch” the “rss_hash” options into smaller groups to avoid time and memory limit problems while still allowing for a preview of their contents prior to their removal.
Possible solution 2: Find a way to minimize the chance of currently active RSS feed rows from being removed during the “blind delete”. That is, instead of deleting ALL “rss_hash” rows, only delete the oldest, and once the number of them is manageable in terms of time and memory usage, allow for the preview and removal of those remaining.

For more information please visit the Clean Options Plugin page.
This post is for comments, suggestions etc. If you need support for the plugin
- please visit the Mittineague Forums (registration required to post).

Comments regarding the following questions are desired and will be greatly appreciated.
1. Do you feel that the simple “blind delete” is a good enough solution to the “rss_hash” problem?
2. Would you prefer to have the plugin “blind delete” only the older “rss_hash” rows?
3. Or would you prefer to “batch” the rows into smaller groups and preview the contents prior to their removal?

[tags]Clean Options, Plugin, WordPress[/tags]

Again, Create an application folder

And again, Create a model, note* specify words to be a text string

However, this time do NOT Edit the model file. But instead, Edit the migration file, db\migrate\###_create_displays.rb

And then,
Create the table

Populate the table with an entry

Create a controller

Edit the controller file, \app\controllers\displays_controller.rb

Edit the view file, \app\views\displays\index.html.erb

Verify that everything is working so far.

Open your browser to http://localhost:3000/displays and you should see

Edit the unit test file, \test\unit\display_test.rb It should accept a text string entry, should have some text, and not be a numeric entry.

Edit the functional test file, \test\functional\displays_controller_test.rb

Verify that the tests pass

This time you should see*

*On my console the test_words_should_not_be_nil error shows many lines of the trace. Of particular interest is the line

Again, although words was specified as a string, the test_words_should_not_be_numeric test fails.

And without the line

in the model file, the test_words_should_not_be_empty test also fails.

Importantly, the test_words_should_not_be_nil test does not fail, but this time errors. By looking at the log\test.log file we can find

Try

What happened to the default value we specified in the migration file?

Open your browser to http://localhost:3000/displays and look at the view-source, you should see

Summary:
Without adequate data control in the model file, even though the database field was specified as a string, not NULL, and had a default value, it still accepted a numeric value and errored with a nil value. The default value was unused.
Without adequate unit testing, these bugs may have gone undetected until a later stage in the application's development.

[tags]assert, Rails, Ruby, Unit Tests[/tags]

Create an application folder

Create a model, note* specify words to be a text string

Edit the model file, \app\models\display.rb, to ensure that words exists

Create the table

Populate the table with an entry

Create a controller

Edit the controller file, \app\controllers\displays_controller.rb

Edit the view file, \app\views\displays\index.html.erb

Verify that everything is working so far.

Open your browser to http://localhost:3000/displays and you should see

Edit the unit test file, \test\unit\display_test.rb It should accept a text string entry, should have some text, and not be a numeric entry.

Edit the functional test file, \test\functional\displays_controller_test.rb

Verify that the tests pass

You should see

Populate the table with a numeric entry

So what’s going on? When the Display model was generated words was specified as a string, and the db\migrate\###_create_displays.rb file has this in it.

check in the browser again.

Open your browser to http://localhost:3000/displays
There they are

Edit the model file again, \app\models\display.rb, using a simple regular expression to check for the presence of at least one text character.

Run the tests again.

This experience with this very simple application has convinced me of the importance of writing tests. I hope it has convinced you too.

[tags]assert, Rails, Ruby, Unit Tests, validates_presence_of, validates_format_of[/tags]

Again, I used a script that searches WordPress files using regular expressions to find Classes and Functions.
64 PHP Classes and 2,116 PHP Functions were found.

The PHP Classes and Functions of WordPress 2.6

* Note *
The list does not include any found in plugin or theme files as these will differ from blog to blog. Nor does it differentiate between “stand alone” functions and functions that are members of a class, such as the Snoopy functions.

If you know of any functions that are not in the list, please leave a comment so I can modify the regex used to find them.

[tags]functions, WordPress[/tags]

[tags]Masting[/tags]

The w3c validator complained

Sorry! This document can not be checked.
…..
Sorry, I am unable to validate this document because on line 292 it contained one or more bytes that I cannot interpret as utf-8 (in other words, the bytes found are not valid values in the specified Character Encoding). Please check both the content of the file and the character encoding indication.
The error was: utf8 “\xFC” does not map to Unicode

Ideally, if I knew Turkish, I would prefer to replace the characters in the excerpt with similar looking ones. But I don’t. So I wrote a new function and added it to the wp-includes/comment-template.php file.

/**
* replace_non_unicode_chars($comment_string = '')
*
* Hack
* Replaces non-unicode characters that cause validation problems.
* 0-127 range of decimal characters are "universal" and should be OK to keep as is.
* 128-255 range of decimal characters may pass validation but could render inconsistently.
* Other replacement characters (or none) can be used instead of question mark.
* TO DO: look into possibility of using Multibyte String Functions instead.
*
* @param string $comment_string Passed from get_comment_author_link() and get_comment_text()
*
* $author = get_comment_author();
* $author = replace_non_unicode_chars($author); //new line
*
* global $comment;
* $comment->comment_content = replace_non_unicode_chars($comment->comment_content); //new line
*
* @return string The string with upper decimal characters replaced.
*/
function replace_non_unicode_chars($comment_string = '')
{
$cslen = strlen($comment_string);
$valid_str = "";
$upper_decimal = 127;
$replacement_character = "?";
for($ci = 0; $ci < $cslen; $ci++)
{
if ( ord(substr($comment_string, $ci, 1)) > $upper_decimal )
{
$valid_str .= $replacement_character;
}
else
{
$valid_str .= substr($comment_string, $ci, 1);
}
}
return $valid_str;
}

Then I filtered the strings that were causing the validation problems by adding lines to the file’s get_comment_author_link and get_comment_text functions

function get_comment_author_link() {
/** @todo Only call these functions when they are needed. Include in if... else blocks */
$url = get_comment_author_url();
$author = get_comment_author();

if ( empty( $url ) || 'http://' == $url )
$return = $author;
else
$return = "<a href='$url' rel='external nofollow'>$author</a>";
return apply_filters('get_comment_author_link', $return);
}

and

function get_comment_text() {
global $comment;

return apply_filters('get_comment_text', $comment->comment_content);
}

Not the best solution perhaps, but it’s the best I can do for now.

[tags]Encoding, Valid, WordPress[/tags]

What the plugins have in common is that they use buttonsnap. Some had decided to choose between the plugins as to which one they used. But not being content with having to choose, I investigated a bit. Unforunately, I am still a bit of an OOP newbie, and I still do not know exactly what the Fatal Error is, what is causing it, or how. I tried to follow the logic of WordPress plugin activation but got lost in the code. In any case, I did determine that it does indeed have something to do with the plugins using buttonsnap.

A search of the WordPress Plugin directory for “buttonsnap” gives these plugins as a result, but I’m sure other plugins also use buttonsnap. eg. Digital Fingerprint

• JAlbum
• WP Contact Form
• Skype Online Status
• Kimili Flash Embed
• Viper’s Video Quicktags
• Subscribe2

Although I would prefer to have a single buttonsnap.php file instead of redundant copies of it, my “fix” was to hack the second copy. I replaced all references to “buttonsnap” to “buttonsnap2″ in the second plugin’s PHP file and in it’s copy of buttonsnap (renamed to buttonsnap2.php). *Note* perhaps it would be better to use plugin intials instead of numbers, eg. buttonsnap_ja, buttonsnap_cf, buttonsnap_s2, etc.

[tags]Plugin, WordPress[/tags]

The code reads an input file, does some string manipulations, and writes to an output file. This it did. But the resulting output file was not complete, being shorter than it should have been. I remembered some example code that I had experimented with in the past that did not have this problem. I compared the working code against mine. A noticable difference was that the example code had close() lines for the streams. My intuition was that Java would close the streams when they were no longer needed via GC, but I saw no harm in explicitly closing them when I knew they were no longer needed, and in fact thought it to be a “best practice”, so I tried it. Amazingly enough, that solved the problem. It seems that Java was closing the streams before they were no longer needed.

My code has a FileInputStream “fis” that is wrapped inside a InputStreamReader “isr” which in turn is wrapped in a BufferedReader “br”. So I closed them in the order I had instantiated them, innermost first, like so

fis.close();
isr.close();
br.close();

After the string manipulations, the code similarly has a FileOutputStream “fos” wrapped in an OutputStreamWriter “osw” that is wrapped in a BufferedWriter “bw”. But when I closed them like

fos.close();
osw.close();
bw.close();

I got - IOException: Stream closed

For some reason, they have to be closed outermost first. I still don’t thoroughly understand exactly why, but I can sense it has to do with the writing as opposed to reading.

I also experienced stream problems with some code using the JPEG codec. I was getting - TruncatedFileException: Premature end of input file

Without any close() lines, the code didn’t work. With them it worked better, but with the Exception. But after adding flush() lines to the code, also outermost first as it is writing, the problem was solved.

[tags]Java[/tags]

I followed the tutorial’s instructions. Under “Creating a web project from the provided source files”, number 6 states

Notice that the $PROJECTHOME/Midnight/WEB-INF/classes folder is automatically selected as your sources folder. Click Finish. You are prompted to let the IDE delete your class files, because they will automatically be compiled to your project’s build folder when you build the project. Click Delete to let the IDE do this.

The IDE imports your sources, deletes the class files, and creates the Midnight project in the IDE. …

If you look in the IDE’s Project window and go to the WEB-INF -> classes -> com -> midnightcookies -> taghandlers node and expand it, notice that the BundleHelper.java, ButtonHandler.java, ContentHandler.java, and LinkHandler.java files have a little red badge icon next to them. From the IDE Help, the description is

The file needs to be compiled. Either the file has not been compiled or the source has changed since the last compilation.

Right click -> Compile them and the errors for main.jsp and Input.jsp go away

[tags]Java, NetBeans[/tags]

Now that a stable version of phpBB3 has been released, I do plan on upgrading eventually. Working in the MODs will take some time, and with Spring on the way I’ll have to get busy soon if I’m going to get to it before outdoor activities call me away from my computer. Hopefully the new version will prove to be just as SPAM free as the old.
[tags]SPAM[/tags]