everything was going well and then...

everything was going well and then...
please see https://www.candygoround.com

the top line ...where home | log in | shopping cart is........
the black line at the top should be wider?
I didnt change the width or anything....it might have changed after I added the slideshow....
but i removed the slideshow and it's still the same...
any ideas how to fix?

thanks so much!!

I think most of your problem is in the slider or your images on the main page.

I'm seeing hidetrail and showtrail not defined as errors when hovering over product images.

The sideboxes and several images have no PX in width or height but, that's a common 1.5.6c prob that shouldn't matter.

Make sure you have everything loaded in the correct locations for the slider and your image program.

When I look at the code in the developer tools in chrome I see the following:

<body id="indexHomeBody" data-gr-c-s-loaded="true" cz-shortcut-listen="true" style="" data-__gyazo-extension-added-paste-support="true">

  
  <meta charset="utf-8">
  <title>Zen Cart!, The Art of E-commerce</title>

where is that  and the extra space after it coming from? Make sure your tpl_main page doesn't have anything hidden hiding after that body opening tag and the opening ....wait wtf? why is there an opening meta tag after the body tag when all of that meta stuff is supposed to be inside the head tags.... something got screwed up in your html_header.php and/or the tpl_main_page.php

What version of the cart is this?

Oh I just notice that the extra character didn't show up in my posting of the code....hmmm. There is actually a hidden character there between the close of the body opening tag and the opening meta tag. in chrome developer tools I see it as & # 6 5 2 7 9 ; (with the spaces removed, of course).

I find it interesting that the view source appears correct but the elements tab in chrome developer tools shows the layout of the dom elements all screwed up.
still points to the html_header.php being messed up or from the wrong version depending on what version the cart is

zencart v1.5.6c

no <body> tag in html_header.php

Oh, I see... what editor are you using to edit files?

the hidden character is a &#65279 (Zero Width No-Break Space) which mostly happens if a file is saved UTF-8-BOM istead of just plain UTF-8

well i was using Microsoft Expression for php files.....but i noticed weird things ,...invisible scary things happening.....so I switched to Notepad....

You also have the issue of calling in a lower version of jquery right after the cart loaded jquery-3.4.0.min.js

<script type="text/javascript" src="includes/templates/responsive_classic/jscript/jscript_jquery-1.7.1.min.js"></script>

so that is a train wreck waiting to happen.

Back in December I had a conversation with the ZX Slideshow author about it being broken with Jquery 3.4.0 and newer. He said at some point he may find time to rewrite it with a better solution as the nivo slider code under the hood for it is no longer open source as far as I am aware.

Use notepadd++ and then make sure to set the encoding as just UTF-8

I'm seeing hidetrail and showtrail not defined as errors when hovering over product images. that was referenced earlier in the thread is from image handler, specifically the image hover stuff. If you have image hover turned on for image handler, turn it off... its broken... and is supposed to either be fixed or just removed.

barco57:

Use notepadd++ and then make sure to set the encoding as just UTF-8

Barco.....which file do I edit?

You should compare the includes/templates/responsive_classic/common/html_header.php, and probably the tpl_main_page.php to clean versions of those files.

OK, this was quite interesting... I've never seen this before and without FTP access, I probably would've pinpointed it sometime in summer 2025...

The culprit was your includes/languages/english/responsive_classic/index.php file - and to be perfectly honest, I'm still scratching my head about it... I have no idea what exactly caused it, but I replaced that file with a fresh version from includes/languages/english/index.php (and removed the 2 lines like in your original file) and it's working.

What's even more interesting is that the file shows as identical, but I noticed the header was broken on product listing pages as well, but was fine on product_info and shopping_cart page, which pointed me in the direction of index page... Interesting, I must admit.

As a side note - I've noticed you're using ZC 1.5.6c, but some of your files (functions_prices.php, categories_ul_generator.php, split_page_results.php etc) are from much older versions of Zen Cart. You might wanna consider fixing that because it might cause problems in the future.

I don't know who you had work on the site, as it appears you cut and pasted their reply to you into the last post.

The older files are probably brought in from add-ons that you installed.

balihr fixed it privately...

@Mike - this was actually brought up in ZX Slideshow thread and got my attention and then we followed up in the template's thread. I didn't even see this thread until now. But, it got my attention and I couldn't let go so I asked if I could take a look and find it.

Call me crazy, but I don't have any other explanation but to point at the server (maybe a Win server?).
I started with template files, worked my way up and finally got to the language index.php file. It was not UTF-8-BOM - that was one of the first things I checked when I realized it was that file. It was actually identical to the 1.5.6c out-of-the-box file. Heck, I even deleted the file on server and uploaded the one from a fresh 1.5.6c and it was still broken, but if I removed the template override language file, it was OK.
So, I ended up moving includes/languages/english/index.php to includes/languages/english/responsive_classic/ and just removed 2 definitions to make it the same as the old file. And it worked.

So, the thing that got me scratching my head was the file from my local vanilla folder that caused the same problem... And the ONLY thing I'm seeing different is that all other language files use CRLF and the files in responsive_classic folder use LF, although that shouldn't cause THIS... Or can it?