[saturnerond]

Okay. Update from YITH documentation (better late than never?).

The wishlist page uses the [yith_wcwl_wishlist] shortcode.

IF we want wishlist pagination and display say 5 products per page, we need to use instead : [yith_wcwl_wishlist per_page=”5″ pagination=”yes”].
So in fact yes, wishlist pagination is ugly, but working when using the shortcode attributes.

IF we don’t like this ugly pagination, we have to live with the empty row.

Voilà. Thank you for your patience,
Ammie

[saturnerond]

No unfortunately, and cannot say when I will have one. My brother is so slow at providing content that I’ve been unable to make his website live for more than 1 year now.

The issue might be partly with YITH. I changed the theme wishlist.php file name to force the theme to use the plugin one (see 2nd attached screenshot). The wishlist page looks a bit messed up, but —
1- I then no longer get an empty row :
– The product table is not wrapped in a form
– The above and previously “empty” row (<tr><td colspan=”6″></td></tr> according to Firebug) is no longer in the table tbody but in a tfoot (that doesn’t exist in the theme wishlist.php template) AND it includes the “share” div. So maybe there is a bit of a markup issue here
2- However I still do not have pagination. Basically and either with the YITH or theme wishlist template, the “echo $page_links” doesn’t echo anything.

I also deactivated all plugins except those required by the theme and so far cannot see an obvious conflict.

From a selfish point of view, pagination is not a real issue for me as I do not especially need it. The empty row is more annoying as it makes share links less visible.

Thanks again,
Ammie

Attachments:

You must be logged in to view attached files.

[saturnerond]

Hi Mohammad,

No, I’m with the last 2.17 version. My cart page is fine.
The styling issue is at the thank you page and at the order details page (when looking at the order details from My Account).
The file at fault is order-details.php, where “Order Details” (line 41) and “Customer Details” (line 191) titles do not have the same h tag. It’s nothing more than that, probably just a typo.

As the css, I didn’t dig into that precisely but it looks like the theme style doesn’t apply to these headings. Firebug shows the following classes : .woocommerce-checkout .checkout-confirmation h2 or h4.

Thank you,
Ammie

[saturnerond]

Aaaaah… thank you sooooo much matteh for the clue 🙂

In my case I had to do it the other way (using ‘swiftframework’ as textdomain keeps loading the parent theme .mo file).
In case other users would have the same issue, I needed to override the translation for the “Out of Stock” badge :

1 – In the child-theme functions.php file, I keep neighborhood-child (or whatever name) as textdomain :

<?php
function my_child_theme_setup() {
    load_child_theme_textdomain( 'neighborhood-child', get_stylesheet_directory() . '/languages' );
}
add_action( 'after_setup_theme', 'my_child_theme_setup' );
?>

2 – In theme/child-theme/woocommerce/single-product/product-image.php, I edited the file to replace ‘swiftframework’ with ‘neighborhood-child’. For instance :

// Line 24 - Change
echo '<span class="out-of-stock-badge">' . __( 'Out of Stock', 'swiftframework' ) . '</span>';

// To
echo '<span class="out-of-stock-badge">' . __( 'Out of Stock', 'neighborhood-child' ) . '</span>';

As overriding woocommerce .mo file specifically I did it the “woo” way and saved my custom .mo file in a wp-content/languages/woocommerce folder. As far as I can see, Neighborhood theme and Woocommerce do not translate the same strings.

Ammie

[saturnerond]

Thank you Laranz,

Well. I’m still unable to make that work. I attach a screenshot of my files name/path along with the content of my child theme functions.php file.

So far I tried :
– Change translation for “My account” –> Doesn’t work. Apparently the issue is not woocommerce-specific
– Placed the add_action line before the function –> Doesn’t work
– Placed my modified fr_FR.po and fr_FR.mo files in neighborhood-child root directory and used load_child_theme_textdomain( ‘neighborhood-child’ ); –> Still no success
– Uploaded fresh WordPress 4.1.1 files (except wp-content and wp-config.php) and fresh Neighborhood 2.16 files –> Still doesn’t work
– Checked my .po file is actually modified and my child theme activated : Yes!
– Disabled all plugins except those required for the theme, cleaned database and deleted transients –> No change
– I don’t know if this is expected or not but when I change define(‘WPLANG’, ‘fr_FR’); for define(‘WPLANG’, ‘en_US’); in the wp-config.php file, then the site frontend is still in French.
– NB : I do not have WPML nor cache plugins installed.

Do you see anything else I could try?

Thanks a lot,
Ammie

Attachments:

You must be logged in to view attached files.

[saturnerond]

Ooops,
No, I didn’t managed to resolve the issue. There was just a typo in my first message that could have made Mr Laranz confused. But my code still doesn’t work, with or without typo.
Sorry for the confusion.
Ammie

[saturnerond]

Thank you Mohammad.
There is a typo in my code snippet above. The path is ‘/languages‘, with a S.
Thanks.
Ammie

[saturnerond]

Hi Mohammad,
Just to say that your replacement tabs.php file does the job indeed –It makes the Description accordion open by default.
Many thanks for that,
Ammie

[saturnerond]

Hi there,

An additional tip. In order to make icons get the Alt. font color, you need to use both h tags as Ed suggested above AND the usual Font Awesome <i></i> text format (do not use the icon shortcode).

PS : I didn’t check that further but apparently, in a boxed content element, using h tags would on the contrary make the custom font color revert to default. That would make the custom font color usable for paragraph text only.

Cheers,
Ammie

[saturnerond]

You’re welcome 🙂

[saturnerond]

Hi there,
This issue (Font Awesome v4.1 availability) is sorted out with the theme 1.81 last version released yesterday. Just need to update the theme.
Cheers

[saturnerond]

Thanks for the update, works perfect!
Yes I had updated both fonts and css but obviously had done something wrong too.
Thanks again,
Ammie

[saturnerond]

Hi Ed,

Better, but still not okay sorry.

If this can help to find a clue :
I’m on local server, Safari 6.1.4 and using FA icons in Chart shortcodes (large size):
– fa-align-center (old icon) : okay
– fa-pagelines (old icon) : I get a vertical rectangle instead
– fa-eye (old icon) : okay
– fa-paw (new v4.1 icon) : the vertical rectangle
– Checked in Firefox : None of the icons are working. I get a vertical rectangle with something inside that looks like the icon code (F something, 4 letter/number). PS : as well as for the + (add to cart) and * (whishlist) icons on product thumbnails. However my Firefox is stuffed with blocking extensions, so I am not sure this clue is relevant.
– Changed the “font” folder name for “fonts” : No change. Also tried the contrary (keeping “font” folder name and changing path to font files for “font” in the new FA css file) : still no change. Okay, I deleted the font folder and I still see the same icons as above.
– Yes, I empty cache each time I make a change.

Again, I can wait for the theme update, no emergency.
Thank you,
Ammie

[saturnerond]

Thank you all for your attention to this detail,
Mohammad, what you suggest is what I tried and this didn’t work. When updating the font-awesome.min.css file, all icons are lost.
Never mind. I can survive till next update 🙂

Ammie

[saturnerond]

Provided that uploaded images are large enough and Woocommerce Image Size settings are okay (what image size/Woo settings are you using?), I’m afraid this is not a bug but simply due to the way WordPress itself processes image resizing when generating thumbnails. Basically, WordPress is not as good as an image editor. There are plenty of posts about that on the web.
That being said, keep in mind that on the contrary of web designers e-shoppers rarely look at a page for more than a few seconds. Most of them won’t notice that the product image is not crystal clear. If they do stay on the page and look at product details, the zoom or lightbox features can then provide them with the full-size, sharper image.

If really you need better quality thumbnail images, then the only convenient solution would be to have the Imagick php engine installed on the server (ask your web host) and to process your uploaded images with the help of WordPress ImageMagick plugin. I didn’t try that however, just a suggestion.

Ammie