-
-
Notifications
You must be signed in to change notification settings - Fork 1
Rejected features
Inevitably, some features are considered but rejected. This page documents the ideas we have already considered but decided to not implement.
Asynchronous image generation with a plugin can take place in one of two ways:
- The plugin injects AJAX code (suing com_ajax) to generate the image asynchronously as the page loads.
- The plugin uses a PHP script as the image.
Let's take each option and analyse it.
Social media and chat applications scrape the HTML output of your pages. They don't run your content in a headless browser. Therefore any JavaScript, including AJAX, is not executed. As a result the HTML would include a reference to an image that hasn't been necessarily generated, e.g. if you copied and shared the link target of a page you have not yet visited or one whose image has already been deleted for any reason. This results in a bad experience for the user sharing links to your site.
Regarding images through a script, the first point to consider is that we can't have a random .php file being directly accessible over the web for reasons of security at the very least. This leaves us with two options:
- The image URL is a com_ajax URL e.g.
/index.php?option=com_ajax&folder=system&plugin=socialmagick&imagehash=0123456789abcdef0123456789abcdef - Create the image URL directly e.g. /images/og_generated/0123456789abcdef0123456789abcdef.png. If the image doesn't exist Joomla handles the 404 error which can be captured and used to generate the image.
Each of these two approaches has its problems.
Some social networks (e.g. LinkedIn) infer the image type from the extension scraped from the HTML. As a result they'd never retrieve the image which goes through a PHP script / com_ajax. Using the missing image handling trick works... as long as you are using Apache and have enabled SEF URLs on your site. That is to say, it's not guaranteed that this solution works.
Even if we ignored these problems, the question remains how would the plugin know how to generate the image given the image hash. This would only be possible if every time you loaded a page we went through most of the image generation code — except the actual image generation — and saved the hash, the template name, the overlay text and the extra image path in the database. This requires one or two additional database queries even if the image already exists. This is one to two orders of magnitude slower than checking if a file exists.
In any case, these solutions were unworkable for a generic use case. Image generation the first time you load a page is a superior solution. It only adds 1-2 seconds to the page load time the first time the page loads (or the first time it reloads after you have changed the Open Graph image generation parameters, template parameters, image in the category/article or text to overlay) and a few nanoseconds every time after that. It also works on any kind of site setup, even when SEF URLs are not supported, and with all social networks and chat applications which support social sharing images through the og:image property. Much less headache with a small tradeoff the very first time an image is generated.
The recommended image sizes for every social network may differ slightly. There are three reasons not to implement this feature.
Generating multiple sized images becomes really complicated and resource intensive really fast. You'd have to define social networks and templates to use on each one of them per menu item. The overrides between menu items, categories and articles would have to take these multiple templates into account. Your experience as a site builder or administrator would suffer. The performance would suffer, too. You'd use up too much disk space with the generated images. It's a messy solution.
If you enable caching on your page the plugin events required to generate the sharing image will not be called. Joomla will respond with a cached page. Since you cannot cache by user agent (only mobile vs desktop user agents) you can't serve a different image to each social network. Therefore it'd require you to turn off caching on your sites.
Most importantly, if you define a 1200x640 pixel image in an og:image meta tag most social network platforms and chat applications will be able to resize and crop the image to match their template. If you want to be extra sure use a 1200x800 pixel image and make sure that your important content will be in a 1000x600 area in the middle of the image.
Between a messy interface, bad performance, use of too much disk space, the necessity to disable caching (further hurting performance) and the fact that there is already a solution we felt that this feature made no sense to implement at all.
Our design goal was to provide Open Graph images for core Joomla content. We do not use third party CCKs, page builders etc. We use template overrides and Joomla core custom fields which turn Joomla into a very powerful CCK on its own right. Therefore we felt it is redundant supporting something that's not necessary and would overcomplicate the logic of the plugin.
Third party extensions which do not fall under the content category can already set the title of the page and we can use it. If you want to override this behaviour you can create template overrides and set the socialMagickText and / or socialMagickImage properties in the Joomla application object to set your custom text and image respectively. Therefore you already have support for every possible third party extension using core Joomla features.
If you want to override the template or any other options you'd normally set in the menu item's Open Graph Images tab you can use the following code in your template overrides:
\JMenu::getInstance()->getActive()->getParams()->set('socialmagick.template', 'A Different Template Here');The first parameter of the set method is socialmagick. (note the dot!) followed by the name of a Social Magick option as you can see them in the plugins/system/socialmagick/form/socialmagick_menu.xml file.
Since our code runs onBeforeRender, i.e. before Joomla combines all pre-rendered component and module content in an HTML page, you can use this code in your template overrides. It will execute at the right point in time to override the menu item parameters Social Magick would normally see. No plugins necessary!
Note: this trick may not work for core content Category and Articles because categories and articles CAN override menu item parameters. If you intend to use this trick with core content make sure that neither your categories nor your articles are set up to override menu item preferences.