traylor23 Posted December 4, 2014 Share Posted December 4, 2014 I am getting the following invalid w3 markup validations for my site ballcardz.com. Any help would be appreciated. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 4, 2014 Share Posted December 4, 2014 I'm not seeing a list. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 4, 2014 Author Share Posted December 4, 2014 I'm not seeing a list. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted December 4, 2014 Share Posted December 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 4, 2014 Share Posted December 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 4, 2014 Author Share Posted December 4, 2014 Hey Brian....so downloaded Notepad++ and saved the file to Unicode Without Bom, and am getting the same errors. Any other ideas? Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 4, 2014 Share Posted December 4, 2014 It didn't work. In Notepad++, on the menu bar, there is Encoding. Select Encode in UTF-8 without BOM. Re-save the file. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 4, 2014 Author Share Posted December 4, 2014 I did that :-/ and repeated the process to make sure that I did it after reading your message. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 4, 2014 Share Posted December 4, 2014 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. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 4, 2014 Author Share Posted December 4, 2014 I've done all of that. Just put a space in between the <!DOCTYPE html> tag and the start of the <html xmlns="http://www.w3.org/1999/xhtml"dir="{$TEXT_DIRECTION}" lang="{$HTML_LANG}"> tag...it is saved as UTF-8 w/o Bom as indicated by the tool bar. I cleared all of the cache in admin... Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 5, 2014 Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 5, 2014 Author Share Posted December 5, 2014 I'll see if I can work on that backwards. Should these files be transferred as binary? I know it converts them to ASCII. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 5, 2014 Author Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 5, 2014 Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 5, 2014 Author Share Posted December 5, 2014 NotePad++ shows it as a UTF-8 w/o BOM when I open the file, and then I force it to save it as such. I can download another text editor, but I have a feeling the problem is with some other customized code within Cubecart. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 5, 2014 Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
traylor23 Posted December 5, 2014 Author Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
ayz1 Posted December 5, 2014 Share Posted December 5, 2014 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. Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted December 7, 2014 Share Posted December 7, 2014 Thought I would work on validation again, and I find that the index.php?_a=basket page does not have a title. Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 7, 2014 Share Posted December 7, 2014 For the moment, I will say that the following do not have any meta-data: 'account', 'addressbook', 'basket', 'checkout', 'complete', 'confirm', 'downloads', 'gateway', 'logout', 'profile', 'recover', 'recovery', 'remote', 'vieworder', 'plugin' Quote Link to comment Share on other sites More sharing options...
Dirty Butter Posted December 7, 2014 Share Posted December 7, 2014 Is there any logic as to why some pages do and others don't have meta-data? Quote Link to comment Share on other sites More sharing options...
bsmither Posted December 7, 2014 Share Posted December 7, 2014 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.