Add open graph meta to your virtuemart and joomla template.

Facebook usually does a good job at picking up all the required information from your web page but there is some instance where you might want to have better control on what image is displayed as thumbnails or have a customize description for Facebook sharing. In that case you will need to use facebook open graph.

List of basic properties: https://ogp.me/

  • og:title
  • og:type
  • og:image
  • og:url

The required meta properties for open graph are the following according to facebook Sharing Debugger :

  • og:url
  • og:type
  • og:title
  • og:image
  • og:description
  • fb:app_id

og:url

We will need to get the URL of the page currently displayed. Joomla doc gives us the solution here: https://docs.joomla.org/URLs_in_Joomla

In index.php simply add:

use Joomla\CMS\Uri\Uri;
$uri = Uri::getInstance();
$url = $uri->toString();

And within your <head> element:

<meta property="og:url" content="<?php echo $url; ?>"/> 

og:title

To get the current page title, Joomla documentation gives us again the answer: https://docs.joomla.org/Add_Static_Text_In_Title_Of_Page

<?php
$title = $this->getTitle();
?>

and within the <head> element:

<meta property="og:title content="<?php echo $title; ?>"/>

og:image

Automated this task will be a bit more challenging as the URL of the image will change from page to page. For instance, images from home page, post and product and category pages won’t be called the same so you have to check the type of page you are displaying to call the right type of image.

For the home page, you can set the og:image content manually. You will need to check first if the user is currently viewing the front page:

https://docs.joomla.org/How_to_determine_if_the_user_is_viewing_the_front_page

<?php 
$app = JFactory::getApplication(); 
$menu = $app->getMenu(); 
$lang = JFactory::getLanguage(); 
if ($menu->getActive() == $menu->getDefault($lang->getTag())) 
 { 
  echo 'This is the front page'; 
 } 
else 
 { 
  echo 'Accueil'; 
 } 
?>

It seems there is a bug in Facebook Open Graph for the image property in website requiring https. We speak about it here. On my side the issue is only present in messenger. Sharing a page as a post is working as expected.

og:type

The default is ‘website’ but there exists a ‘product’ type that can be of interest in product pages

<meta property="type" content="website" />

Facebook OpenGraph doesn’t diplay the image set into the og:image meta and pick another

Issue: Facebook OpenGraph doesn’t diplay the image set into the og:image meta and pick another one instead.

It seems to be an issue with https URL in open graph. There is a closed bug report in facebook without answer from facebook.

developers.facebook.com

Some people in stackoverflow have found a work around.

stackoverflow.com

Work around 1: upload all your picture in a non https domain and use these URL for your og:image content property.

Work around 2: use og:image:secure_url and use the facebook sharing debugger to lint your page. https://developers.facebook.com/tools/debug/ [Work around currently in test]

Code end up on one line after Filezilla upload.

Issue description:

End of line are removed from file after uploading a file to your server through filezilla or any other FTP software.

https://trac.filezilla-project.org/ticket/3830

One of the answer on the bug report above describe the issue clearly:

For the benefit of anyone like me who finds this after having experienced exactly the same issue, I believe I have a more rigorous explanation for exactly what’s going on. Codesquid posted a link on #5486 that provides all of the relevant information, which I shall re-post here for convenience:

​http://wiki.filezilla-project.org/Data_Type

The bug appears to lie in the standard itself, rather than Filezilla specifically. That is, the actions defined to ensure that \r\n line endings are always transmitted and then converted by the receiver to whatever is appropriate for that platform may fail if the source file itself has the wrong line endings for the client platform. For example (assuming one transfers the file using the ASCII data type):

IF: a file with CR-only line endings is uploaded
FROM: a windows client
TO: a linux server
THEN: the transmitted file will only feature CRs, which will be deleted
RESULTING: in a file with no newlines

Which is very bad news if your file contains line comments, since this will effectively change its meaning. Similarly,

IF: a file with Windows line endings (CR+LF) is downloaded
FROM: a Linux/Mac server
TO: a Windows or Mac/Linux client
THEN: additional unwanted CR/LFs will be inserted
RESULTING: in a file with mixed or double newlines

Other scenarios of this type can clearly be concocted, but I would have thought these two would be the most common. As codesquid pointed out, the data type can be specified for transfers. In the absense of a parser in Filezilla to handle malformed newlines, the only safe answer appears to be to use the binary type for all transfers.

More infor about Data type available here:

https://wiki.filezilla-project.org/Data_Type

To check the type of carriage return used in your file, you can turn that on in notepad ++ in View->Show Symbol->Show End of Line.

In my case, once downloaded via ftp from the linux server to my windows machine, the file showed CR for mark the end of the line. Other files not causing issue are making use of both CR and LF.

When reuploading the file using only CR on the linux server. All CR are removed and the file open in a single line when I open it for edit through FTP. As it is an executable file including comment, some code are commented out and the script don’t execute properly anymore.

Solution: To solve the issue, you can open use find and replace extended mode in Notepad++ and, in my case, replace \r by \r\n and save.

Find unsused code in your javascript and css files. Optimizing your lighthouse scores part 2

To find out what part of your CSS or JavaScript is not used, you will need to enable the coverage tab in the Chrome Developper Tool. For that you will need to run a command in the command window. The command window can be enabled in the right hand “three dot” menu of the Chrome Developper Tool.

Type coverage and press enter. The coverage tab will now be available in the bottom window of your Google Developper Tool.

Reload the page to start the diagnostic.

You will see listed your files, their type, size and amount of unused code as well as a graphical representation of the proportion of unused code compare to the total size of the file. By clicking one of the file it’s content will be displayed in the code window of the source tab and you’ll see that the beginning of the line of unused code will be highlighted in red. Now it will be your job to refactor the script so that only necessary CSS and js are loaded for any given page …ideally, as this is no easy task.

Additional reading: https://developers.google.com/web/tools/chrome-devtools/coverage