Forum Replies Created

Viewing 15 replies - 1 through 15 (of 333 total)
  • Thread Starter Clicknathan

    (@clicknathan)

    That is absolutely good news, and frankly was unexpected. I’ve been a customer of SG for several years now and this is helping me remain confident that you guys are still the correct choice.

    Thread Starter Clicknathan

    (@clicknathan)

    The topic was also marked as resolved, which is not the case.

    Thread Starter Clicknathan

    (@clicknathan)

    User @skolcs posted the following, but it appears to have been deleted due to an inane policy about creating new posts. This is my post, and I deem that it is appropriate to have this “second” here.

    Hey, so this is a *huge problem*! It looks like the “solution” was to put a warning when you deactivate this feature, and then call it “intended behavior”. A warning is not a legitimate solution to this.

    Imagine: you have a website that you have years worth of .webp files that you manually uploaded. You migrate your site to Siteground, and enable all these cool new features, and later decide to (or accidentally) disable the WebP feature…. and now your entire media library 404s.

    OK, so you restore from a backup, and now your webp files are back, but that feature is re-enabled (because it was in the backup). You now have no way to disable that feature safely without disabling the plugin entirely.

    Let’s call this what it is: a bug that would require time and effort to resolve, yes, but the right thing to do is to fix this, please.

    Thread Starter Clicknathan

    (@clicknathan)

    That is reassuring. I’d hate to think that a fix to this might happen but then it wouldn’t be included int eh changelog. Oh the humanity!

    Can you clarify what you experienced when you say “with legacy ones regenerating all images successfully” but then say “It allowed the ‘Force Regenerate Thumbnails’ plugin to convert existing WebP images to AVIF, none of which came out okay and needed manual replacement”?

    Your subject is true! But the Block editor has many deficiencies with how it handles code on the front end (ie, way too much – bloat is another negative aspect of the human experience, in both code and the gut!) and making it much more difficult for some developers to create the experience they want their clients to have.

    Not everyone uses WordPress the same way, and it is therefore also worth considering that you may not currently have the ability to do what many of us still wish to do. Unfortunately, perhaps, these skills are not obtained in just a couple of hours, but takes months to learn and a lifetime to master!

    @macmanx, while I do realize you are likely volunteering to be a moderator, there isn’t much value in a response that shows no attempt at any research. Ideally, moderators would be aware of code changes in WordPress before repeatedly asking people to do the “disable everything” shuffle.

    And I agree with, but would take @robin_dean ‘s approach one step further. Malicious code is defined by Google as:

    Malicious code is any software, script, or program designed to harm, disrupt, or compromise systems and information.

    Code which deteriorates a theme developer’s intentions and bloats themes by adding code to our sites which we do not need can easily be defined as harmful and certainly, for those of us who still believe in the mantra that “code is poetry,” it compromises our information.

    That this thread exists is also evidence of disruption.

    So yeah, fairly malicious code and arguably irresponsible moderation.

    Thanks to the rest of the community here for actually working on a solution!

    Forum: Fixing WordPress
    In reply to: ACF Error

    I was able to resolve this issue by removing the following code from functions.php, which was being used to try and show WP’s default custom fields interface even with ACF installed.

    // show default custom fields, even with ACF add_filter( 'acf/settings/remove_wp_meta_box', '__return_false' );

    I also experiencing this, with ACF 6.3.9.

    I was able to resolve the issue by removing this code (which was used to bring back default Custom Fields meta boxes):

    // show default custom fields, even with ACF add_filter( 'acf/settings/remove_wp_meta_box', '__return_false' );

    Thread Starter Clicknathan

    (@clicknathan)

    Thanks for the response. I really do think you’ve created an awesome plugin.

    Here are responses to your questions:

    Could you please let us know which post type you’ve selected for the import? Is it posts, pages, or taxonomy?

    Taxonomy.

    Additionally, if you could share the name of the custom fields plugin you’re using, that would help us provide a more accurate solution.

    I create custom fields manually via functions like add_post_meta

    In the free version, custom fields for taxonomy terms are not supported—this feature is available in the Pro version.

    That’s completely acceptable of course, except the plugin as is does allow you to upload taxonomy terms and use custom fields – at least the interface allows for this. But once you’ve done it, those custom fields area attached to POST ids instead of TERM ids. So it’s altering post meta in a way that is not clear, and I suspect you as the developer do not intend it to do, with your current interface.

    For anyone who may come across this, the fix was:

    1. You have to create a taxonomy term and then, in your database — via PHPMyAdmin or something, increase the term_id to something higher than your largest current post ID. If this is daunting to you, the instructions below may not be for you.
    2. Then, you can import all custom field data as the term’s description. Best to separate each item by something that will never be used in one of your custom fields. For me, a comma was sufficient, but a | or ; or something might be better for your needs. I was able to use commas so that my CSV rows were like some custom field data, another custom field value, yet another custom field value, and so on
    3. In that example, “some custom field data” was the value of one custom field, “another custom field value” was the value of another, etc.
    4. Then you can set this code up on your site to look at all of those term_descriptions and convert them to custom fields.
    $terms = get_terms( array(
    'taxonomy' => 'your_custom_taxonomy',
    'hide_empty' => false,
    ) );

    foreach ($terms as $term) {

    $description = $term->description; // gets the term's description, where we stored our custom fields
    // replace the ',' in the next line with your separator, as per my #2 point above.
    // If you used a | then you'd have '|' there.
    $fields_array = explode(',', $description);
    // these next three lines relate to the custom field values as per my point #2 above
    $some_custom_field = $fields_array[0];
    $another_custom_field = $fields_array[1];
    $yet_another = $fields_array[2];

    // here we take our variables above and make them custom fields
    update_post_meta( get_the_ID(), 'custom_field_key_1', $some_custom_field, true);
    update_post_meta( get_the_ID(), 'custom_field_key_2', $another_custom_field, true);
    update_post_meta( get_the_ID(), 'custom_field_key_3', $yet_another, true);

    }

    Always good to create a backup of your database before doing such a thing, of course.

    OP is referring to Woocommerce’s output for the function woocommerce_show_product_images()

    By default, this function outputs the following opening div code:

    <div class="woocommerce-product-gallery woocommerce-product-gallery--with-images woocommerce-product-gallery--columns-4 images" data-columns="4" style="opacity: 0; transition: opacity .25s ease-in-out;">

    If you’ve elected to remove Woocommerce’s tons and tons of scripts, then this renders the entire image gallery invisible. They are specifically asking how to remove the inline style from that block of code just above.

    Unfortunately, the only way to remove this – aside from using Javascript after the page loads – is to override Woo’s product-image.php file.

    Since so many people still use the Classic Editor, the designers of the Block Editor should understand that to mean that something is seriously wrong with the block editor.

    While I don’t disagree with this statement, if anyone at WP is listening – some of us just like to be able to write and edit our content as HTML, or one big paragraph. I use the Block Editor for some clients, classic for most. It’s nice to have both options and would be really nice to know we don’t have to worry about Classic ever going away.

    Also seeing this issue still in v 4.1.1

    Thread Starter Clicknathan

    (@clicknathan)

    Thank you Milind, that was exactly what I was looking for.

    Apologies, it takes me forever to get through things over here. But that did indeed work and now it shows up as an option for me on my site. Much appreciated.

    My vote is to not enqueue this by default either. Is there a better place to voice these opinions?

    1. Style vs. content was a big conversation we all had in the 2000s, which helped produce CSS vs. table-and-inline-style sites. Would be a shame to backslide.

    2. It wouldn’t be that hard to mark a post with a custom field, indicating that it was created with the block editor vs. classic.

    3. Adding the CSS in style tags in the head would be better than linking to a resource, or making it an option to toggle off for users who install the Classic Editor plugin.

Viewing 15 replies - 1 through 15 (of 333 total)