To address this, and hopefully preventing others from doing the same, the plugin now requires that delete actions on the menu and icon indexes be confirmed through a JavaScript pop-up.

Keep up the good suggestions!!

To try out the free version go the Free Version WordPress Plugin page.

and for plugin support go to our support forum.

At SAI Digital we use modern development platforms and environments which means we don’t always see and address the same warnings plugin purchasers may see on the wide array of server platforms and configurations they use.

In the latest Free (1.2.2) and Extended Versions (10.1.2.2) of Easy Restaurant Menu Manager, we’ve combed through our code and tried to address these warnings.

If, like most, you haven’t been seeing these warnings, upgrading is not required.

Example, current SAI Digital development environment:

$ lsb_release -a
Distributor ID:	Ubuntu
Description:	Ubuntu 12.04.2 LTS
Release:	12.04
Codename:	precise

$ php -v
PHP 5.3.10-1ubuntu3.6 with Suhosin-Patch (cli) 
(built: Mar 11 2013 14:31:48) 
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies

$ mysql --version
mysql  Ver 14.14 Distrib 5.5.31, for debian-linux-gnu (x86_64) 
using readline 6.2

As requested, there is now a separate print stylesheet that is only displayed on the print view of each menu. This allows you to hide images or add backgrounds and fully customize how the menu prints. The CSS is entered on the Global Settings page on the plugin admin right below the existing dynamic CSS box.

We also clarified what is meant by the “Default” Category. This default was left over from previous development and no longer needed. Now the default category says, “None (hidden)” which more accurately reflects what putting a menu item in the default category actually does.

And to alleviate some stress on the support forum, we modified style.css to more forcibly remove bullet points on ul and li HTML elements. The previous CSS added the directive to not show bullet points; however, many themes conflicted with this and re-added them so we added the !important flag to make the plugin function properly on a wider variety of themes right out-of-the-box.

All three additions are a part of the Free and Extended versions of the restaurant plugin.

Initially we tried to use the cloudservers gem but found that it cannot return Rackspace Generation 2 servers. Unfortunately we did not discover this until after a support ticket was opened with Rackspace.

Here’s a simplified version of what we came up with:

class Server < ActiveRecord::Base

  # List of servers in Rackspace account.
  # Returns errors for API key misconfiguration.
  def self.rackspace_servers
    username = ENV['RACKSPACE_API_USERNAME']
    api_key = ENV['RACKSPACE_API_KEY']

    begin
      servers = []

      # Get Gen 2 Servers from Rackspace region dfw
      s = self.get_server_group(username, api_key, "v2", "dfw")
      servers << s if !s.blank?

      # Get Gen 2 Servers from Rackspace region ord
      s = self.get_server_group(username, api_key, "v2", "ord")
      servers << s if !s.blank?

      # Get Gen 1 Servers from Rackspace region ord
      s = self.get_server_group(username, api_key, "v1", "ord")
      servers << s if !s.blank?

      return servers.flatten.sort{ |a, b| a.name <=> b.name }
    rescue
      return "invalid api key"
    end
  end


  #  Get Rackspace server objects from a specified group
  def self.get_server_group( username, api_key, version, region )
    service = Fog::Compute.new({  
                     :provider => 'Rackspace', 
                     :rackspace_username  => username, 
                     :rackspace_api_key => api_key, 
                     :version => version.to_sym, 
                     :rackspace_region => region.to_sym })
    
    service.servers         
  end

end

Then we iterate through our server objects and send a reboot request based on some internal logic we needed.

# Get Rackspace servers and send hard reboot request if desired.
servers = Server.rackspace_servers
servers.each do |server|
  if server.crazy_logic?
    server.reboot("HARD")
  end
end

Now each restaurant menu you setup with WordPress Easy Restaurant Menu Manager has its own RSS feed. Customers can subscribe to special menus to see changing menu content from their feed readers and other integrations.

Here is a screenshot of a menu using Google Reader. You have the option to turn the feed on or off for each menu. Here is an example of the raw output of the RSS2 Feed.

Keep up the requests and we’ll keep adding features!

This feature has been added to both the free and extended versions of the plugin. To upgrade to the new version, just follow the instructions you used to upgrade from the free version.

Here are the new features for the free and extended versions:

For the free version (v1.0.8), we’ve converted all newline characters to HTML break tags for some fields on output. This means you will be more easily able to control the spacing and formatting of the Menu Description, Category Description, and Item Description fields.

Need more control over the look of these fields?

For the Extended Version of East Restaurant Menu Manager, we have added the WordPress WYSIWYG editor to the description fields for the Menu and Categories, while still converting the Item Description newlines to HTML breaks.

Keep requesting new features and participated on the plugin forum and we’ll keep adding awesome functionality.

Typically, a developer would incorporate the HubSpot API into the web store code natively.  In this case, the client’s web store provider is located in a country many time zones away, making it difficult to solve problems outside of basic web store functions. Additionally, the web store platform does not have an available API that would allow us to easily export data in a computer parsable manner.

As a HubSpot and inbound marketing partner for the client, we decided to bypass the third party development firm entirely by writing scripts to scrape data from the web store and send that data to HubSpot. Today, these scripts are hosted on the server and run daily, automatically scraping and importing data from the previous day’s orders.

This method requires two components: a web scraper, and a script that can push data to HubSpot using their new Contact API.

Web Scraper

The web scraper uses CasperJS to authenticate with the web store through a headless browser, navigate to the recent orders screen, and enter date filters. Our only difficulty was working around the antiquated and non-semantic web store markup to programmatically select the correct buttons and tables. In fact, we assumed writing the scraper would be the hardest part of the project, but we were pleasantly surprised by the simplicity and reliability of CasperJS. We chose to output the data in CSV format to standard out, so the data could be piped to a CSV file on the server, allowing a separate script to feed the data into HubSpot.

HubSpot Contacts API

This part ended up being much harder than it needed to be. HubSpot has made a few changes to their API recently, and we were not sure which parts needed to be used and which parts are set to be deprecated. Initially, we chose to use the HubSpot PHP API Wrapper – haPiHP with the Leads API component. This requires that a custom API endpoint be created on HubSpot, which they call forms. Using this API, data can be posted to the endpoint in key-value pairs, which the form will accept and convert into Leads.

Ideally, the scripts run once a day and post data from the previous day’s orders, but we ran into a problem with the initial post. Since the web store does not have an export function, we had to use the script to access all the data from previous sales. After running the script on a few hundred orders, HubSpot informed us that a Leads were being created by sending us email notifications — over 150,000 of them.

Unfortunately, each email contained a Lead with blank data, so the necessary data was not pushed into HubSpot.  On top of that, the API went awry and left our email provider with no option but to queue all emails from HubSpot. We were not able to communicate via email with them for a few days. At first, we assumed that a job had been corrupted on their end and that there would be no end to the emails. After a phone call with the HubSpot development team, we were convinced that the emails would stop and that we actually needed to switch to the Contacts API and away from the Leads API. We also learned that the Leads API is asynchronous and that the Contact API was not, which would allow us to immediately see if the data was posted correctly. Best of all, there is no email notification when a Contact is created through the Contacts API.

In trying to switch to the other API calls, we found two issues. First, we had been using the custom form API endpoint on a number of projects, and it was unclear whether that part of the API was slated to be deprecated.

After some back and forth with the HubSpot dev team, we learned this:

I would encourage you not to use those endpoints to push data in, unless that data is form submission which you are capturing. If you simply want to sync data in from one DB to the other, I strongly encourage you to use the “add contact” and “update contact” API methods.

The custom endpoints won’t be going away per se, and there are newer versions of that process in the Forms API, but it’s not really the intended use.

So we will continue using the custom form endpoint to push data in until it stops working … per se.

The second issue we encountered was that, of the two API key generators in HubSpot, one of them does not work with the Contacts API, and the other is hidden. In the client’s main HubSpot portal, you can generate a token by clicking:

Your Name → Settings → API Access

The token provided will not allow the use of the Contact API, and the PHP wrapper returns a message that the key is not valid.

After more back and forth with the HubSpot dev team, we learned that the key required can be found by going to https://app.hubspot.com/keys/get. There is no link to this in the client’s main HubSpot portal which was causing a lot of confusion.

Wrapping Up

From here, the process was pretty simple. A Contact will be rejected if it already exists, unlike with the Lead API. We had to implement a simple Create or Update method which looks something like this: HubSpot Contacts API – Create or Update. Once the two scripts were in place on the server, we set a cron job to run the scraper and pipe the output to a CSV. Once that completes, the PHP script runs and pushes the data to HubSpot.

In order to send emails to a dynamic set of users, we found that we needed to add each user to the same, predefined MailChimp list, and then segment that list at send time to send the campaign to a filtered set of email addresses.

Here is some sample Ruby code on how we were able to accomplish this:
Using MailChimp API to send email campaigns to a dynamic set of email addresses

A rake task grabs all EmailCampaigns needing to be sent and calls this member function on each.

Rundown:

• Segment the full predefined MailChimp list to get a segment_id.
• Grab the recipient email addresses from the database. Note, you cannot send to email addresses that are not already on the predefined MailChimp list. We chose to run a separate rake task to continually add new email addresses to that list via the API.
• Add the recipient email addresses from the app database to the segmented list on MailChimp.
• Create a new campaign on MailChimp with the segmented email campaign_id. For our project we used a predefined email template branded by the client so we also needed the content_section id so that we could inject the email body into the correct location in the template (must be prefaced with ‘html_’, see campaign_create).
• Tell MailChimp to send the campaign and save the campaign id for retrieving statistical information later.

Note, this is probably something MailChimp wants you to use their new service Mandrill for.

Links:

• MailChimp API Documentation
• Gibbon API Wrapper

First we’re giving the user control over whether the restaurant menu title gets displayed on the frontend. This was causing some confusion because the menus are usually outputted on a WordPress page that already has a title, which more often than not matches the restaurant menu title. This resulted in the restaurant menu title seemingly being displayed twice, which led some users to leave the menu title blank on the WordPress admin which caused further confusion when they tried to go back and edit the menu and there was no title to click on. Our initial solution was to have users hide the menu title with CSS, but now we have a much easier method.

Secondly, we are allowing WordPress users with the Editor capability to edit the menus. Originally only admins could edit restaurant menus on the WordPress backend but after a solid demand, we have loosened that restriction so that WordPress admins and WordPress editors can manage the restaurant menus.

Both these features are being pushed to the free plugin and extended plugin versions.

The plugin is designed to make it simple for a restaurant owner to maintain their menu, which displays in a format that website visitors can easily read and use.

The Easy Restaurant Menu Manager plugin is available in free and extended versions. In just a few days of being available, the free version has been downloaded more than 100 times from the WordPress plugin directory, and we’re sure the $25 extended version will be a big hit for users who want some extra features.

So what does the plugin do? Here’s a rundown of features in the extended version (a few of these aren’t available in the free plugin):

• Put items into categories like appetizers, entrees or desserts — name them whatever you want — and set the order those categories should display in
• Include a description for each item, and decide whether or not you want to display the price
• Add CSS right from the plugin, without fiddling with theme files
• Attach pictures to each menu item
• Choose single-column or two-column layouts
• Add icons to dishes to show that an item is spicy, vegetarian, a speciality, etc. — even upload your own icons
• Create multiple menus
• Include a “print this menu” link that creates a print-friendly version of your menu

Our staff worked hard to make sure the plugin looks great and functions well in all WordPress themes. It was important that the menu match the rest of the site, using the site’s own colors, fonts and styles.

Click here for screenshots, a live demo and more information about the Easy Restaurant Menu Manager plugin for WordPress, which costs $25 from SAI Labs.