Save disk space?

[crystalenka]

If the template selection, title, or template settings change and a new OG image is generated, the old one stays there.

On small sites that's not such a big deal, but on bigger sites that would add up fast.

Is it possible to remove the old image(s) if one of the above changes?

[nikosdion]

Not really. We'd need to know how the old image is named. Since the template or the text has changed we don't know that.

Solving that would require doing something similar to what SEF components do, i.e. keep a database table with URLs accessed and images generated. In this case, sure, we know the old image's name and can delete it.

If this is something you find interesting / necessary let's add a milestone 2.0 and assign it there.

[nikosdion]

Even if we have a database table we can never really know if we need to delete an old image because any of the following may have changed:

• the menu alias (therefore the URL to the page)
• template name
• template parameters
• the text we use to overlay on the OpenGraph image
• the extra image

As a result I cannot know what would be the old image.

One solution is to convert SocialMagick to a combination of a plugin and a component so that the component can manage the templates in a separate table, allowing us to have an immutable template ID. Combined with a menu item ID and a relative path to the menu item ID's root we might have enough information for most but not all images. However, this is both over-engineered and doesn't work very well.

A better approach is to simply delete old images based on their last access date. If an image hasn't been accessed in over X days we can delete it to save space.

I can make so that this runs over AJAX and only if it hasn't already run in the frequency defined in the plugin. Alternatively, I can let the user disable this pseudo-CRON and provide them with a URL they can schedule themselves.

[crystalenka]

A better approach is to simply delete old images based on their last access date. If an image hasn't been accessed in over X days we can delete it to save space.

I can make so that this runs over AJAX and only if it hasn't already run in the frequency defined in the plugin. Alternatively, I can let the user disable this pseudo-CRON and provide them with a URL they can schedule themselves.

This is elegant. I like it. Default should be something like 6 months, maybe? Anything less than that and it's not really helpful to cache the images on small sites.

[dmitriitux]

@nikosdion you can just save the address on the menu. I am personally worried about the generation happening during page generation. Better to shift it to com_ajax and let it be generated when it will be accessed. source url: index.php?option=com_ajax&plugin=phocaopengraph&group=system&file=msk-serebro&format=raw to: /cache/opengraph/msk-serebro.jpg

And also need to add the language as a prefix or folder so that it works fine on multi languages

You can see my old implementation. I forked Jan's plugin. it was a quick implementation: https://github.com/Delo-Design/PhocaOpenGraphSystemPlugin

[dmitriitux]

I also thought about making a universal plugin. What I forked was a quick fix in a couple of days. I thought it was the component that was needed, and then integration plugins. For materials based on previews and fields, but for hikashop, for example, get an image of a product and display it. At the plugin level, you can also add triggers to call your plugins in the concept

[dmitriitux]

Here is an example sitemap for example. We decided to write our own sitemap, which can be expanded: https://github.com/Joomline/jlsitemap

[crystalenka]

There is already a trigger to apply certain text to the OG image from a template override (or 3rd party component) per the dialogue that shows in menu options. I believe we are also adding the option to specify an image in the template override, which would cover the e-commerce use case. But this particular part isn't relevant to the saving disk space topic of this issue :)

The Ajax stuff is but I'll let Nicholas respond to that comment as I'm not as familiar with the various pros and cons.

[dmitriitux]

saving disk space topic of this issue

I just didn't become a separate issue branch.

I personally do not like the approach with the menu. I have projects where menu generation is automatic. For example, a categories from hikashop. It is me who constantly need to enable the button or write a separate code to save the parameters. I think that you need to automatically turn on everything at once. And for the generation to be accurate, it's better to decide by plugins. And use the menu only as an override.

[nikosdion]

you can just save the address on the menu.

Joomla constructs URL based on the menu structure, something which is already available when a page is being generated.

Moreover, a menu item is not a unique URL. In most cases it would be the base of a set of URLs, e.g. when you have a Blog Category menu item.

Further to that, a URL is not necessarily a reason to create a different share image. For example, an article could be accessible from two different menu items with two different URLs which have the same Open Graph image generation parameters, resulting in identical images. Double generating the image in this case would be a bug.

That's why I said "this is both over-engineered and doesn't work very well". It's not that I didn't think about this, it's that I thought about it long and hard and saw it's the wrong way to go about it.

I am personally worried about the generation happening during page generation. Better to shift it to com_ajax and let it be generated when it will be accessed.

FYI this is not a novel idea. It's something I did consider when I started converting Crystal's template helper code into a more generic plugin and I ruled it out.

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.

A different approach is to use a com_ajax URL as the image URL, serving a cached image if it exists OR generating one if it doesn't. However, this suffers from a multitude of problems. Least of all is that some social networks (e.g. LinkedIn) infer the image type from the extension scraped from the HTML (gotta love Microsoft...), therefore they'd never retrieve the image. The other salient point is that offloading the generation to com_ajax requires passing all the information required to generate the image as URL parameters which raises security, privacy and URL format abuse issues.

That's why the image is generated when you visit a page — including when social media / chat applications try to get the HTML of the page to scrape it.

To save time on future requests we cache the image on disk. This means that images are left behind for pages which are no longer listed / shared, have been removed, or their Open Graph Images parameters / template parameters have changed. This issue is about cleaning up these leftover images.

And also need to add the language as a prefix or folder so that it works fine on multi languages

No, you don't because each menu item and content item can only belong to one language (even if it's the "All" a.k.a. * pseudo-language). This means that if you wanted to point to the same category from, say, the English and Russian mani menu of your site you'd have two separate menu items with two separate sets of Open Graph Images settings. Therefore you could use two different templates with two different, localised versions of your base image. This is already supported, of course, so your problem is already solved. Did you even try using this plugin or are you just making stuff up?!

For materials based on previews and fields, but for hikashop, for example, get an image of a product and display it. At the plugin level, you can also add triggers to call your plugins in the concept

There's already a provision to set the text and extra image programmatically for this plugin. You could either write a plugin or template overrides for Hikashop to do that.

Here is an example sitemap for example. We decided to write our own sitemap, which can be expanded:

The only way that a sitemap extension would be even tangentially relevant to this plugin is if you used the same approach to essentially discover each and every URL of your site and pre-generate an image for it. I won't even bother explaining why this is a bad idea. It should be painfully obvious.

I personally do not like the approach with the menu. I have projects where menu generation is automatic. For example, a categories from hikashop. It is me who constantly need to enable the button or write a separate code to save the parameters.

We have already implemented a default settings option. If that doesn't work for you and the existing features which allow you to change the title and extra image are not enough you CAN have your code change the parameters of the current menu item, e.g.

\JMenu::getInstance()->getActive()->getParams()->set('socialmagick.template', 'A Different Template Here');

This is possible because we only access the menu parameters onBeforeRender i.e. after Joomla has executed the component's, the modules' and most plugins' code and is about to load the template's index.php file to convert everything into HTML. This means that even your template overrides, loaded long BEFORE the render event, can do this.

Also, if you are automatically generating menu items (a bad idea, but I digress) you could of course add the little bit of extra code required to set up the Open Graph images generation parameters for them.

If, however, you are automatically generating menu items and THEN you have to manually edit them... maybe it's time to rethink your approach because it's nonsense. Also, you would still be able to do the trick above in your template overrides.

And for the generation to be accurate, it's better to decide by plugins. And use the menu only as an override.

If you have actually ever worked on a solution that requires one plugin per extension (and extension version range...) to work you know that this is the least productive way to do things. It creates a MASSIVE barrier for site integrators. They can only use the 3PD extensions that have plugins for the solution they are using. This is a problem, for example, with sitemaps which I presume is exactly why you created your own.

By allowing template overrides to programmatically control the Open Graph image generation, using simple and straightforward code, we LOWER the barrier for site integrators. There is no extension that is unsupported as long as you can write template overrides for it. Moreover, you are not limited by the options given to you by a plugin; you can do ANYTHING you want.

That said, if you really think that your disastrous approach of using AJAX to create social sharing images and your ass backwards approach of using plugins to control the image generation are the way to go feel free to NOT use this plugin. What you envision is a failed approach that barely works for your use case — with a lot of bugs that are plainly obvious to me — but doesn't work for anyone else. We don't care about something broken like that.

Finally, please DO NOT hijack other issues for unrelated commentary. What you typed here has absolutely nothing to do with how to remove the leftover cached images. Consider this your first and last warning. Thank you.

[crystalenka]

Locking to prevent unrelated discussion. Please keep future comments on topic. Thank you!