Two of the key selling points for WordPress Development is “No coding Required” for most of its Themes and Plugins and “there is a plugin for that” based on its huge 45,000+ library of plugins. But the downside of WordPress can be when when plugins which you have relied on suddenly fail to perform. Such has been the case with Google Docs Embedder plugin. It worked very nicely in 2 websites about 2 years ago; but now:
here is the results when I try to load a Word .docx file and a Powerpoint .ppt file using Google Doc Embedder plugin. In the past this has been a reliable way to show not just MS Office files but an array of common file types like Adobe PDF and PSD files. But suddenly, what worked before is not now.
So the first instinct is to check if the new multipurpose theme being used is in conflict with the Google Doc Embedder. So I switch the active theme to WordPress 2016 – and get the same no go results. My colleague suggested that I try the latest and greatest document embedder plugin – Embed Any Document which supports the key Microsoft Office and Adobe PDF and AI file display but does not have the same file reach as Google Doc Embedder. But if it works, then Google Docs Embedder gets unceremoniously dumped. But it does not – failing to display the same files that Google Docs Embedder stumbled on. Plus the Adobe AI and PDF files. So now we have a full bore WordPress debug problem.
WordPress Plugin Debug Process
The first step is to ascertain that we have the latest version of the plugins – check. Next we make sure that the plugins work in version WP 4.7.3 and have been recently updated – GDE-Google Docs Embedder is tested to WP 4.6.4 and last update was 6 months ago; EAD-Embed Any Document is better with WP 4.7.3 compatibility and an update 4 months ago.
So next we start to deactivate one by one the 7 active plugins looking for plugin conflicts – SiteOriginPage Builder and 3 Widget Bundles, Cyclone Slider 2, FooGallery plus WP Edit. One by one we test and find still no display of the documents. So now with the all the plugins turned off including GDE and then EAD alternately we switch the theme to WP 2016 – still NoGo. So now we pour over the documentation and find that GDE recommends using 2003 versions of Office products – effectively DOCX => DOC, XLSX=> XLS and PPTX=> PPT. Still no go with either plugin but EAD is able to display Adobe PDF files but only if accessed from a URL and not the Media Library where the files are normally stored. We also try switching in EAD from the Google Viewer to the Microsoft Online Library – still NoGo.
Worse Media library will not load some of the simplified 2003 versions of Office files. See the screenshot on the left. XLS seems to be the villain of the piece. Perhaps this is because XLS files allow for embedded code.
This is about 2 hours of total debug time so far. So now its time to consider that Media Library may be the source of the problem. So we check the source code using Chrome’s Developer tool and by golly the address in the uploads files used by both plugins is good.
However there is a breakthrough. If we load the files onto the website but outside Media Library , then bingo the documents are displayed properly.
But this is hardly a practical solution because the client is familiar with using the Media library and then transferring the requested file to select users. But now the client must store the files in a directory outside the media library and mange the upload, download, and delete functions himself. All this in order to be able to display the documents instead of just downloading them.
There is an awkward solution using either GDE or EAD, but I want to deliver a simple UX experience for clients needing to display one or more Office or other documents. So a Google search leads me to Code Canyon.
And right away GridPlus plugin looks promising with multi-column designs plus boxed, metro and masonry layouts and the ability to sort/filter based on media categories. But GridPlus does not support display of Office and other document types. But Fivo appears to do so with a simple grid layout and hierarchical media categories support.
Unfortunately the only way to discover how well Fivo works is by investing $24US. As it turns out, setting up the media’s hierarchy of categories is awkward and time consuming. But the coup de grace on lacking effectiveness can be seen in the screenshot on the left. Fivo does not display the documents on screen in a popup popdown. All that Fivo does is deliver a download of the a selected document to your PC. As it currently performs, Fivo is worth $9-12/copy.
Summary
With effort and using an awkward system we are able to display documents stored in the Media Library:
So delivering documents for display using either Embed Any Document or Google Doc Embedder plugins now requires a two step process. First go to the media library and copy the URL of the document you want to display. Then in EAD or GDE use the embed by URL option to display the document until the direct media library selection option is fixed. This is the trade-off using “free” plugins. The response time to support requests can be quite variable. Also users have to be prepared to show lots of context information to the plugin support staff. The Debug-Info plugin provides valuable WordPress context information.
But the bottom line is that when suddenly a favorite plugin misbehaves, just ruling out the possibilities of theme-conflict or plugin-mismatch can take a fair amount of time to work out – 3-4 hours in this case. And if you cannot isolate the problem then finding a work around is the next priority. And how do you bill for the search-for-solution work? Ahh the fun of “no coding required” WordPress. Does this WordPress misbehavior occur often – no; but in the Pixel Perfect world of web design, when it does finding a shiv or fixer becomes essential.
Comments are closed.