[airuck]

Hi Mohammad,

Thanks, that seems to be the problem. The single-product.php files are the same in both locations (one at /neighborhood, one at /neighborhood/woocommerce), and this code exists atop both:

	 * Override this template by copying it to yourtheme/woocommerce/single-product.php
	 *
	 * @author 		WooThemes
	 * @package 	WooCommerce/Templates
	 * @version     1.6.4

Are the two identical copies of single-product.php present in the current neighborhood 1.80 release? If not, can I get a zip file with the latest so I can update my local repository? I don’t want to have multiple copies, and in case I have old copies of other files, I’d like to correct the issue.

If the files are both present in 1.80, can you pass along to the developer to remove one and to update the comment at the top to match the correct version and template override location?
Thanks!

[airuck]

Yeah, I also didn’t see the option…
Since the code seems to use max-width (which is viewport width), not max-device-width, so it’s not limited to mobile devices. When i checked the latest zip, i still saw the code, I think the confusion was due to it appearing as tablet code, but it was listed under the iphone section (line 433 in the latest responsive.css, added in version 1.71).

As a result of this change (even though I’ve worked around the original issue with my proposed fix), the top menu is gone for desktop users between 768-1024px, so i don’t that it’s fixed even without the code in question. Unless I’m mistaken, before the last 2 versions, didn’t the topnav show for users between widths 768-1024? If we had this menu option and could disable it, that would probably fix things for myself and Deon.

Here’s a testing tool that shows our layout at the various smaller resolutions, you can see the topnav issue there at 768: https://hookandloom.com/2014dev/responsive/?browse/cotton-striped-rugs

[airuck]

Ed, can you do the same for sf_mini_header and sf_mobile_search functions in the same file (sf-header.php line 424)?
They also output html, but currently don’t have function_exists calls. Hugely appreciated!

[airuck]

Awesome, you’re the best!

[airuck]

Hey Mohammad,

You’re right, I can add those checks to sf-header.php. But if I do so, I’ve now overridden the whole sf-header file, and have to be careful when upgrading not to overwrite it. I want to change as little as possible any time I’m overriding swift framework / neighborhood functionality. If I just want to override one file for its html output, that’s very different from having to keep up to date on the whole sf-header file, does that make sense? It’s all about changing as few things as possible to your core framework and theme while still supporting our needs in the child theme.

What I’m asking for is for you to add the function_exists check to the file in your code and release it with the next version of swift framework / neighborhood. This way I add these changes locally (to sf-header.php) and know my code won’t break when I update to your next version, because it will contain the function_exists check.

Then other developers can use this in the future, and it has no negative implications on backwards compatibility or anything–the function_exists checks also already being done in the same file for other functions, so I’m hoping it can go in the next version.

Thanks again for your time (:

[airuck]

Hi Mohammad,

Well, I have a functions.php in child theme, as mentioned. You cannot override any functions except those that will conditionally check to see if they already exist. The ones I listed don’t do this. If I take your advice, I’ll get a fatal error due to redeclaring an existing function (because the swift framework will try to make the function again when that code runs, as the functions.php runs first).

The addition of these function_exists checks in the swift framework sf-header.php would allow them to be overridden. Can you pass this along to one of the developers?

Also, is there an easier method for developer-related requests, or swift-framework-specific tickets, or is this the best method?

I appreciate the help!

[airuck]

Yeah, I was hoping to avoid overriding the template, that’s the option I guess I’m left with though. if I get a few minutes I’ll submit a patch re-adding the hooks, maybe that can help. Understand you’re busy, thanks for taking the time to reply!

[airuck]

hey Ed,

Yeah, that’ll definitely do it, but I really wanted to keep template compatibility (which is why I ran through the css loopholes in the first place). Is this something that can be done with the next version, so I know I’ll be okay to change it now? It seems to be a non-breaking change, and I believe this is how the structure was before the woocommerce 2.1 support was added (though I haven’t checked the codebase, but just from how our shop pages were laid out a couple of months ago, this makes sense).
Thanks for taking a look!

[airuck]

This reply has been marked as private.

[airuck]

Hi Ed,

I didn’t get a notification on this unfortunately, didn’t realize I had to subscribe. Sorry for the delay.

I wish it were so simple! That rule is already in place, but doesn’t help. Here’s why.

We’re actually not using the archive description to display content above, rather, we made a shop page to display richer content above the fold. But still, the idea behind this fix won’t work, because the content in question is /after/ div.woocommerce-count-wrap and form.woocommerce-ordering. This is the real problem.

For example, on a category product archive page, I’m using html in the category description, which has the css rule you mention already in place, to no effect:

.term-description, p.archive-description {
	clear: both;
	padding-top: 20px;
}

These elements are locked into the html template, and the woocommerce_archive_description action is called after these elements are outputted (line 186 in archive-product.php).
The only CSS trickery that would work was forcing them below the existing element using position:absolute, since they’re actually earlier in the DOM, so no clearing is going to work, you have to take the elements out of the DOM flow and hack them in below the element in question.

Even something as simple as moving line 186 up to line 145 (the do_action call) places page content ahead of the output of the ordering and result counts, and allows proper styling, since these elements really should always be attached to the product results themselves, and the archive_description is getting between these two things.

This is a start, but it still means using CSS to hide the sorting, for example, rather than removing it via a remove_action on woocommerce_catalog_ordering. since those 2 actions are now hardcoded (woocommerce_result_count, and woocommerce_catalog_ordering, since there’s no more woocommerce_before_shop_loop call now)

Still, it would save me (and anyone else trying to style these things and use archive and category page headers) a ton of trouble. I have probably 50 lines of css (across various responsive stylesheets) to account for the height of the header element (which changes as the page shrinks, so the top value on the result-count div has to change). It’s actually already broken on pagination (where the header disappears for some reaon). It would be a big relief if it could just fixed at the source.

I think I subscribed properly this time, so I’ll answer more quickly, sorry about that!

[airuck]

This reply has been marked as private.