Posted by & filed under Developer Blog.

I struggled for over a week trying to get my MacBook Pro to connect with the Live Meetings that were happening at work. I’ve been working from home a lot and needing to join the conversation remotely. After searching the internet high and low, it seemed that I kept running into the same dead ends, with people and supposed experts leading me to the same help pages, the same suggestions, and the same lack of results. Nothing worked. “How can this be?” I thought, “everyone providing ‘answers’ seem so sure of themselves and act like I’m an idiot. But it still doesn’t work.”

Well, today I found the answer (though not the solution), and it really boils down to semantics.

If the email you receive with the Live Meeting invite uses terms like these…

  • Microsoft® Office Communications Server
  • I am connecting from outside the network

…or when you try to connect you are getting messages like this…

  • Mac OS X doesn’t recognize Internet addresses starting with “meet:”

…you are in the same boat as me:

You are not connecting to a Live Meeting!

You are actually attempting to connect to a Microsoft Communications Server, which uses the Live Meeting interface for connection. The thing about Communications Server is that it is something installed by your organization and lives inside the firewall. Here’s where it gets frustrating…you cannot connect to Communications Server through the Live Meeting web interface. And, since there is no installable Live Meeting client for Mac, you have no options.

Here’s the explanation I received from a Microsoft Live Meeting support person:

Office Communication Server meetings are hosted on internal servers. If the address for your meeting is given as meet:sip, it is an internally hosted server address, and Live Meeting Technical Support does not have access to troubleshoot or diagnose issues with those meetings. An OCS meeting uses the Live Meeting client as an interface but it is not using the Live Meeting server.

So I recommend you do what I did and tell your meeting organizer that, because you are not on a Windows machine, you will join the meeting by calling in on your phone but that you do not have an option for joining the screen share.

Posted by & filed under Developer Blog.

As web developers, we’ve all heard at least one client or member of corporate management express concern about the design and layout of a site because things are appearing “below the fold.” The concept of the fold seems to make sense at first glance, which is probably why it is one of those myths that just won’t die, in spite of much evidence that disproves it.

In an effort to spread the word and help people everywhere understand the fallacy behind the myth in the most simple way possible, and probably a bit tongue in cheek, I’ve built the website IsTheFoldAMyth.com.

Please enjoy it and share it.

Posted by & filed under Developer Blog.

I think I may have just discovered a major issue with WordPress. It would seem that WordPress is loading two pages at a time, the second loading after the first one has rendered on the screen, the other somehow in the background.

Here’s what I did to discover it. I’m hoping someone else can verify this and make sure it’s not just my environment and that I’m not just plain crazy!

  1. Create a fresh, new WordPress 3.3.1 instance on MAMP.
  2. Turn on WordPress DEBUG logging in the wp-config.php file.
  3. Turn on the permalink structure for “month and name” (http://localhost/fresh/2012/02/sample-post/)
  4. Create at least one extra page than the already generated Sample Page. I called mine “About Us.”
  5. Create a very simple plugin to track the $_SERVER[“REQUEST_URI”] call and send it to the log.
<?php
/*
Plugin Name: mytest
*/
 
add_action('init', 'mytest');
function mytest(){
    if(!is_admin())
    error_log($_SERVER["REQUEST_URI"]);
}
  1. Activate the plugin.
  2. Tail the log file (tail -f Sites/fresh/wp-content/debug.log) in Terminal.
  3. Visit your site and watch the log file. Visiting “Home” only causes the request to fire once, visiting the new About Us page only fires once. But, here’s the strange thing: visit the Sample Page and it fires both the Sample Page and the About Us page.
  4. Create more pages. Watch the logs.
  5. Wonder, “WHY??”

UPDATE: MAMP was the problem. Restarting Apache did the trick. I’m still not sure what caused it, but at least I know the root.

Posted by & filed under Developer Blog.

I was having an issue with my newly created theme not even appearing in the Appearance -> Themes settings page on WordPress. After much searching online I never did find an answer so I’m posting it here.

I did some trial and error of adding and removing files and realized that WordPress not only requires the style.css file to be present, but also the index.php file. I was missing the index.php file thinking I was only using page.php without a blog.

Posted by & filed under Developer Blog.

Update

It looks like there is a fully fledged plugin for accomplishing this feat for both plugins and themes. I recommend using it instead of this hack:
https://github.com/jeremyclark13/automatic-theme-plugin-update

The Problem

WordPress PluginsThe biggest appeal WordPress has is it’s extensibility via plugins. But if you create a private plugin for personal use or for a corporation with a very specific purpose, you may not want to go through the process of having it submitted, approved, and available for the world on the WordPress Plugin repository. So what’s wrong with just hosting your plugin .zip file and providing a link for convenient access? One answer: updates.

When a plugin is installed via the official repository, it will automatically make a call back periodically and check for updates. If updates are available, it will alert the user and provide a link to “update automatically.” With a home-grown private plugin, or a plugin kept out of the official repo. for whatever reason, there is no such lookup and link available. Until now!

(Note: In my testing, this only works on Multisite if the plugin is activated for the entire network.)

Don’t You Just Love Open Source?

The wonderful thing about Open Source products like WordPress, is that you can see how things are working, and make your own solutions for issues like the scenario described above. After a lot of tinkering and investigation I came up with a really easy and simple solution with just 3 easy steps.

Step 1: Host an update file.

Create a plain-text file that contains 2 parts. The first part contains the current version number of your plugin, the second part contains the URL of where your plugin .zip file can be downloaded from. Separate these parts from each other using a simple pipe. Like this:

1.2.3|http://www.mycustomrepository.com/plugins/myplugin-1.2.3.zip

Now you need to host this file somewhere accessible by WordPress. My recomendation is to include this file right within your plugin folder prior to compressing it, and host the folder along side your .zip file. So the URL for the update file in our example above might be:

http://www.mycustomrepository.com/plugins/myplugin/myplugin.chk

Notice that I added a .chk extension on the filename. The extension does not matter here, just as long as the file is saved out as plain text. Using .chk just makes it easy to distinguish. It could just as well be .txt or whatever you want.

Step 2: Include update checker

I have developed a php file that contains all of the code necessary to make this work. You can either copy/paste its contents unchanged into your plugin’s main .php file, or I recommend just adding this file to your plugin folder and require it in your code.

Download gill-updates.php

You will also add some code to your plugin referencing the update check file discussed in step 1, and set a quick variable referencing your plugin.

To accomplish all of this, follow this example at the bottom of your plugin php:
//custom updates/upgrades
$this_file = __FILE__;
$update_check = "http://www.mycustomrepository.com/plugins/myplugin/myplugin.chk";
require_once('gill-updates.php');

Step 3: Host your plugin .zip file in the location you specified above

In our case, you would add the myplugin.zip file to the web host so that it will be accessible at the exact location specified in your update check file. For example:

http://www.mycustomrepository.com/plugins/myplugin-1.2.3.zip

What now?

Once you have completed the steps above you are set to allow your plugin to automatically check for updates of itself. All you need to do when you update your plugin, is edit the update file to a new version. Also, make sure the .zip file it points to contains your new version.For example:

2.0|http://www.mycustomrepository.com/plugins/myplugin-2.0.zip

That’s it! The plugin will now compare it’s current version (specified in the meta information of your plugin) to the version listed in the check file. If the check file number is greater than the number in your plugin, it will provide an “update automatically” link as though it were being hosted in the official repository, and when clicked it will update the plugin automatically with the file specified.

Credit

Ainun Nazieb who wrote a similar post on How to Make Your Own Plugins/Themes Updating Service. Ainun’s post claims it will work for plugins, but there wasn’t any specific information to support that claim. It was specifically related to Themes. This post certainly saved me a lot of work and started me on the right path, however.

The image used above was stolen from Smashingmagazine.com