Hi, I bought the template and found some design bugs in it. I am using it with Hika shop.

1. On all the forms on the template, when hit the submit bouton without entering any values, the errors appears and push the registration form overlapsing the footer (my body is smaller than the demo). Wierds it looks like a position: absolute problem but I didnt find exactly what it is. You can see the bug on your demo version on the contact form by submiting it empty: demo.joomlabamboo.com/index.php?theme=nov14

2. The border that appears on input text fields on focus doesnt have the good radius so small holes appear in the field corners.

3. In the Hika shop checkout page, when we hit the submit without entering any value, the validation errors don't show up

4. The menu hover animation is slow so when we mouse hover a menu element and move the mouse down before the hover arrives, the hover disapear.

5. There seems to have some wierd bug with the tooltip, sometimes when we put the mouseover it opens and close right after

Can you point me out on how to fix those? I am a programmer myself so I can fix the things without wating for an update.

Thanks.

Do you have a link?

Cheers
Paul

No, no link. Just check on your Rasa2 demo, all the bugs are there.

There is also a front-end design bug when we put 3 cols products instead of 2 cols with the Hika products module.

Looks like you guys designed the template without testing the different options of Hika. I was really hoping for a bug-less product.

Hi Sorry for the delay.

It's just gone Monday morning here and I will look at these issues shortly and post an update for the issues.

Thanks Anthony

Okay I am waiting for that.

Thanks

Hi Pierre,

Im working through the issues here now but need to clarify some things:

1. I have this fixed locally and will release once we get the other issues square away.

2. Which browser are you using? the focus effect often differs from browser to browser. If it's Chrome and the big blue border all I see is an outline that obscures the entire border of the input.

3. Which form is this happening with? There is an equal height script that's obviously not getting triggered but I will need to know the page. Ive looked at a few pages and it's fine here. It may be that the fix for number1 fixes this but please confirm the page to be sure.

4. Again I dont see that here with the default settings. Which browser and menu item are you hovering on? You can adjust the menu delay in the menu settings of the template.

5. I'm not sure which tooltips you mean. Can you confirm?

6. Ive tested with 3 columns and again it seems fine. Can you be more specific? I test the Hika product module in the tab position.

Thanks

Hi Anthony,

Thanks for the reply.

1. Great, could you point me what lines to change so I can fix this asap on my side? This bug is urgent compared to the rest.

2. I am using Chrome last version. It's only 1 pixel in both the top corners, I included a screenshot showing the problem.

3. Looks like it's okay now, it was happening when I had 2 payments options and didnt select any, it didnt pop an error message.

4. You can see the problem by hovering the Extensions menu in your demo and moving the mouse down right after. I see why it's acting like that but it's a bad user experience.

5. I am talking about the tooltips that are mixed with a form label everywhere on template. You can see the problem by looking at the contact form on your demo, hover a couple times over a label and sometimes the tooltip close right after

6. It's happening with the Hika products listing with 3 or more columns, with 2 it's fine. The problem is that a big gap appears between the thumbnail and the price/title/buton. The more the columns, the more the gap increase. I included a screenshot.

Thanks

Sure ...

1. In js/scripts.js add button to around line 48 so it looks liek this:

$('span, a,li,h3,.zentitle,button').click(function () {

2. Ok as far as I know there is no way to add border-radius to inputs that have a focus. For me 1px is so slight it's not worrying about but if you want to adjust it I would remove the outline like this in a custom.css file:

input:focus,textarea:focus {
outline: 0;
border-color:whatever-color-you-want !important
}

3. Yep I see that. Best to change the transition if you dont like that effect. That can be done in the templates menu settings.

5. Does adding the following to a custom.css file solve it for you?
.contact label {display:block;padding:10px 0;line-height:2em}

6. Thats a Hika shop setting. You need to adjust the height of the image block in the Hikashop settings to change that.

Thanks

1. Worked, but also had to reduce the timeout to 0 because the bug was appearing for 600 ms. Why is the timeout there? And why not just adding the errors to the dom so it's just pushing the content naturally.

2. Okay

4. Okay

5. I added the css in custom.css and the bug is still there

6. Okay

Another thing I found out is that the pagination is not styled at all. The ul li even appears from top to bottom. Is it normal?

Thanks

1. The timeout is to allow for content and images that get lazyloaded. eg tabs etc. So you could trigger the feedback twice. with and without the delay.

5. I was doing this in the browser so its possible you may need ot add !important after the rules.

7. Which pagination and no it shouldnt be unstyled or be at the top of the page.

Hi,

1. Not sure what it has to do with the lazy load because we only add text to the html, not images? Is it safe if I leave it at 0 ?

5. I added the !important and the bug is still there. It happens when you hover the label, then leave it for a short time and hover it again, it doesnt stay opened the second time.

7. The pagination of the Hika shop (products listing, probably categories listing as well but didnt try). I included a screenshot for the pagination. You can see that the list isnt styled at all.

Thanks.

1. The time out is used to add a buffer when content is loaded that there may be a delay. In your case it's possible you dont need it. If you see other delays occurring then you may need to reimplement the timeout. If you load content in tabbed layouts for instance the timeout is required. You can see it on the demo site on the typography page as an example.

5. Ok I need to look further into this. Will come back.

7. Yes my ;pologies this was missed in the testing. But the pagination isnt coded properly in Hikashop so that the styling didnt autaomtically get picked up like you would expect. eg the code is ul > a - no li and no active class.

But anyway if you add this to the less/buttons.less file then recompile the less to css it will fix the issue. This has been added to my version here and will be included in the next release.

Thanks

1. Okay I am gonna try it like that for now but there should be a better way than a timeout to do it, because with the timeout it's breaking the design for 600ms. It's also always risky to use a timeout, the page doesn't always takes the same time to load depending on computer, internet etc.

5. Okay, please let me know when you find out

7. Great it's working now.

Also, there was a little other something that I fixed already but you might want to know, not sure if that was intented but the form selects were not the same height as the text inputs (42px), I fixed it by adding "select" to line 135 of zengrid\less\_form.less like that:

input,select {
min-height: @input-min-height;
border-radius:@input-border-radius !important;
border: 1px solid @border-color !important;
box-shadow:none !important
}

Thanks

Thanks I added the select fix to the framework and it will get released in all future updates.

Regarding 1. - which way would you do it? Its there to cover a variety of ways that content changes on the page. Keen to hear low overhead suggestions you might have as the timeout is the best option as far as I can see.

Thanks

Hi,

Why is there a need to resize the height manually? I just tried to remove the inline css height from the html: <div id="midCol" class="zg-col zg-col-8 zen-push zen-push-4" style="/* height: 973px; */"> and I removed the resize in script.js: $('.sidebar, #midCol').matchHeight(); and it works. So the errors DIV is just added to the DOM and the parent height is naturally resized like it should without the need to use JS.

Also, I was wondering if the validation was done server side as well?

Thanks

The height is resized to allow the sidebar border to stretch full width.

Not sure what you mean by server side validation.

I just tried it with the left sidebar layout, no jquery height resize and everything is working fine. The sidebar border doesn't break. Am I missing something?

For the server side validation, right now it's validating the forms client side (javascript). But is it also validating it server side (PHP)? It could be a big security issue if it's not.

Thanks

The equal heights is used for circumstances where the sidebar is taller than the main content. I had it around the wrong way.

It's not going to break the template. So if you want to remove it then it's more or less going to be fine.

Joomla templates don't handle any data processing. Thats all done via Joomla and your component.

Thanks