virtual page using url parameters to solve facebook sharing issues

Question

With some struggle and a LOT of reading, the solution to facebook sharing issue is to use the wordpress rewrite option, but not a wordpress endpoint.

Endpoints are fixed additional options off of a single wordpress page. There is no room for expansion.

My site required single WordPress page, built on short-codes. This one page has the potential to display thousands of different content combinations. The url parameters were the index. But facebook, disliked indexes or parameters and indicate this in the Facebook developers guide lines.

BUT, you can trick Facebook, by changing WordPress rewrite rules, into what looks like an URL. The page does not actually exist, rather the URL now contains the same parameters, but in a different form.

Originally the page operated like this:

 domain.com/yourpage?option1=X&option2=Y

This is the format that is now rejected by Facebook, leading the shared page to come up as missing.

By turning the parameters into part of a standard URL such as:

 domain.com/yourpage/X/Y

The URL is accepted as is by Facebook.

Classic rule rewrite rules recommend the use of to modify content.

 add_filter( 'the_content', 'YourFunction' );

The problem with this is: Only one parameter can be associated with one piece of data and shortcodes require all parameters at the same time. Unless you want to use global variables and risk a race condition between different users, is not practical or content reliable.

Thus my solution, is to rewrite the rules within WordPress, only for this one particular page and then when the page is loaded and the short-code hit, “READ” the URL and parse it out, in order to retrieve the variables desired. The beauty of this solution is, you can add as many variables as you like. There is no limit.

The previous URL was this:

  domain.com/yourpage?option1=X&option2=Y

we now want the url to look like this

  domain.com/yourpage/X/Y

Solution:

 add_action( 'init', 'wpd_detailspage_rewrite' );
 function wpd_detailspage_rewrite() 
     {
      add_rewrite_tag(
                    '%option1%',
                    '([^/]+)'
                     );

      add_rewrite_tag(
                     '%option1%',
                     '([^/]+)'
                      );


     $pattern      = '^yourpage/([^/]+)/?';
     $ppagepattern = 'index.php?pagename=yourpage&option1=$matches[1]&option2=$matches[2]';
     add_rewrite_rule( $pattern,  $ppagepattern,  'top'  );
     }

Then add this function, telling WordPress what parameter variables you are looking for:

     add_filter( 'query_vars', 'DetailsParametersVariables' );
     function DetailsParametersVariables( $vars )
       {
       $vars[] = 'option1';
       $vars[] = 'option2';
       return $vars;
       }

With your content shortcode code, then parse the URL.

  add_shortcode('PAGE_CONTENT', 'GenerateContent');
  function GenerateContent($atts)
   {
   $base_url    = ( isset($_SERVER['HTTPS']) && $_SERVER['HTTPS']=='on' ? 'https' : 'http' ) . '://' .  $_SERVER['HTTP_HOST'];
   $current_url = $base_url . $_SERVER["REQUEST_URI"];

  $ClearUrl        = explode('?', $current_url);      // Clear any content attempts
  $ParametersShown = str_replace($url,"",$ClearUrl[0]);
  $BrokenUp  = explode("https://wordpress.stackexchange.com/", (string)$ParametersShown);
  $Option1   = sanitize_text_field(stripslashes($BrokenUp[0]));
  $Option2   = sanitize_text_field(stripslashes($BrokenUp[1]));

   if(!is_numeric ($Option1   ) || !is_numeric ($Option2   ))
      {        
      // GO TO MISSING PAGE. PAGE IS NOT VALID. 

      header('Location: /missing-page/');  
      return 0;
      }

   .....READ DATABASE AND FORMAT CONTENT

   }

Some may say that using the $_SERVER call is insecure. But in this case, we are parsing and analyzing any content, like a pseudo fire-wall, so the risk is gone and potential removed.

The last REQUIRED step is to flush the rewrite rules. Nothing works unless this is in place. This can be done with a one shot of going to your Permalinks and re-saving. There are other solutions, but unless you are selling the plugin, not having the refresh overhead seems more practical for a custom site. If I come up with a better programmatic way of flushing, will update later.

You will see NO CHANGES in your .htaccess. This rule is saved in the WordPress database. The saving causes the changes to be saved there.

With a URL of :

  domain.com/yourpage/X/Y

Facebook now accepts the link and is clickable to the generated page.

I put this code directly into my plugin, that generates all the content for the site. But could very easily be it’s own independent plugin.

Related Posts: