Jump to content

Invalid Markup Validations w3


traylor23

Recommended Posts

I'm not seeing your list, either. I also had a long list to start with, but over time I was able to validate our Blueprint site. There are still some warnings, but no actual errors. It took several weeks of work off and on - just one error at a time. You'll have to be able to edit the skin code for sure, and possibly even a few plugins. I don't specifically remember editing any core files, however I may have.

Link to comment
Share on other sites

Here is what I see: In the skin template file main.php, there are three bytes that are always placed at the very beginning of the file to indicate it is encoded utf-8. Those bytes are: xEF xBB xBF

 

What needs to be done is to load the main.php file into a programmer's text editor, make sure the editor is using the encoding of "Unicode Without BOM", then save the file.

 

Of what was posted above, the other errors are caused by this first error.

Link to comment
Share on other sites

Ok, then let's force the issue. Make sure NotePad++ is using that encoding method, load the file, make an inconsequential edit, save, and replace the existing file.

 

Here is a factoid that may be relevant... CubeCart 5 uses a cache system to hold rendered skin files. If the cache system does not notice the source file has been changed, the cached copy will be used. So, in admin, Maintenance, Clear the Cache.

Link to comment
Share on other sites

The only other thought I have is that the FTP program you are using (if!) may be modifying the file if being transferred as a text file (ASCII) as opposed to being transferred as a binary file. Please check on that.

 

If your hosting control panel has a text editor, you might also try using it.

Link to comment
Share on other sites

Ok...tried it as a binary file after re-saving it and clearing cache.  Still have the same error.  I'm thinking there's a code edit I did somewhere else that is messing with the main.php.  I'm so frustrated with CC5.  It's always something.  I also tried using my hosts inline text editor to no avail.

Link to comment
Share on other sites

There are pro points for why an FTP utility would choose to transfer a file as ASCII. If the file can be be compressed before and after transfer, so much the better.

 

But the biggest pro point is that the FTP utility can determine how the receiving side's operating system prefers line endings:

x0D x0A (CR-LF) for Windows

x0D for Macintosh (I think)

x0A for everything else

 

Making such changes - as a favor for the user - may solve certain problems inherent in text files.

 

On the other hand, if the user of the FTP program does not fully!! comprehend all that is taken into account, then there may be more problems not solved than solved.

 

So, please see how to force the FTP program to use binary mode (if it wasn't already sending the file in binary anyways).

 

This all assumes that NotePad++ is doing it's thing correctly.

Link to comment
Share on other sites

Looking at the source HTML received by the browser, I see:

X<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">

where X is the BOM.

 

But if I ask for:

http://www.ballcardz.com/skins/kurouto/templates/main.php

which is the Kurouto skin your store is using, I get:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" dir="{$TEXT_DIRECTION}" lang="{$HTML_LANG}">

There is no BOM and there is no blank line between the two lines of code.

 

So, I will ask that you confirm you are FTP'ing the correct file and overwriting the correct file.

Link to comment
Share on other sites

Hey Brian,

 

   I took the space out of the file to make sure that I was making an "inconsequential change" to the code before I saved it again.  I know that I am writing/overwriting the correct file (/skins/kurouto/templates/main.php).  I am sending the e-mail you asked for now.

Link to comment
Share on other sites

I tried to run your url through the validator and got the same results as previously posted. However, if you run the actual source code for the homepage through the validator it does complete validation and you end up with 57 Errors, 11 warning(s)

 

I have seen comments where the line <meta http-equiv="X-UA-Compatible" content="IE=Edge"> causes problems so maybe try removing this and see if that helps. If so you can add functionality for the <meta http-equiv="X-UA-Compatible" content="IE=Edge"> in your htaccess file.

Link to comment
Share on other sites

Other than 'plugin' (and maybe 'basket'), all other destinations are either in the middle or end of checking out, or in the customer's account, or accessed from outside the store.

 

So, as far as using meta-data to conform to one's belief in seo, these pages are irrelevant.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...