In the WP Social plugin, specifically in the share.php file (line 406), there was an issue with how the URL for sharing a product was generated on product pages. The problem occurred when individual product blocks were placed on pages with more than 10 products. In these cases, each product block contained a shortcode with social media buttons, but the URL generated was not always correct for the specific product. Instead of providing a unique URL for each product, the plugin was generating a shared URL based on the current page’s URL (for example, page 4 or page 5 with a generic title of the product, rather than a link directly to the product).

This caused confusion for users and hindered proper social media sharing for individual products, as they were sharing the link to the page rather than the direct link to the product itself.

Analysis:

Upon reviewing the problematic line in the share.php file:

$currentUrl = (isset($_SERVER['HTTPS']) && sanitize_text_field($_SERVER['HTTPS']) === 'on' ? 'https' : 'http') . '://' . sanitize_text_field($_SERVER['HTTP_HOST']) . sanitize_url($_SERVER['REQUEST_URI']);

This line was constructing the URL using the current page’s URL, which works fine in many cases but fails when a product block is embedded within a page that lists multiple products. Here, the page’s URL (e.g., page/2 or page/3) was used, leading to incorrect sharing links for individual products.

Temporary Solution:

To address this issue, I implemented the following condition:

$currentUrl = '';
if ( 'product' === get_post_type($postId) ) {
    // If it's a product, get the correct permalink
    $currentUrl = get_permalink($postId);
} else {
    // If it's not a product, use the current page's URL
    $currentUrl = (isset($_SERVER['HTTPS']) && sanitize_text_field($_SERVER['HTTPS']) === 'on' ? 'https' : 'http') . '://' . sanitize_text_field($_SERVER['HTTP_HOST']) . sanitize_url($_SERVER['REQUEST_URI']);
}

This code ensures that if the current post is a product (via the get_post_type($postId) check), it will use the correct product permalink (get_permalink($postId)). Otherwise, it will fallback to using the current page’s URL as before. This provides the correct sharing URL when a product is on a page with multiple product blocks, ensuring that each product has a unique URL to share.

Benefits of the Solution:

1. Correct Product URL: When the post is a product, the correct permalink for that product is used, ensuring that the shared link points directly to the product page rather than a generic page URL.
2. Fallback for Non-Product Pages: For pages that are not product-specific, it continues to use the current page’s URL, which works as intended.
3. Cleaner Sharing: The correct URL ensures that users can share individual product pages rather than a generic page, improving the sharing experience and accuracy of the shared links.

Temporary Nature of the Solution:

This solution is a temporary fix that I implemented to ensure the correct URL is passed for product pages while still using the existing behavior for other pages. I hope this improvement will be included in future updates of the WP Social plugin so that I no longer need to patch this line myself. Ideally, a hook could be added for easier customization, allowing developers to override this behavior without needing to modify the core plugin files.

Why This Is Important:

For those using the plugin on product pages where multiple products are listed, it is crucial to ensure that each product’s URL is shared correctly. Without this fix, social media sharing would point to a generic page URL instead of the specific product link. This is particularly important for websites that rely on e-commerce features, as it allows users to share specific products, driving more accurate traffic and improving product visibility.

By implementing this fix, I was able to make sure that each product block has a unique shareable URL, making the sharing experience more effective for both users and site owners.

First, I want to thank the developers for the fantastic WPMovieLibrary plugin. It’s been a wonderful tool for managing my movie review library. However, I’m facing a few challenges and would like to know if there are solutions or recommendations for the following:

1. Changing the default slug “movies”
   The plugin generates a page with the slug “movies,” which displays my latest movie reviews. I would like to change this slug to “films” to better match my native language and improve SEO in French-speaking regions. Is there an easy way to customize this slug?
2. Using both the archive page and the recent reviews page simultaneously
   I would like to use the archive page provided by the plugin to list all my movies, while also keeping the “movies” page (or its customized version) for the most recent reviews. However, activating the archive page seems to automatically redirect the “movies” page to it. Is there a way to keep both pages functioning independently?

Steps to reproduce the issue:

• Activate the archive page in the plugin settings.
• Attempt to access the default “movies” page.

Environment Details:

• WordPress version: [WordPress 6.7.1]
• PHP version: [8]
• Browser: [Chrome 131.0.6778.205 (Build officiel) (64?bits)]
• Plugin version: [2.1.4.9]

I would greatly appreciate any advice or guidance on how to address these issues. Thank you in advance for your help!

Best regards,
Carl

.gtranslate_wrapper a.glink {color: #fff !important; /* White switcher text */}

But when the popup opens, again white text color appears with the default white background, which I am aware of. Now I would like to change the text color when the popup opens.

Other questions, 1. How to change the fonts 2. Why nice drop-down expanding the whole section/container 3. Why is the customization of the plugin very limited (at least the nice drop-down has some option to change the colors)?

Once again, thank you for your nice plugin, and I look forward to your reply.

I recently updated to version 5.0.6 of the WordPress Simple PayPal Shopping Cart plugin and am pleased with the improvements.

I have a feature request that I believe would enhance the plugin’s flexibility: Could you consider adding a custom hook in the calculate_cart_totals_and_postage() function? This would allow users to implement their own postal cost calculation routines.

Adding this hook would significantly increase the customization options available, making the plugin more versatile for various use cases. The hook could look like that:

/**
 * Custom hook to allow modification of the postage cost.
 *
 * This filter allows developers to provide their own custom postage cost calculation routine.
 * It gives access to the WSPSC_Cart class instance which can be used for additional context
 * or logic when calculating the postage cost.
 *
 * @since 5.0.7
 *
 * @param float        $postage_cost The default postage cost calculated by the plugin.
 * @param WSPSC_Cart   $this The instance of the WSPSC_Cart class, providing
 *                           context and additional methods/properties if needed.
 * @return float The modified postage cost.
 */
$postage_cost = apply_filters('wspsc_custom_postage_cost', $postage_cost, $this);

Many thanks for the good work,
regards Valentin

And it’s also showing on the frontend:

But the issue is when I submit the form it’s indicate the error called “File is a required field and can not be empty.” I already try to attached different file type but the error remains the same so can someone help me with that it’s gonna be a very much appreciating.

I have two problems with Bricks and meta description generation and I think Slim has something to do with them.

1. It seems that Slim doesn’t use post extract, if it is filled, to generate meta description for posts, but renders the content of the post and keep the first few words.

But in Slim’s post metabox, if no meta description is filled, post extract is displayed as placeholder, if filled, so users believe extract is used, this is very confusing and misleading.

I think Slim should ALWAYS use post extract if it is filled and if description in metabox is empty. ONLY if BOTH are empty, then render content.

I added this PHP snippet to fix this:

add_filter( 'slim_seo_meta_description', function( $desc ) {
    if ( is_singular( 'post') )
        $desc = get_the_excerpt();
    return $desc;
} );

2. When Slim generates meta description from content, H1 title is included at the beginning.

But most of the time, if not all the time, my H1 titles are equal to meta titles, so meta description always replicates the meta title, which is useless and harmful since there’s few characters left for the actual description.

Sometimes there are also category tags or post meta like date or comments at the beginning of post content, and they are included in description, which is not wanted.

As a conclusion of this and also for performance purposes, I really think Slim should not mess with meta descriptions and leave user decide if he wants to leave them empty or not.
Google renders them better than Slim, anyway, and it will push user to write a correct description.

Thx and have a good day!
Yan