Sayontan Sinha is a technology strategy consultant living in Houston, Texas. Coding is his hobby, as are philately, numismatics, classical music, creative writing and quizzing. He is the author of numerous pieces of WordPress software, including the ultra-popular Suffusion WordPress theme and the versatile Photonic (for Flickr, Picasa, Smugmug and integration) and FontMeister.

Apr 182019

In version 2.24 of Photonic I had introduced a change to the behaviour for handling the filter attribute for Google Photos. The change I had made would internally make calls to Google so that all listed albums would get fetched. I have generally been against such automated calls, as they tend to hit API rate limit issues. As if to validate my resistance to making this change, quite a few users reported that they ran into issues.

To remedy this I released version 2.25, which keeps this “chaining” behaviour off by default but lets you turn it on via Photonic → Settings → Google Photos → Google Photos settings → Chain queries.

Version 2.25 also puts some optimization in place for regular admin pages, which seemed to be getting all the Photonic scripts loaded.

Apr 092019

I have released version 2.24 of Photonic. This is a minor release with some mid-size changes:

  1. Improved Google Photos behaviour
    Google has the worst-in-class limits on how many photos and albums you can retrieve in one shot, and Photonic has a policy of not making calls to get the remainder of the photos in an automated manner. The challenge this was presenting was that if a user was passing the filter attribute to get a filtered list of albums, and if the albums are old, Photonic’s logic would fail to fetch any albums. I have modified this functionality so that if you explicitly provide a list of albums, Photonic will fetch all of them. Bear in mind that if you pass too many albums to the filter, your server will reach a request length limit, so use this with caution!
    I have also added the capability to control what to show for the title (really, whether or not to show the title) under Photonic → Settings → Google Photos → Google Photos settings → Photo titles and captions.
  2. There was a bug where the shortcode builder was requiring a SmugMug API key. This shouldn’t be happening any longer.
  3. I added a little piece of optimization code to the editor, where, if the Classic Editor’s visual mode is not active, a JavaScript template will not be loaded.

Hope you enjoy this release!

Apr 022019

It has been almost 4 months since Gutenberg was released (on 6th December 2018) or foisted upon unsuspecting users, depending on your point of view. I had posted about it on my blog earlier as well as on the WordPress Reviews section, but I did want to revisit it now that I have had some more time to spend with it.

The Good

As I had written earlier, I was very happy that it was bringing some native layout features to WordPress. I was always very frustrated with the fact that there was no native way to do landing pages in WordPress, and users had to rely either on their themes or on shortcodes or on block-builders. To that end I had provided “Custom Layout” templates with Suffusion almost a decade back (still in use on one particular page on this site), and had used Beaver Builder with TwentySixteen on one of my sites and Elementor on another page on this site.

With Gutenberg finally becoming available I removed Beaver Builder and Elementor from their respective sites and managed to bring down page load speeds across the sites. Now, loyal fans of those plugins might point to the versatility of those plugins, and while I don’t dispute that, I was really using them for something very simple that didn’t need me to add the bloat to my pages. Of course, one of those sites uses BuddyPress (another piece of obscenely bloated software), but that is a necessary evil for the moment.

Was the transition quick? In a manner of speaking, yes. I was able to get each of the pages switched over in about a couple of hours each.

Was it easy? Hell, no! Gutenberg is woefully behind the times in terms of several core areas, primarily responsive design. I am mainly using it for one thing: multiple-columns. And in spite of adding a 33 KB stylesheet to every page on every site using Gutenberg you need some additional CSS to make sure that your columns don’t get squeezed too much on smaller widths. The fact that I was able to get the switches done in a few hours was mainly down to my knowing exactly what I wanted to do.

The Bad

Apart from what I have written above, Gutenberg makes very poor use of space. Having worked with code for more than half of my life, regardless of editors I find myself moving to use raw HTML several times. Now consider this:

  1. If I am designing a page that is 960px wide, Gutenberg first clamps it down to 610px, so I lose 350px of space, or more than 36% of my desired real estate.
  2. Now if I add a 3-column block to my content, each column becomes just around 200px wide. Take out the padding and margins and you are left with around 150px. That less than one-third the width of most phones today – pretty much pointless in terms of writing area.
  3. Knowing that using a block-based interface is going to add a ton of junk markup (inline styles and the like) to my content, I switch to using a custom HTML block, which, by requirement, needs a fixed width font. And with that, any semblance of readability flies out of the window! I don’t get more than 18-19 characters of text per line!!

Gutenberg’s paradigm is to force users to think visually, and really, the only area where it is suitable is where you have users writing a single column of content (with images thrown in). To that end I see the Gutenberg developers’ point in shouting from the rooftops that Gutenberg is not a page builder. But that begs the question, why would you clutter it up with native “features” such as columns if such features are really unusable in real-life scenarios? All of this contributes to the 33 KB stylesheet.

The Ugly

The “Text” editor is gone. Users of the Classic Editor are probably familiar with the two tabs that show up in the Classic Editor – “Visual” and “Text”. While the “Visual” tab (which uses TinyMCE) is the one that Gutenberg aims to supplant, the “Text” mode has no equivalent in Gutenberg.

Gutenberg touts a “Code editor”, which, from personal experience and from multiple accounts on the web is undiluted garbage. If you accidentally touch the markup of a custom block in the Code editor, good luck editing your post in the block editor after that! The Code editor takes away all the tools you had access to in “Text” mode in the Classic Editor, like the QuickTags (the small buttons that let you do basic markup and add links and images), so you spend a lot of time doing basic markup activities.

This is apparently by design.

In short Gutenberg is a brutal kick in the teeth for any person wishing to work directly with markup.

In Closing

I haven’t gotten to a point of installing “Disable Gutenberg” across the board – I believe that for my use cases of custom layouts Gutenberg is a lesser evil than Elementor or Beaver Builder (it is considerably lighter), so those plugins get the axe. For sites that don’t require custom layouts I am installing “Disable Gutenberg”. For all other sites I am installing the “Classic Editor” with the default editing mode set to “Classic Editor” in “Text” mode.

And if you hadn’t guessed, this post is being written in the “Text” mode of the Classic Editor.

Mar 202019

A common malaise I have seen with multiple themes (particularly those obtained from beyond, such as Divi, Avada and a bunch of ThemeForest themes) is the inclusion of buggy scripts from other sources. Such scripts often cause unintended conflicts with well-coded plugins for no fault of the plugins’.

One issue that had dogged Photonic in the past for several months (while version 1.64 was active) was that of third party themes including Bootstrap tooltips. Bootstrap tooltips conflict with jQuery Tooltips, and the latter ships with every copy of WordPress by default. So a plugin using a native WP script would get caught in the crossfire if it was used with a theme that went rogue. If you think this doesn’t happen, most of the common paid themes in the market include Bootstrap tooltips.

Recently I discovered another such conflict, resulting from the RetinaJS script. This script is included by multiple themes to supposedly help display images at Retina resolutions for Apple devices, though the concept is applicable to any high resolution device. To be quite honest, native support across devices for multiple high resolutions is now quite good, so the script is rather pointless. But as luck would have it, themes have this grandfathered in, and apart from adding more bloat to your page, the script also has an unresolved bug that has been out in the open since 2016. What is worse is that this bug has been reported multiple times but closed by the developer.

Such things generally end up happening to me, and when I introduced the optimization features in 2.21 and 2.22, I pushed the JS for Photonic to the footer. And if the theme has RetinaJS in play, sometimes Photonic’s scripts get loaded after the RetinaJS file, resulting in errors.

I released version 2.23 solely to counter this bug in RetinaJS. As a part of this fix Photonic now has a new option, Photonic → Settings → Generic Options → Generic Settings → Force JS in header when possible. If you select this option in conjunction with the option to Include Photonic JS for non-Photonic Images / Videos, Photonic will effectively get rid of any sort of JS loading optimization and load the JS in the header.

Version 2.23 was made available in the repository last evening.

Feb 282019

I had made a rather uncharacteristic error in the previous version of Photonic, which necessitated a patch so quickly. I have made version 2.22 of Photonic public today with the following changes:

  1. The conditional inclusion of scripts was not working for Gutenberg blocks. This was a careless error on my part, and I have rectified it.
  2. I have added an option to override the conditional inclusion via Photonic → Settings → Generic Options → Generic Settings → Include Photonic JS for non-Photonic Images / Videos
Feb 272019

Photonic Version 2.21 is out. The core focus of this release is performance, and there are several pieces that should help here.

  1. Conditional and Deferred Loading:
    Photonic has two main components on the front-end – JavaScript and CSS. In this release I have ensured that the JS for Photonic gets included only on pages where the plugin is active. Moreover the JS has been pushed out to the footer instead of the header, thereby letting the rest of your code load. I did have to take care of multiple aspects here, which is why this was not done so far.
    The CSS will still continue to be loaded on all pages and in the header, but I have taken steps to reduce the footprint. The reason for the CSS not being pushed out to the footer is because it goes against the W3 Spec for CSS definitions, and it can cause some nasty UI surprises while the rest of your page is loading. The inability to move it out of the header makes it imperative for the CSS to be loaded on all pages, since plugin has no knowledge of whether the shortcode is being used when the page starts loading.
  2. No jQuery UI
    I was using two components of jQuery UI: a tooltip and a dialog box (for password-protected galleries). Unfortunately these came with a lot of baggage. They downloaded a combined total of 8 JavaScript files totaling ~70KB. So in this release I replaced them with plain JavaScript code that took up a total of 5.5KB and removed all the jQuery UI dependency.

    Note that jQuery UI is different from jQuery, and the latter still remains as a dependency. Removing that is a much harder task that will have to be weighed judiciously.

  3. Support for Other Plugins
    I made some tweaks to code to make Photonic play nice with other plugins. Previously Photonic had an escape-hatch (the alternative shortcode), but now, while the escape hatch is still present, you will hopefully have to rely on it a lot less.
  4. Bug Fixes
    The following were fixed in this release:

    1. A mosaic layout bug on small screens was causing photos in the last row to get positioned badly.
    2. The interactive shortcode builder was not able to process authenticated SmugMug calls.
    3. If Colorbox was the lightbox and Photonic was being used as a lightbox for non-Photonic images, it was not working.
    4. On slow connections with the square thumbnail display showing the titles below the thumbnail was causing the titles to appear as a long, narrow column.

Hope you enjoy the performance boost in this release!

Feb 122019

I had to patch the version of Photonic that I released yesterday. Version 2.20 contains the following changes:

  1. A fix for sites running PHP 5.4 and below. Older versions of PHP were throwing a fatal error due to some additional checks that I had put in. You should be able to safely run Photonic on older PHP versions too.
  2. The video_size parameter was not getting passed to the videos nested within an album if you were displaying a group of albums. That should be working now.
Feb 112019

Version 2.19 of Photonic is now available.

One of the big things I had intended for this release was the drastic simplification of authentication for Google. As most users are aware, getting an API key for Google Photos is a lot more cumbersome than newbies bargain for, and authentication is riddled with challenges. The simplification needed Google to approve me as a “Google Photos Partner”. So I followed the process and was granted provisional approval as a partner, however at a later point Google backtracked saying that WordPress users have to download their photos from Google Photos to their WP installations!! This obviously makes no logical sense and violates 3 other core directives they have set, however Google has not responded to any of my repeated follow-ups in this matter.

So I had to scale down my ambitions, nevertheless this ended up being a release with several small things:

  1. RIP Picasa
    About 3 weeks back Google killed off the last vestiges of Picasa by deprecating its API. It is debatable whether the Google Photos API is a better replacement, but it is all we have now. The Google Photos API, while more streamlined, is a lot harder to authenticate, cannot fetch videos and, ironically for Google, sucks at searching. That being said, Photonic has supported Google Photos since July 2018, and the interactive gallery builder should make it easier to build out your galleries once you have overcome the authentication hurdles.
  2. No More API Key for Regular SmugMug Requests
    Most people who use Photonic for SmugMug use it to display their public or password-protected photos. There is good news for them – they don’t need to create an API key any more! What was intended to be in place for Google ended up happening for SmugMug. There is a catch here: if you want to display your private photos, you will need to authenticate … and for that an API key is required. This is because authentication would require me to bundle my API secret with the key, and Photonic being an Open Source application would expose me to risk.
  3. Block Improvements
    1. Gutenberg block “wide-alignment” and “full-width” options are now available for Photonic galleries. Note that the underlying theme has to support these options for them to work.
    2. The interactive block-builder now shows the equivalent shortcode at the bottom for users who are facing Gutenberg conflicts or want to use a shortcode instead of a block while in the Gutenberg editor.
  4. Native Galleries
    1. Performance tracing was causing native WP galleries to not show up if the style attribute was left out. This should be working fine now.
    2. Another issue that has been fixed is that the main_size option was being ignored for the native galleries in favour of slide_size
  5. Miscellaneous Additions / Changes
    1. A few releases back I had significantly streamlined the JavaScript in Photonic. This release I have taken it a step further and minified the scripts by default. You can turn off minification from Photonic → Settings → Generic Options → Advanced → Script Dev Mode.
    2. I have removed the links to the albums and photos for Google Photos, as they almost always point to private locations that cannot be accessed by blog visitors.
    3. Instagram justified grid, masonry and mosaic layouts can now use the tile_size to avoid serving a full-sized image on the main page.
    4. Videos for Instagram, Flickr and SmugMug now display an overlaid “play” icon when viewed as a part of a gallery.
    5. All galleries now get an “end” element to enable linking to the end of the gallery. E.g. if your gallery has an id photonic-instagram-stream-1, the end element will have an id photonic-instagram-stream-1-container-end.
    6. All translation strings have been “escaped” properly. This wouldn’t have caused an issue earlier given that the only translation out there for Photonic was Spanish, but now you have an additional layer of security.
    7. I have added a photonic_helper utility shortcode. The shortcode is eponymous in the sense that it functions the way the Photonic → Helpers page functions. Since the shortcode doesn’t do much, I have provided the documentation in the Photonic → Getting Started page.
    8. I have added options to let users disable the loading of Photonic’s lightbox scripts but continue using the associated JavaScript calls. This will let users load fewer scripts if they have other plugins handling the same lightboxes that Photonic offers.
    9. I have renamed the translation file to photonic.pot from photonic.po.
  6. Bug Fixes
    The following bugs have been fixed in this round:

    1. For some user configurations the more button was not showing up due to end-of-line character mismatches. This has been addressed in the code.
    2. I fixed an issue where the slideshow layout was not respecting the strip-above option.
    3. Safari users were seeing an “empty space” at the bottom of the masonry layout. With Apple no longer making Safari for any platform other than OSX or iOS this was hard to troubleshoot, but it should be working now.
    4. In some cases if PhotoSwipe was the lightbox and the Random Justified Grid layout was being used, the lightbox would start up with an image different from the one clicked. This has been addressed.
    5. I fixed another bug with PhotoSwipe and StripJS where the looping setting was not being respected.
    6. There were some compatibility issues with PHP 7.3, which I have addressed in this version.
Feb 032019

This post essentially marks the end-of-life of support for Suffusion from this website.

The Aquoid Support Forum was the one-stop-shop for Suffusion support as well as for support provided for other plugins I have built over the years. However it was beset by problems, primary among them being the insanely high number of spammers who used to register. Considering that it was on a different platform (phpBB) than the rest of this website (WordPress), it received a different level of attention from the creators of the software. As a result I had moved support for everything except Suffusion to the native WordPress forums. This worked well because I at least didn’t have to worry about managing spammers. Regardless, the forum served as a lifeline for Suffusion users who got to reach out for support after the theme was pulled from the WP repository in June 2016, since that point of time crippled the native WordPress forums for it.

In any case, at this point the energy required to administer the forum is a lot more than I or any of the volunteers can invest, so I am closing it down with immediate effect.

For starters, the forum is still available for browsing, but I have shut down two core things:

  1. User Registration
  2. Posting capability

New users will no longer be able to register there, and old as well as new users will be unable to post to it.

What Next?

There is the GitHub site where I had hosted the last stable version of Suffusion – New users can consider creating issues there. Regular forum contributors Colin and Drake are set up as collaborators on that repository, so they have privileges to release code / patches there.

This will help / encourage users who wish to fork out Suffusion do so from that website.

Closing Thoughts

Suffusion was created at a time when:

  • WordPress was a platform incapable of doing anything apart from very simple blogs. There was no capability to do custom menus, nothing to support custom post types, no post thumbnails etc.
  • The “premium” theme market had multiple players who certainly charged a premium, but failed to deliver very basic features without requiring a developer.
  • The era of page-builders was at least 5-6 years away

Suffusion offered novel solutions for each of the above and all that for free.

The theme remained a pioneer for several years, but with the ever mounting barriers imposed by the WPTRT it became harder and harder to maintain. Every new whim of the WPTRT would mandate a massive change of code for Suffusion (removal of shortcodes, replacement of theme options with the Customizer, removal of custom widgets etc.).

When finally removed from the repository, what I felt was a mix of rage, resignation and relief. Luckily Suffusion had a bulletproof foundation that several thousands of users still found easy to use, and even 2.5 years after removal the theme still manages to stand on its own for the most part. I had hoped that the theme would die down in the months to come, but it has still lingered on, hence rather than shut it down completely I moved it all to GitHub.

I would recommend, though, for users to pick out newer and lighter themes, because the free themes space is a lot more diverse, and WP itself has managed to integrate many of the features of Suffusion in a native manner. Essentially the niche that Suffusion filled for over 5 years is no longer existent, and you might have a more spiffy blog running something else.

Jan 162019

I have just now released version 2.17 of Photonic. The following are covered in this release:

  1. Flickr private albums were not showing up in the interactive gallery builder – this should be working now
  2. There was an apparent conflict with Divi due to Divi overriding some of WP’s native styles. This was causing the WordPress media uploader to disappear behind Photonic’s interactive gallery builder – I have made a change at my end to help out with this

In other news I am working with Google towards making my API key usable by everyone. If I succeed in this, the most complex aspect of Photonic, i.e. creating a Google API Key will go away, dramatically simplifying Photonic’s back-end process.