[alibey]

sorry, forgot to include code tags for the canonical thumbnail HTML statement (see above)

<img data-jckqvpid="15506" src="https://needlepoint.land/wp-content/uploads/2015/09/Tropical-Patterns_b-150x150.jpg" alt="needlepoint canvas" scale="0">

[alibey]

So the question from a SwiftIdeas support perspective is: can swift builder support (a)? [ see below for an explanation]

The requirement is how to create a very fast loading page that displays 3 or 4 columns
with each row displaying a wp native 150×150 thumbnail image associated with each product in the woocommerce catalog
each thumbnail image must be “Quickview plugin enabled,” such that the use can hover over an image, have the quickview modal materialize, and read the product’s price, sku, see whether the item is in stock, then add it to the shopping cart (if he or she wants to buy it)

One way to do this is as follows

1. write a js function 1 that calls a simple PHP function, using AJAX
2. write the simple PHP routine that calls a simple (1 select statement that perform a join between 2 tables) mysql stored proc and pass back to the js func an array of rows containing the thumbnail urls, for each product listed in wp-post
3. use phpmyadmin to write the simple sql proc that joins wp_post and whatever meta or auxiliary tables (or files?) that contains the url for a wp-generated thumbnail url
4. once the sql data “cursor” is returned to js func 1 via the php func, have it call a simple js function 2 that constructs on the fly, for each product, a simple raw html statement that looks like this

5. pass the urls back to invoking wp page…

despite all this work, there would still be several things that need to done

first, write simple js func1 in the form of an event listener that calls the php routine when this page is loaded
then,
(a) either find a way to insert each raw html statement into a predefined swiftbuilder template for the page
or
(b) build the page using custom (responsive) HTML/js written for that page

The questions here are:

– what is the specific mysql table/column that contains wp thumbnails url strings?
– can swift builder support (a)?
– how to handle products that have no associated thumbnails (assuming that can happen)
– any security holes in the above call architecture that exposes the wp store to hackers?
– is there a simpler way to achieve all of the above?

The above goes well beyond a standard tech desk / support question, but i wrote it at this level of detail in the hope of any readers responding who may have found a more efficient or better way to achieve the same result. Probably send it to to Stackoverflow or whatever for some additional feedback.

of course it would be great to learn for sure from swiftideas if (a) is possible, which I am fairly confident is not.

thanks!

[alibey]

i figured out a partial solution

1. go to page swift editor
2. insert row element
3. insert 3 or 4 raw html elements – set to 1/3 or 1/4 width
5. copy the following code into each html box

<img data-jckqvpid="15506" src="https://needlepoint.land/wp-content/uploads/2015/09/Tropical-Patterns_b-150x150.jpg" alt="some seo name" scale="0">

this solution takes advantage of the fact wp will automatically create a 150px x 150px thumb for each image you save in Media
so if you set your woocommerce / product / display / thumbnail setting to 150px, there is no additional rendering lag in html/css resizing

the disadvantage with this is that you have to manually change each product id and associated jpeg image

a better solution would be to write a js function loop that queries the db, selects each product id and its associated image, then just builds the quickviewable product images directly on the page as shown above display in a 3 column format

this would probably reduce swf builder and woocommerce overhead in rendering a page, allowing potential sub second response assuming the backend if set up right

then again, it might not

i might try that next

any feedback from Swift support much appreciated!

thanks.

[alibey]

the issue of Atelier/Woocommerce image sizes was rather confusing for a long time. i was not sure at first how these were being controlled exactly. using firebug and constantly resizing my browser window for the catalog and product and home pages eventually helped me identify more or less exactly what was going on behind the scenes.

my main problem is that my client’s product pages all have a mesh background. this lead to a moire effect (ie, pics having an ugly sooty wavy background), unless careful steps were taken in (a) taking the photo itself and (b) how it is resized (moire can be introduced in pics that are originally non moire but can become so when sized down, due to extremely technical reasons involving how digital cameras work in general and how different brands and models try using various techniques to handle / reduce moire).

In addition, these products all have wildly different sizes. some are very tall and skinny, some are very short and fat, some are round, and some are square. it was a requirement that the mesh under the painted design (these products are handpainted designs on 13 and 18 mesh canvases that are sold to needlepoint stitchers) and on the exposed (ie non painted) canvas show clearly in all pics in order to be attractive to the viewer/buyer.

mesh clarity was highly dependent on “studio” light conditions and distance to the object being photographed — even minor differences in this led to the pics looking unattractively different from one another on the catalog page.

i should emphasize here that my client’s products are individually hand crafted works of art, not, say, mass produced t-shirts, and required unusual level of attention in rendering images of them correctly and attractively while not sacrificing performance.

my initial solution (which was to uniformly resize very large pics taken with a Samsung S5 under particular lighting condition to 1200px wide, save these in a PNG format — which I like to use due to its support of transparency and the fact that it is lossless — and leave the image settings as recommended in the Atelier documentation) did not work in terms of image placement issues on the woocommerce shop page.

They just looked screwy (sometimes they were inappropriately cropped, sometimes they were blurry, sometimes they were gigantic, etc), and it was taking too much time to figure out the associated CSS controlling their display. I also do not particularly care for the overuse of !important to override native styling, with resultant code maintenance complexity, but that is another issue.

In addition, the catalog became extremely slow after about 50 pics were loaded. Rendering a single product page was also became very slow, especially when it had to also display 3 or 4 “related” pics that were averaging 1MB each.

Google Page Insight revealed issues with (sorry to mention this) woocommerce/atelier HTML/JS coding (in particular with JS non deferred script loading), but this I could not control. Essentially there was on average a 1.3 – 3 sec wait time as the HP waited for the scripts to load. This of course can be fixed using various techniques, but this was outside the scope of my project, and I did not want to touch any PHP or go through the hassle of creating child themes since my client is completely non technical, and I will not be around to fix things once the project goes live, as I am moving on to another project shortly.

However, I worked extensively with Siteground (the hosting providers) to fine tune the server configuration, make sure no plugins were slowing things down (e.g., I got rid, alas, a plug in that allowed me to display the beautiful custom SVG logo I had developed for the client using Inkscape), but still the site was slow, and the images were displaying unevenly on the shop page — it was always unpredictable how a given canvas would end up being rendered.

In addition, I was having problems with center-cropped thumbnails, and I had another puzzling problem involving two columns only being displayed when using Chrome in the shop page when I had specified 3 columns (this while working fine in IE, FF, and O) in Atelier shop options.

So what I had to do was come up with a way to radically optimize my product images and have them appear uniformly on the shop and product pages in responsive mode.

I finally came up with a solution that worked and solved most/all these problems, not perfectly, but well enough. I will summarize them here for any readers who spent, like me, days trying to figure this vexing problem out.

1. Keep all pics in jpg format — PNG is just too heavy for a catalog consisting of large pics
2. resize all pics using gimp to be 600px wide.
3. for pics that are very tall (ie, whose height greatly exceeds their width), or very wide, resize to fit using gimp, on a white 600 x 600 background layer. meaning, add a layer of a proportionally resized product pic above the background layer, then merge down.
4. Set the shop and product woocommerce sizes to 600 by 600 px and the thumbnails to 120 by 120, with hard crop checked. you do this by going woocommerce –> setting –> product –> display
5. run each original ~3000px w pic through http://jpeg-optimizer.com/ — set the optimize dial to 40 (calibrate if necessary, to achieve different levels of optimization, which can change depending on things like moire, color brightness etc)
6. run the resulting image through tinypng for an additional size reduction – this can add an additional 20 per cent reduction in image size, while maintaining reasonable quality
7. attach the final highly optimized jpg image to the featured image “bucket” or section of the product page (leave the main pic panel empty: it is not needed, and may slow down things.)
8. write some simple html to eliminate (ie make invisible or hidden) the second image and associated text that appears in the product page below the fold. remember to use !important.
9. Use a much larger width (say 900 to 1200px) on the HP for any products displayed there, and specify the swiftbuilder row to be full width. this is the heaviest hit your site will take, but what you are sacrificing in terms of performance here (and only here) you make up for with dazzling product images (which can be animated using Sitebuilder).
10. add what I called a Quicklook page (ie a page that using the mini products element off Sitebuilder) link as a submenu off the main menu bar shop menu option on the hp to allow user the option to quickly view a thumbnail list of all the products in the catalog (could not figure out how to eliminate the round image display of these here, but the client will live with this) – remember to use the regen thumbnail plugin when changing product images.

These exact steps led to a massive reduction of pic size from several MBs each to well under 50kb in many cases. In the case of very dense pics (from a mesh/paint design perspective), this procedure was still successful in reducing 3MBs pics to an average of 100 kbs, while maintaining clarity and without introducing moire.

The product page and the catalog load time became noticeably faster, and all the pics were correctly centered and sized more or less regularly in the catalog, no matter what the size of the display device or browser at any given time during testing.

The only minor drawback was in the case of very tall or wide images: the cart/wish list and on sale or out of stock flags appear to float by themselves slightly away from the product img against a white background (but still contained within the 600 x 600 confines of the image settings, as described above).

Now that this problem has been solved, the client is now prepared to load the rest of the catalog (loading a catalog is a non trivial matter, and should only be undertaken after the client is satisfied with the design and performance of your solution), and go live next week, as the STRIPE plugin testing has also been completed successfully.

Thanks to Atelier, the end result is an ecommerce site that is intuitively simple to use (I had the good fortune of having some of my client’s B&M customers provide early feedback on how Atelier performed on desktop, tablet, and mobile envs, which was crucial in terms of things like fine tuning font sizes and color and product descriptions, the need for the resume shopping button in the cart/checkout area to return to referrer page — which i solved by writing a simple custom js function) yet compares favorably in terms of design sophistication to the competition in my client’s vertical.

For example, I was able to add a unique (this was custom css3 animation with no js, not provided by Atelier obviously) animated needlepoint canvas on the HP to use as a product marketing tool, and also use things like parallax and lightboxes (which are provided by Atelier), in order to further differentiate my client’s site in what is a very crowded and competitive space.

I did not use Quickview (for a variety of reasons), and decided on using the Swift Slider in only one section of the site that did not require a cart (I wrote a css solution for the woocommerce short code cart addon, but it looked ugly, despite much effort to prettify).

I hope this brute force but effective “recipe” will be of help to any future users of Atelier who may be encountering some of the same problems I did.

Now that everything is working correctly, I will leave anyone who has taken the trouble to read this far with a slightly modified copy of the golden 5 rules of ecommerce (which I did not originate, but agree with completely):

Rule Number One
Auto backup your site often, both database and full code (especially before any installs). Nightly backup your clients order flow or write some cron job that does this. Your client will thank you forever in the event of a disaster recovery scenario.
Rule Number Two
Once you have a stable store, never, ever update any module – not a plugin, not wordpress, nothing.
Rule Number Three
Try as much as possible to minimize plug in dependencies, and stay away from plug ins that look like they are not being supported or not likely to be supported in the future. Buy directly from an established vendor when possible, but don’t expect much by way of support due to the classic fingerpointing dilemma. Never expect your client (typically a non technical shop owner) to start fiddling around with things like child themes and PHP, and only allow them to add plug ins at their own risk.
Rule Number Four
Never, ever update your live site. Always test exhaustively in a Test environment
Rule Number Five
Do not believe claims that fully tested secure high performance ecommerce sites can be up in a week, and never tell your client that you can deliver anything in under a month for a site that has more than a few virtual products.

Re #4, Siteground only offers a separate dev env for an added cost, which can be prohibitive to many startup ecomm retailers.

The order flow backup and Rule #2 are critical: always have your orders exported to an excel or libre spreadsheet, just in case, and, once your client has signed off on the site, never update anything, no matter how attractive it may sound in the plugin description, unless the client understands and accepts that something new (even a minor rev) can break the site and that it might be very costly to isolate and fix or restore the previous version. This rule of thumb of course does not apply to essential security related fixes. Scope creep is not your friend, btw, and the client will end up resenting you unless you lay down the ground rules early.

Well, that summarizes my solution to this image-related problem in particular, and my overall experience working with Atelier in general for a talented who wanted a sophisticated site up in a month at a very low cost!

cheers,

ali

[alibey]

please cancel/close this topic – solved without help from swift support

[alibey]

please cancel/close topic – solved without help from swift support

[alibey]

please cancel/close topic – solved without help from swift support

[alibey]

please cancel/close topic – solved without help from swift support

[alibey]

please cancel/close topic – solved without help from swift support

[alibey]

please cancel/close topic – solved without help from swift support

[alibey]

given the lack of response, i will restate this question more succinctly, so i am closing the topic.

[alibey]

?

[alibey]

get rid of a question mark in one of the comments above

[alibey]

hi dvddown

i am no longer using either quickview (too baroque) or the swift slider. my crude css fix (see below) has to do with using the caption area below a swift slide to force the woocommerce “add to cart” short code (when added to a slide page) 2 look more presentable, and despite this, it still looked pretty amateurish though it is thx to the flexbox responsive. in the end, i went instead w/ the plain old atelier shop catalog metaphor, with full price products only off one menu option (this is the shop page with sale items hidden), and a catalog element from the swift builder where i scope the products to being only the ones one sale (which you can specify). this worked fine, and allows buyers to immediately choose off the menu if they want to view full price products only, or sale items only, and makes use of built in cart and wish list functionality. i also offer the ability to cut across sales and full price via categories (ie, dog products, cat products, etc) client is pleased and therefore so am i… imho i think the heyday for ecommerce sliders has come and gone, particularly since the swift slider does not support hover and the revolution slider a target for hackers… what you might want to do is consider doing what i did which is to present customers with a fast loading matrix of images they can click on and checkout quickly. nice, clean, and fast, and is pure atelier without any need for xtra css. the css code i wrote, which you can expand by adding comma separated post #s (as the code below works for only 1 product /slider page) is as follows”

/* start of caption code under slider css */

.caption-excerpt pre  {
    
    display: flex;
    flex-direction: column;
    background: black;

     
    overflow-y:hidden;
    overflow-x:hidden;
   
    margin: auto;
    width: 90%;
    
  }
  
  
  
  .add_to_cart_inline {
    
    display: flex;
    flex-direction: column;
    background: black;
  
    margin: auto;
    width: 90%;
    border-color: black !important;  
  
}

.post-14915 del .amount {  /* you can add xtra .post classes (for additional products) here, separated by commas *?
    display: flex;
    flex-direction: column;
    align-items: center;
	justify-content: center;
    color: white;
    font-size: 135%;
    background-color: black   !important;
    border-style: solid !important;
    border-width: 1px   !important;
    border-color: black    !important;

}

.post-14915 ins .amount {  /* expand here */

    display: flex;
    flex-direction: column;
    align-items: center;
	justify-content: center;
    color: red;  
    font-size: 155%  !important;
    background-color: black   !important;
    border-style: solid !important;
    border-width: 2px   !important;
    border-color: #191919 !important;
  
}

.post-14915 .sf-icon-add-to-cart {  /*expand*/
    
    font-size: 200%;
}

.post-14915  .wp-caption-text {  /* expand*/
    
    font-size: 70%  !important;
}

.caption-content .tooltip{
display:none !important;
}

/* end of caption code */

cheers,

ali

[alibey]

Hi David,

Okay, looks like this is the right time to set up a child theme!

Cheers,

Ali