[airuck]

Hi David,

Thanks, nice spot! Looks like an old setting on the individual slider that was including the fonts. I think I’ve fixed the include twice issue, but I can still reproduce the iOS “empty divs until you scroll up” issue after a few page loads, though, at about the same frequency as before (maybe every 5 page reloads).

[airuck]

Jason,

I still see this very occasionally. I believe it’s related to the revolution slider and the google font loader and some quirk in webkit. It seems most prominent if a page load is interrupted (e.g., during rapid testing) or immediately reloaded. We solved it (or mitigated it) with caching for better performance, but I haven’t totally solved it; I just reproduced it now. Wish I had better news for you.

[airuck]

David, I think this is all set now. I see the same flash of blank content as before, but when the slider loads now, the content displays correctly. Will mark as resolved unless it resurfaces…thanks for your time!
-aaron

[airuck]

This reply has been marked as private.

[airuck]

This reply has been marked as private.

[airuck]

This reply has been marked as private.

[airuck]

(attaching file again to pass forum security)

Attachments:

You must be logged in to view attached files.

[airuck]

Updated via wordpress – 1.92 on the install linked above, and 1.93 on our test install, which shows the same results.

Both versions show the same code: …/neighborhood/woocommerce/loop/result-count.php is the file in question.

Wordpress currently shows version 1.93, and style.css shows version 1.93 in the opening comment, so the update appeares successful. I attached the file in question (from 1.93 on our test installation).

[airuck]

Hi Kyle,

I haven’t heard back on this, but it’s definitely not fixed as of 1.93. Any update?

[airuck]

Sure, here it is

Attachments:

You must be logged in to view attached files.

[airuck]

Ed,

Here’s the patch with the above changes mentioned (flexSlider included in the SF namespace, and the productSlideChange function placeholder as shown in the code example of my previous post). The patch is against neighborhood 1.80.

cheers,
-Aaron

Attachments:

You must be logged in to view attached files.

[airuck]

Ed,

Sure, I’m happy to help. That version didn’t include a hook for flexSlider, which I’ve added since.

Given this namespacing, I was also thinking it would be useful (and painless) to add some callbacks in logical places into these functions. For example, let’s say a client wants to perform something whenever the image slide changes (like updating text somewhere, or a pinterest button link, or something).

If the methods are defined atop each object, they can serve as user documentation.

SF.flexSlider = {
// User callback placeholders.
	// After product image slide changes. SF.flexSlider.productSlideChange() = 		function(productSlider) {...}; 
	productSlideChange: jQuery.noop,
		
init: function() {

It’s already defined as an empty function so we can just call it where the product slider is being instantiated:

before: function(productSlider) {
	if (hasProductZoom) {
		jQuery('.zoomContainer').remove();
	}
	SF.flexSlider.productSlideChange(productSlider);
},

Then a user can put something like this in their own javascript file:

SF.flexSlider.productSlideChange = function(productSlider) {
	console.log('after product slide change');
};

Here’s that code working: https://hookandloom.com/2014dev/product/ashley-rug-blue-white/
I bet there would be a use for several of these type of placeholder hooks, but it’s the kind of thing that could be added quickly as necessary. I’m sure you can think of a few callbacks based on user requests, but the example above would be something I’d use right away. If nothing else, it’s an option for later on to make your theme as extensible as possible.

If you have a public git repo or some better way you’d like patches or pull requests, let me know. I’m happy to send along a patch that adds flexSlider to the SF namespace, and adds this placeholder method.

If you want to chat about the idea of extensibility, or have thoughts on a similar approach, feel free to email me any time. I’m happy to talk about such nerdy things for a few minutes if I can be of any help. Improvements like this help both the users and the theme authors / maintainers, so I appreciate you listening and responding, too.

cheers,
-Aaron

[airuck]

Removing a line of debug output I left in first patch

[airuck]

Hi Ed,

I realized the original proposal wasn’t ideal, since name collisions can happen if you remove the anonymous function container, which I assume is why you did it. Attached is a simple patch that changes very little, and addresses this concern with a namespace for all swift framework functions in functions.js.

It’s pretty straightforward, and I checked each method call after the regex replace and corrected a few. I tested that all of the init methods ran without error, so this is a drop-in replacement that should cause no issues. I have this version running now on my dev site, and am now able to override any method, similar to the example in the original post:
SF.woocommerce.productZoom = function(zoomObject) {console.log('zoom!')};

The patch adds an SF namespace to all method objects within functions.js. None of the code has to changed except the declarations. I don’t think this approach has any downside, as your code is safe from namespace collision, but your users can override any one of these methods with their own javascript.

The patch is against the latest 1.80. I hope you will consider including this in the next release, it will be hugely helpful to anyone trying to customize javascript, and takes advantage of the already-well-thought-out method names and organization of your swift framework javascript functions.

Cheers,
-Aaron

[airuck]

This reply has been marked as private.