• The WSS 3.0/SharePoint 2007 WYSIWYG editor can’t upload images, video, audio clips and can’t insert Flash files.
  The workaround requires so many mouse clicks and web page interactions, that users look at me like I have “3 heads” when I show it to them.
• Working with tables is difficult, at best
• Any customizations such as:
  • custom file browsers,
  • link management,
  • syntax aware code viewers,
  • and much more

  are difficult to implement

From a Wiki perspective

• Explicit syntax [[]]
• No free form image inserts
• No server side include of other topics.
  Need an easy way to include content from another site. In Foswiki/Twki the %{link} tag can be used
• No easy upload and insert of attachments
• No Easy way to insert links.
  Foswiki/TWiki support WikiWord/Camel Case.
• No tagging
• WYSIWYG support for tables is ugly. You must know the number of rows and columns in advance.
  Foswiki/TWiki support simple “|” character based table definitions and an editable table plugin
• No printable vew
• No export to PDF/Word
• Limited Alerts support.
  Email alerts say something changed and include the full text. However, this can not be customized to tell you what changed. You must login and see the history for that.
  Foswiki/Twiki support a highly customizable WebNotify
• No easy support for multiple top level webs.
  There is only one flat “Wiki Pages” page with list view, no hierarchical view or some sort of sitemap feature.Wikis are made up of Topics that are interlinked in the form of a graph. Hence a specific Tree or Hierarchy structure is not the right representation. However, there must be a way to find all top level topics, i.e. Topics that are not linked to by any other topics. These topics will include
  • the starting points
  • new topics that have been added but not yet organized.

  I could not find a way to do this with this with the SharePoint Wiki. Even a simple way to flag a page as “add this page” to “Quick Launch” would help.

• Not easy to provide a standard footer
  No apparent concept of templates

The “MS/SharePoint 2007″ update approach does not seem to fit into this “revolution”, either. The current approach requires direct access to the servers to install and activate extensions. With “Cloud Computing” and web hosting on the rise; the direct server access approach is not a good match. SharePoint needs something like a Plug-in central for SharePoint. Ideally, this could work on a site level and not require Central Administration be updated first. Another issue for remote management is that “by default” SharePoint Central Administration and SharePoint Sites must run on different tcp/ip ports. I’m sure that if I work real hard I can find a way to run them on the same port using “host-headers”. However, if I do, then will this really be supported or would the next next patch or upgrade break my sites?

So my wish list for SharePoint 2010 starts with:

• A site focused web based upload, install, and management capability similar to that found in WordPress and Plug-in central for WordPress
• A Rich-Text Editor that is rich in function, easily expandable and replaceable.
  Consider integrating a freely available javascript-based Rich-Text Editor for all browsers including IE. My primary choices would be FCKEditor and TinyMCE or TinyMCE Advanved.
• A competitive wiki and blog, without having to buying 3rd party add-ons.

Perhaps Microsoft only wants SharePoint to be a document sharing facility. Maybe I should not be trying to bend WSS and SharePoint into the social media and web 2.0 “arena”. Maybe that “arena” should just belong to Apache, Linux and Open Source.

I checked my “Bad Behavior” log and saw that “Bad Behavior” was reporting that it had blocked 74.125.75.17.  The reason given was “IP address found on http:BL blacklist”.  I determined that this IP address did belong to Google. I ran several more tests and each time the Google Analytics verifier used this IP address and was blocked.

I added the IP Address to my “Bad Behavior” white-list located in directory <blog>/wp-content/plugin/bad-behavior/bad-behavior/whitelist.inc.php and restarted my httpd service. This allowed me to verify Google Analytics.

I use several of Google’s service. This has me considering white-listing all of Google’s IP Addresses. Currently, this appears to be “74.125.0.0/16″ in CIDR format. However, at this time I decided not to do this. One of the main reasons is that would make me trust any computer that accesses the internet from inside of Google. I’m not sure that I’m ready to do this.

Below is my whitelist.inc.php code with the IP 74.125.75.17 white-listed.

<?php if (!defined('BB2_CORE')) die('I said no cheating!');
 
function bb2_whitelist($package)
{
	// DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER!
 
	// Inappropriate whitelisting WILL expose you to spam, or cause Bad
	// Behavior to stop functioning entirely!  DO NOT WHITELIST unless you
	// are 100% CERTAIN that you should.
 
	// IP address ranges use the CIDR format.
 
	// Includes four examples of whitelisting by IP address and netblock.
	$bb2_whitelist_ip_ranges = array(
		"64.191.203.34",	// Digg whitelisted as of 2.0.12
		"208.67.217.130",	// Digg whitelisted as of 2.0.12
		"10.0.0.0/8",
		"172.16.0.0/12",
		"192.168.0.0/16",
                "74.125.75.17",          // Google
                "65.54.233.0/24",       // Microsoft Live
//		"127.0.0.1",
	);
 
	// DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER!
 
	// Inappropriate whitelisting WILL expose you to spam, or cause Bad
	// Behavior to stop functioning entirely!  DO NOT WHITELIST unless you
	// are 100% CERTAIN that you should.
 
	// You should not whitelist search engines by user agent. Use the IP
	// netblock for the search engine instead. See http://whois.arin.net/
	// to locate the netblocks for an IP.
 
	// User agents are matched by exact match only.
 
	// Includes one example of whitelisting by user agent.
	// All are commented out.
	$bb2_whitelist_user_agents = array(
	//	"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) It's me, let me in",
	);
 
	// DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER! DANGER!
 
	// Do not edit below this line
 
	if (!empty($bb2_whitelist_ip_ranges)) {
		foreach ($bb2_whitelist_ip_ranges as $range) {
			if (match_cidr($package['ip'], $range)) return true;
		}
	}
	if (!empty($bb2_whitelist_user_agents)) {
		foreach ($bb2_whitelist_user_agents as $user_agent) {
			if (!strcmp($package['headers_mixed']['User-Agent'], $user_agent)) return true;
		}
	}
	return false;
}
 
?>

My reservations with the existing plugins had to do with modifying code in the theme. Although, I’m more than capable to modify the theme, I did not want to remember to do so every time I changed or upgraded my theme.

When you setup Google “AdSense for Search” on a plain old website, you:

• create a search results page that contains the “Search Results Code” JavaScript that is generated by Google.
• create a search button on the pages of your website, using some more Google generated JavaScript code.
  This is done by placing the “Search Box Code” JavaScript that is generated by Google on the pages of your website where you want the search button to appear.

Much to my surprise, this turned out to have a fairly direct translation to wordpress. It seemed pretty simple to do.

First, I setup my Google “AdSense for Search” which created 2 JavaScript code blocks: “Search Box Code” and “Search Results Code”

Next, I created a search results page for my site. Making sure that my permalink was in the format of http://mysite/search and then in source view I added  the Google generated JavaScript code for the “Search Results Code” from my “AdSense for Search”. This will look something like:

<script type="text/javascript"><!--mce:0--></script>
<script src="http://www.google.com/afsonline/show_afs_search.js" type="text/javascript"><!--mce:1--></script>

Last, I removed the standard wordpress “Search” widget. I created a new Text widget and placed the Google generated javascript “Search Box Code” from my “AdSense for Search” into the text of the new widget. This will look something like:

<form id="cse-search-box" action="http://mysite/search/">
<div>
<input name="cx" type="hidden" value="partner-pub-xxxxxxxxxxxxxxx:yyyyyyyyy" />
<input name="cof" type="hidden" value="FORID:10" />
<input name="ie" type="hidden" value="ISO-8859-1" />
<input name="q" size="32" type="text" />
<input name="sa" type="submit" value="Search" /></div>
</form>
 
<script src="http://www.google.com/coop/cse/brand?form=cse-search-box&amp;lang=en" type="text/javascript"><!--mce:2--></script>

Then I made my new search widget which was named “Text” the first listed widget.

This seems to work pretty well.

Maybe in a future release wordpress will let me give user controlled names to my text widgets. I currently have 3 widgets named Text

1. I manually created the uploads folder in my wordpress wp-content folder .
    
2. I changed the ownership of my wordpress directories and subdirectories to be owned by the apache user and apache group. I should have done this from the beginning to be secure and clean. Shame on me

   chown -Rf apache-user:apache-group [mywordpress base folder]

3. I changed the Selinux security context of the following folders to "httpd_tmp_t": plugins, themes and uploads
   chcon -Rf -t httpd_tmp_t plugins
   chcon -Rf -t httpd_tmp_t themes
   chcon -Rf -t httpd_tmp_t uploads

With these changes I’m able to upload and to run plugin central and save changes to my themes.

As I learn more, I’ll be updating this post.