init2null

Depends on the association. With this small association, it's included in the membership, and the $10 signup fee didn't sting too much. Now the MLS providers often have richer, easier options available. For instance, FBS, the maker of Flexmls, has a JSON-based IDX API, but their proprietary API wasn't worth $479/year from our perspective.

Sure, I'd be glad to elaborate. Here's the outline of the update process: Update the MLS, processing each property type and property status individually for flexibility Get layout of RETS parent class (In my case Property) and RETS listing type tables (In my case A, B, C, and D) using GetClassesMetadata and GetTableMetadata Populate list of available MLS entries with only MLS, internal ID, and modification timestamp. $connection->Search('Property', 'A', '(LIST_15=ON6KCGQ87YK),(LIST_104=Y),(LIST_12=2013-06-02+)', ['Select' => 'LIST_1,LIST_105,LIST_87','Limit' => 'NONE']) The LIST_15 part of the query is a filter for status. Sadly, RETS makes heavy use of lookup fields, so you have to find the code for the value you want on the lookup table before you can find the value to use for the query. Fortunately, this is only an issue for field values used in the RETS queries themselves. Delete listing pages that no longer exist on the MLS For each listing without pages or each listing with a changed timestamp { Populate MLS data using data collected by querying for all fields from only the one property Update all photos if the photo timestamp changed (iterate the media using a GetObject -- PHRETS makes this easy) Update all documents if the document timestamp changed (mostly the same as with photos) Precache the resized images of random listings Precache the long-lived WireCache snippets of random listings Aggressively delete unused asset files, including unneeded and obsolete image sizes. 10 GB of photos and documents is plenty. This code also forces a photo update if photos are missing. Delete expired log files Prerender homepage and pages linked from it with ProCache curl -sS `curl -sS https://website.com/|grep -oE 'listings/([a-z]+)/([a-zA-Z0-9-]+)/|quick-search/([a-zA-Z0-9-]+)/'|sed -e 's/^/https:\/\/website.com\//'|sort|uniq` >/dev/null I'm sure there's so much I missed; I'll be doing well if this even makes sense! One thing I didn't cover above is the replay mechanism. If I make a change to RETS value parsing, I can easily run a complete offline update using the cached JSON data from each listing. It's a big timesaver.

Well, as shown in my signature, I've done it. I use a PHRETS-based importer running in a cron job. It really wasn't that hard to write and the code is mostly reusable, but it isn't a module. I'd be glad to elaborate on how I did it if you have questions. I'll say that I'm glad I spent some effort mapping the MLS values to proper ProcessWire fields instead of just saving a JSON dump; the cleanup makes a big difference.

Posted. I hope that I'll be able to supply patches in the future, but this is the best I can do for now. Thanks for the guidance.

Not sure if the bug tracker is better for this or not, but I've definitely found a bug in the Image field when using SVG files. SVGs upload without error and display thumbnails, but they have no trashcan icon and are deleted when the page editor is reopened. Existing files uploaded with the old version of image are not deleted, but there's still no trashcan icon, so they can't be deleted at all. Cropping tools don't make sense for SVGs, but it is nice to have thumbnails and a shared field for all types of images.

ProcessWire and ProCache both run on LiteSpeed with no changes needed.

I've gotten a little obsessed with the page loading time on my latest website. Many of you use AIOM for asset preprocessing, but I decided to use Grunt and htaccess for more control and a lighter server burden. Here are the techniques I used in a random order: For file versioning, I supply distant expiration dates and use this line in my htaccess: RewriteRule ^([^.]+)\.[0-9]+\.([^.]+)$ $1.$2 The file is referenced as "myfile.<?php echo filemtime("myfile.js"); ?>.js", though I do this in a function for additional path translation. MD5 would be another option, but it would take longer. For both Javascript & CSS (first converted from LESS), I first combine the multiple support libraries into one file. I include these files on the server as *.src.*; the templates includes the *.src.* files when the viewer is superuser. I then minify them and include them as *.min.*. I use Grunt to compress them all as *.*.gz and serve them as needed: <IfModule mod_headers.c> # Serve gzip compressed CSS files if they exist and the client accepts gzip. RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}\.gz -s RewriteRule ^(.*)\.css $1\.css\.gz [QSA] # Serve gzip compressed JS files if they exist and the client accepts gzip. RewriteCond %{HTTP:Accept-encoding} gzip RewriteCond %{REQUEST_FILENAME}\.gz -s RewriteRule ^(.*)\.js $1\.js\.gz [QSA] # Serve correct content types, and prevent mod_deflate double gzip. RewriteRule \.js\.gz$ - [T=text/javascript,E=no-gzip:1] RewriteRule \.css\.gz$ - [T=text/css,E=no-gzip:1] <FilesMatch "(\.js\.gz|\.css\.gz|\.svgz)$"> # Serve correct encoding type. Header set Content-Encoding gzip Header set Precompressed true #for debugging # Force proxies to cache gzipped & non-gzipped css/js files separately. Header append Vary Accept-Encoding </FilesMatch> </IfModule> I needed to provide the main script with arguments but wanted to load the Javascript using the async keyword, so I assigned the arguments as global variables and access them when JS finishes loading. I found many ways to use SVG in this design, and I aggressively optimized the illustrations and the generated code. Editing the XML by hand can shave several kilobytes off the file. In one case, I reduced the file size from 40 KB to 4. I also use Grunt to pre-compress it as with the JS and CSS. If you're really obsessive, you can rearrange the SVG attributes for better compression. These may be basic tips for most of you, but I'm hoping they'll be helpful to someone. For anyone interested, I've attached the Gruntfile. I only ask that you don't judge the file structure too harshly. Since I probably haven't scratched the surface here, feel free to provide any of your own tips. gruntfile.js.txt

Hi Mike, Your form has good questions and a reasonable number of them. I have a few random observations, though: I don't know about the table border and the lack of clear textbox outlines. The table borders make it feel more like a paper form; that, along with the font, gives it a more conservative look than I'd expect from a design firm. The lack of outlines make it harder to recognize as a web form; I didn't instinctively know where to type. You may want to at least consider shading the text fields. The all-caps text makes the long labels harder to read. You're assuming that the person contacting you has or represents a business. The phrasing of some of the optional answers might overwhelm the technically-inexperienced inquirers, such as the web address question, and the tone used through the form varies substantially. Some of the phrases seem informal ("As soon as humanly possible", "Yes!"), but this doesn't match the look of the form. When the submitter chooses "Other", a focused textarea should appear below the radiobutton. You might want to consider adding an Other option to more of your questions. Anyway, feel free to take my suggestions, but it looks good as it is.

Very nice. I would have considered this for my last project a few weeks ago. I found theming is too limited for the embedded calendar, so I ended up using a fullcalendar fork on Github that added a Google-style agenda view. Still not ideal, but a rather nice interactive calendar without iframes. It would be worth taking a look at if you're wanting to add more flexibility.