Simulating a wp page – wp page load sequence

So apparently I’m missing something in the wp loading sequence to
display a page.

Not exactly, or that your code is good in terms of parsing the request.

And I don’t know why you need the add_query_arg() below, but this:

public function Check_Incoming() {
    global $wp;
    $current_url = add_query_arg($wp->query_string, '', home_url($wp->request));
    $parsed = parse_url($current_url);
    if ($parsed['path'] == '/myhiddenform') {

Could be simplified like so:

public function Check_Incoming( $wp ) {
    if ( 'myhiddenform' === $wp->request ) {

Now here’s why are you getting the CORS error

1. Font Awesome uses web fonts (loaded via @font-face), and web font requests are subject to the same-origin policy; and

2. You accessed the page with the www prefix (https://www.example.com/myhiddenform) and yet the web font URL did not have that prefix (https://example.com/.../fontawesome-webfont.ttf?v=4.7.0), which means the hostname didn’t match, i.e. www.example.com and example.com do not match — yes, they actually pointed to the same domain, but in CORS context, they are different.

   And because the resource did not have the Access-Control-Allow-Origin header, then that consequently caused the browser to not load the font and instead throw the CORS error.

How to solve the problem

Any of these would work, but you should use functions like get_template_directory_uri() to output the link to your CSS file.

• The CORS error says, No 'Access-Control-Allow-Origin' header is present on the requested resource, hence just set the header on the requested web font. 🙂

  I.e. Make sure the server sets the header when the example.com/.../fontawesome-webfont.ttf (with or without the www) is requested.

  And with .htaccess, you can do it like so (credits to this answer on Stack Overflow):

  <FilesMatch "\.(ttf|otf|eot|woff|woff2)$">
      <IfModule mod_headers.c>
          Header set Access-Control-Allow-Origin "*"
      </IfModule>
  </FilesMatch>
  

• Redirect all requests to www.example.com/* to example.com/*, or vice-versa depending on your canonical domain, i.e. whether your “Site Address (URL)” setting has the www prefix or not.

  And with .htaccess, you can do it like so (credits to this answer on Stack Overflow):

  # Add at the top in your .htaccess file. I.e. Above the BEGIN WordPress line.
  <IfModule mod_rewrite.c>
      RewriteEngine On
      RewriteCond %{HTTP_HOST}#%{HTTPS}s ^www\.(.+?)\.?#(?:on(s)|)
      RewriteRule ^ http%2://%1%{REQUEST_URI} [R=301,L]
  </IfModule>
  

  But actually, WordPress has a redirect_canonical() function which will do the above redirection, however, that won’t happen in your case since the function is hooked onto template_redirect which runs after (but not immediately after) the parse_request hook.

Another possible solution

• Use absolute path (i.e. without the domain) when linking to your (Font Awesome) CSS files.

  So for example:

  <!-- Use this: -->
  <link rel="stylesheet" href="/wp-content/themes/melos/.../your-file.css" />
  
  <!-- And not this: -->
  <link rel="stylesheet" href="https://example.com/wp-content/themes/melos/.../your-file.css" />
  

  But in WordPress, CSS files should be loaded using wp_enqueue_style(), and although you can use absolute paths, WordPress will actually turn the URL into a fully-qualified one (with the domain) when WordPress generates the <link> tag, hence the same problem would still happen.

  Therefore you should just set the CORS header, or redirect the www to non-www (or vice-versa), or both.

Additional Notes

• When outputting the hidden link, you should use WordPress functions like home_url() like so: <a href="<?php echo home_url( '/myhiddenform/' ); ?>">...</a>.