iCheckRETS is a co-developed project by founder / originator Tony Russo, Gary Little and Jared Ritchey. The project is available free of charge via this blog or on the RETS.ORG website.  What iCheckRETS is designed to do is simply connect to a RETS server, query and then retrieve listings in a CSV formatted file.  Although downloading RETS data in a CSV is the most common method used to date, many developers are opting for a direct DB insert from the RETS data.  iCheckRETS variants are capable of doing this now as I’ve developed a few that were simply used to maintain MySQL tables for Offices and Agents where the data is directly inserted into those tables.

What we have discovered over the past several years is that many users of the iCheckRETS package find setup and configuration confusing so we set out to build a relatively simple visual interface where all settings are stored in a database table as opposed to an XML file.  The furtherance of this development is due to be wrapped up sometime in the next few weeks and will be available free of charge.  Anyone competent with setting up SQL queries can easily navigate to the documented areas of the script to fill in the blanks so to speak. An example is laid out in the source code that connects to a simple database on the client side and the Variaman RETS server over on vieleRETS.org

I’ll keep you posted!

iProperty is a product developed by Tim and Vince Kramer at The Thinkery designed to put real estate listings into a Joomla website with relative ease.  vieleRETS has been used on numerous projects involving iProperty websites and due to the demand for RETS integration into iProperty – the people at vieleRETS are adding a new schema specifically for iProperty users.

vieleRETS has mapping schemas for Open-Realty, Orodha, CSV and SQL and they are expanding the code to map iProperty and possibly the Interactive Tools listings manager. Like a television commercial there is always a “But Wait, if you act now, something else will happen blah blah blah…” as you will see. After a brief discussion with the top dog on the project, he revealed to me that vieleRETS is planning to publish a database model for real estate websites as a pre-defined structure that can be easily modified by developers who build real estate web sites.  This new turnkey model will be based on years of experience in building real estate websites and will include all tables and data fields necessary for a modern real estate website.  I wont go into the tables at this time but any developer looking at them would be quite pleased that the bridge between RETS data and a good RDB structure is being built.

How cool is that? vieleRETS, the easiest to use of all RETS tools available for the PHP platform is going to provide foundation code for building custom real estate websites. Naturally such code does not replace any of the turnkey applications on the market but it does provide a foundation for custom projects.

Once the generated code is completed, building the inserts takes the balance of the time but its not nearly as tedious as the mapping and configuration part in any project. As a result I’m able to bring the price of mapping down to about $100 to $150 per class on average.  So if your typical MLS RETS feed has 5 classes (Residential, LotsLand, Multifam, Commercial, Rentals, etc…) then the price for a full iProperty RETS integration can be about $500 to $750 which has been my average lately. This includes all necessary iProperty mods for adding new fields to the DB, modification of the Language file and then building adding the field data.

I’ve sent the scripts to Mark Curits over at vieleRETS for examination and publishing.  What they do is as follows;

• The first generates code for the property.php file as in;
  $property[$i]->L_Area= $p->L_Area;
  $property[$i]->L_HotSheetDate= $p->L_HotSheetDate;
• The next generates template code for adding fields to the /tmpl/default.php file for example
  <?php if($this->p->L_Area): ?>
  <tr>
  <td class=”key” width=”40%”><?php echo JText::_(‘Listing Area’); ?>:</td>
  <td width=”60%”><?php echo $this->p->L_Area; ?></td>
  </tr>
  <?php endif; ?><?php if($this->p->L_HotSheetDate): ?>
  <tr>
  <td class=”key” width=”40%”><?php echo JText::_(‘Hot Sheet Date’); ?>:</td>
  <td width=”60%”><?php echo $this->p->L_HotSheetDate; ?></td>
  </tr>
  <?php endif; ?>
• The last generates the modifications to the language file
  ##############################################
  # ADDITION FOR MLS FIELDS
  ##############################################
  L_Area=Listing Area
  L_HotSheetDate=Hot Sheet Date
• Number 4 will be the SQL generator for the SQL Modifications

I produced these things to help people save money. Even though I don’t personally believe $600 is a lot of money for a turn key RETS enabled iProperty site, there are Real Estate Agents unable to pay that much when starting out. Why should they not have the same benefits? Well thats my thoughts too, so when clients use these generators it will help reduce costs by 20% when we are contracted to build the MLS scripting for an iProperty project in the future.

iProperty Scripts VIDEO GUIDE

Yeah I have a video, it wont upload to YouTube because its a Captivate Tutorial so I’m having the people at vieleRETS publish it over there.

First, I’m not the developer of iProperty and I don’t have any real bias towards any product in particular. I do believe iProperty and the people who develop it to be very very professional.

Questions;
1) Can you have MLS listings into iProperty dynamically updated daily?
a) Yes!

2) People always ask if they can have categories different than those in the MLS data. For instance, their MLS may have three property classes like, residential, land, commercial and they want to filter for specific property types such as condos, townhouse, etc and have those in their own categories.
a) The answer is Yes! It can be done if the MLS data has the subtypes available and it does not require separate RETS downloads to accommodate most of the time.

3) Can I have amenities from the MLS data appear in iProperty as amenities check mark items?
a) We get asked this a lot. Yes it can be done. We take a column that may have for instance (Cable TV,City Garbage,City Sewer,City Water,Electricity,Natural Gas,Telephone) and each of those items would be items in the amenities area of the site.

4) My MLS doesn’t have latitude and longitude in the MLS data, can I still have google map search features?
a) Yes! We have done this for clients where we geo-code after the MLS data is entered. There are provisions naturally but for the most part it is possible.

5) Can IDX also be added to an iProperty site?
a) Yes! 20% of all integrations we do are IDX.

6) I’m on a shared hosting account and don’t have the room to download several gigabytes of images, what can I do?
a) Three things can be done. You can upgrade your hosting package with your host provider, you can take advantage of the MLS’s media server and directly link the MLS photos, or you can hire people like vieleRETS.org to manage your images for you. I think vieleRETS charges $12 a month to host and manage the images, but don’t quote me.

I hope this helps in answering some common questions, please see the video link below.

A little history on the application may shed more light as to why this upcoming release is so very important. Early on WPRealty was a WordPress plugin that simply bridged two popular open source applications together for nearly seamless integration. The first version of the plugin simply allowed you to install both WordPress and Open-Realty® in order to show real estate listings in your blog, both as posts and pages. After Open-Realty® updated their application to include a blog of their own, it became a bit confusing to end users who tried to draw the line between the need for such an integration. Why use WPrealty if OR includes a blog?

Recognizing that people still wanted real estate solutions for their WordPress blog, WPRealty’s team set out to fork a version of Open-Realty® into a stand alone plugin for WordPress there by becoming the first ever truly real estate WordPress plugin. That statement may offend some even though true since WPRealty suffered substantial bad press and resentment by Open-Realty® supporters hell bent on seeing the application fail. WPRealty was in fact the very first plugin that made the attempt to integrate real estate listings into WordPress almost simultaneously as the now popular “Great Realestate Plugin” was released.

WPRealty changed the approach a bit when it announced that they were migrating completely away from the bridged solution to a fully proprietary GNU/GPL compatible version they hoped to be in 2.5.  Since 2.5 had come and gone, the new code and structure is actually being realized in the version 3 of the application. Unlike the previous versions, the version 3 was tasked to solve several persistent issues with the 2.0 series of the plugin mainly in the area of search engine optimization and ease of use.  Although the plugin was my idea initially my capacity and involvement dwindled overnight as the development team was financed by long time magazine publisher Chad Broussard. My role even today is advisory and interface design related.

Even today, the team at WPRealty realizes that the emergence of so many competing plugins would put such a blur on the market as to which ones is best for each solution; they continue to revamp the structure to accommodate only a few unique business models which I’ll explore in a different post.

Here is a Calendar History of WPRealty

August 15 2007

The very first version was simply a bridge plugin that allowed the publishing of Open-Realty® listings into a WordPress page or post. The solution was first built and tested on two sites that are still in use today. http://napaforeclosures.net and http://lookforcoloradohomes.com In fact those two sites were the motivation behind the development of the plugin in the first place as each site was new both to WordPress and to the market. With SEO foremost on their minds, creating WPRealty was a test in essence to see if listings could be indexed faster if part of WordPress.

Both of the sites above mentioned are using newer solutions now.

November 13 2008

After several refinements I decided to publish it along with 4 other plugins on WordPress for the first time. My motive was of course link bait in hopes people would link back to my site.

June 20 2009

Version 1.0.6 was published to WordPress to solve dozens of bugs and issues including the iframe and CUrl features that broke on some host providers. At this point it was being discussed that the plugin should actually include a fully installable version of Open-Realty® in accordance to their license to save people the headache of having to configure each app to work together. The first versions of WPRealty that included Open-Realty® were released on a few blogs which was quickly received as a favorite among Realtors already using OR since they did not need to relearn the interface. For the next few months, the integration of a forked version of OR was where the development went.

October 10 2009

The first release of the 2.0 series was released and the paid support model was used to raise funds for development. The idea was that you can have WPRealty 100% free of charge where support and guidance would be given in the forums keeping with the OR license. But the paid support model was in increments of usage beginning with entry level support at $30 and moving up from there. WPRealty 2.0 was a night and day different experience from the 1.0 series since bridging was out and integration was the new process as a full forked version of Open-Realty® was added to the plugin keeping in compliance with the OR license naturally.

This is where the public assault on WPRealty began first by an employee of Home Depot named Abner “The Tico” failed multiple times to get the plugin to work in his awkward hosting solution.  WPRealty was already in planning for version 2.0.5 at this point to solve these issues when Abner rallied attacks from his best source of like minded people, the competition. This coupled with dozens of RSS, link, and setup problems, in addition to the lack of documentation was so bad that it lead many to believe WPRealty simply did not work. This was not the case in most instances.

The first true release version suffered horrible bad press and reviews and the team had spent a solid month tracking issues and updating as quickly as they could.  WPRealty early on was likely the most actively developed and updated app of its type. My opinion.

May 17 2010

Jealous of the successful response WPRealty was gaining in the market after multiple bug fixes; the developers of Open-Realty® cried foul ball. It was later discovered that the initial concern the OR people had was that WPRealty was making money for support fully unaware that Open-Realty® was secretly being prepared for commercialization.

Although the license was adhered to accurately, the developers at Open-Realty® felt the confusion between each application was such, that people would not be able to discern that they were not directly affiliated with the plugin and set out to pursue legal action. The assertions made in the claim was that unauthorized use of the Open-Realty® was being abused and that copyright infringement was taking place in addition to other petty and clearly bogus points. This poorly thought out claim essentially stated that the use of the word Open and Realty joined by a hyphen was a registered trademark that the owner thereby wanted any and all use of it on blogs or sites owned by Jared Ritchey and Chad Broussard be removed. In  addition there was demand to stop of further development of WPRealty. Both claims proved to be wishful thinking having no legal merit what soever.

Naturally since the license in Open-Realty® was unchanged since the early versions of the product, the opportunity to fork in compliance to the license was 100% legal to do so long as credit was given where credit was due. Next, people are able to write about programs and companies giving proper disclosure of trademarks so long as you don’t abuse it. Case in point is this very post in which I give proper formatting and disclosure of the OR trademark. Needless to say, the legal threats and countless attacks and extortion attempts by the developers of Open-Realty® quickly died as host providers, developers and even CERN recognized the attempts to be potentially fraudulent as well as malicious and frivolous.

October 2 2010

WPRealty is at version 2.5.6 and has solved nearly every issue that has surfaced from the beginning with new features being added frequently. A new feature recently added was better SEO tools and broad support for canonical URL’s in addition to dozens of short code templates.  WPRealty has moved away from the old support ware model to pursue one that works better by providing a collection of exclusive videos and license models beneficial to developers. More on this later.

Tomorrow – First Quarter 2011

WPRealty has finally tossed any and all Open-Realty® code including the database structure for a totally revamped one. The new DB structure takes into account changes that are on the horizon for the market in general as the team worked very closely with various Boards of Realtors and MLS providers to integrate its own RETS data loader.

The new version of WPRealty which makes a full version jump includes 3 commercially licensed products and much better export tools for things such as XML, SiteMaps and feeds in addition to a full blown client resource manager.  Previously it had been discussed that making WPRealty a CRM would be pointless since the bridging to vTiger or SugarCRM would be the ideal considering they already had the code being implemented.  Keeping the option for bridging available the new CRM features have a great deal more to do with lead conversion than anything else.

WPRealty handles listings management substantially different than its predecessor to better accommodate the multitude of MLS integration methods being employed. The team took all the lessons learned with the 2.0 series and simply made it better.

Over the last 11 months I’ve followed a dozen or so threads related to the subject of IDX RETS and WordPress and have noticed with ever increasing frequency that people expect a one size fits all application to actually exist.  Although there are plugins that will integrate IDX and RETS based on special circumstances there are no existing plug-ins with the capability of fitting the bill for all situations and in this post I wanted to point out the top five reasons why.

No two MLS sources are ever alike.

Thousands of MLS providers, hundreds of service professionals and dozens of software vendors have yet to come up with an easy to implement and globally standardized format. Given all the different types of IDX and RETS services provided by the various boards, I have yet to encounter where any two are ever alike beyond casual similarities. Below I’ll go over mapping and why that stands as one of the biggest hurdles but first I’ll say that to build a plug-in that can address all types of data feeds would not only be daunting, but extremely expensive to build, maintain and even manage.

Here are a few data feed types that such a plug-in would need to take into account.

• Push type data feeds and these include time stamp and even encoded text and csv files that must be decoded before processing. Push means that the data provider will PUSH the data to a folder on your server.
• Pull type data feeds which in addition to the above mentioned will also require scripting for FTP or even an FOPEN URL path to access the data. The limitation here is that the url file include method wont always work as many servers have this feature frequently disabled.
• Media server types which are most often domain locked. This means that you may have a feed, push or pull but some have file and access points that are domain locked. Scripting
• IP locking of access to the various feeds. This includes RETS feeds. Many RETS service providers will domain or IP lock your access to the data. A plugin would need to take into account settings for how it will access the data if it is to be useful in most production sites.
• RETS versions and the differences are not backwards compatible all the claim is that they are. Go to RETS.org and the professionals there will quickly tell you that not all RETS versions are alike. The plugin would need to auto detect the type of RETS version being used and then adjust according to additional settings for actually getting the data. One of my favorite tools is the vieleRETS downloader which is as close as you can get to a globally compliant RETS downloader anywhere. The only issue is that without ideal setting, it can tank a server if not properly configured.
• RETS and IDX are not at all the same. RETS uses an XML wrapper to shake hands and communicate as a sort of translator for lack of a better term between two different databases. In essence if you speak spanish and I speak english the person in the middle doing the translation for us is this thing called RETS and all that it embraces.
• IDX can be in many forms including remote SQL connections to the downloading or pushing of data and photo archives which once extracted would be processed depending on your particular database structure.
• I can go on and on but I’ll stop here by saying its not realistic to believe such a solution could exist at this point.

Hosting for real estate is a unique animal.

Hosting for real estate websites is a real different animal for sure. There are configuration settings required for real estate hosting that almost none of the commercial shared solutions can accommodate. The biggest hurdles in making a plugin that would be able to do all things would have to take into account things like step processing, offset downloads, file splitting, and a hole host of other little things that developers frequently encounter.  When it comes to actually processing the images and other data elements a server setting called the max_execution_time setting plays a role.  MLS scripts can and often will run for several minutes non stop during the database updates. Most servers are not configured beyond 30 seconds for this to take place.

Boards of Realtors Just Say NO!

I’ve encountered boards of Realtors that literally said no to a scripting tool that would be used by the actual website owner. In fact I’ve encountered some MLS providers that wont talk with anyone beyond programmers and IT professionals even if the person contracting the solution is the broker / owner of the company.  Some MLS’s are in the position that leaving such a tool available opens the door for abuse by novice users and would expose their data. I disagree but paranoia is common among many MLS’s still today and their entire policy is dictated by an inventory of precautions.

Compliance isn’t really a reason for not building such a plug-in but I’m calling it one.

First and foremost, if you don’t think the industry is full of hidden loyalties, underhanded competitors and snitches that seek to debunk your every effort you are deliberately indifferent to the truth.  The reason a one size fits all plug-in would be almost impossible to publish is quite literally someone would call foul ball.  Compliance is the number one reason real estate websites run into hot water. Compliance isn’t just about knowing which fields to and not to include as would be expected. Various elements of the data source among other things must be included in compliance disclosure and boards frown on anything that appears to buck the trend.

The issue of mapping the fields.

Last and in some ways the most important. If you have ever opened up an IDX data feed file and looked at how its structured you would likely notice its some sort of delimited structure possibly a CSV comma delimited type.  Mapping a CSV to a database isn’t rocket science but mapping with proper field concatenated values is essential for effective search and display features of the listings data.  In all my years of experience I’d say that mapping equates to 70% of the over all time in any RETS or IDX project. I’ve looked for ways numerous times to reduce this action to something a bit more manageable and have yet to find any that really work much better overall.

So in summary, due to the exhaustive differences between all the MLS data feed types, it would be nothing shy of a seriously expensive effort to develop such a plug-in.  But all hope isn’t lost since there are tools that can be adapted to fit most scenario.

You know, I’ve been in this business almost 9 years, and after considering all my time spent on moding, core hacking, altering, integrating, bridging and every other possible thing to get popular applications to behave with MLS data, I’m pleased to say it wasn’t a wasted 9 years. Out of all that time we have gotten a serious education about the things that can and should be done in the building of Real Estate websites. We, meaning my two programmers, my business partner and I. After all those years of building integrated solutions for Realtor’s using Open Source applications I can honestly say that none quite fit as tightly as I would have liked. The limitations in bridging successfully occupy a lengthy list. Until recently.

Having published real estate plugins and addons for a number of open source tools such as Joomla, WordPress, vBulleting and even open realty, I feel that we have something super powerful this time around that is unique and certainly easy to integrate.But now, we have finally wrapped up our third plugin for use with IDX / RETS type data. With the new release and update to version 2.0 of WP Realty, we achieved several important features that should make the application useful to end users, blog developers, theme publishers and more. We factored in several things in order to be as well rounded as we could in our approach. One of the things I’m most proud of is the support we give to theme developers who we hope to encourage to distribute the project in their theme works. By doing so, we can hopefully solidify what really can be achieved for Realtors when they use the worlds best blogging solution available.

WP Realty 2.0 Announces WP Realty 3.0

WP Realty 2.0 is in the final days of development before our release and already we have bridging and migrating tools planned for yet another fully modified version of this plugin to version 3.0. WP Realty 3.0 however is unlike any we have built in the past in that no only isopen realty completely out of the loop, but the database has been tried and tested to listings exceeding 500k. With WP Realty 2.0 we set the stage for what is to come in WP Realty 3.0 as a fully dedicated or should I say native application designed to work with all that WordPress has to offer and still be able to provide a super clean, light weight and lightening fast listings manager.

Its no secret how we are approaching this as we have written about it in blogs all around the web. The most important feature in WP Realty 3.0 is the database structure, the map and search features, and the template system. All of which is being built from the ground up based entirely on our already proven MLS IDX RETS database integration structure we use in many commercial real estate websites. Saying goodbye to open realty in that regard is a breath of fresh air since all of the code is modern PHP built on object oriented coding fundamentals that truly robust applications follow. I’ll expand on this later naturally but for now, you can follow the project on http://www.wprealty.org and on my own blog at JaredRitchey IDX RETS WordPress