Jason Judge

Although what Julian says is true – hiding elements using CSS does hide them visually – I would not recommend taking that approach in most instances.

Making something not visible still involves creating it in the first place and delivering it to the browser. That still involves time and database queries, also transfer bytes. It is also still there in the page, so may still get indexed (you may or may not want that).

In my case, generated the related items was adding over a second to each page generation. It really had to be stopped at source.

— Jason

Here we go – works a dream. In the WooCommerce meta.php template, I check if the get_field_object() function exists (because it won’t if ACF is not enabled), then fetch the two lists:

if (function_exists('get_field_object')) {
            $field_obj = get_field_object( 'field_5062e50c7da52', $product->id );
            if (!empty($field_obj['choices'])) $disc_grade_choices = $field_obj['choices'];

            $field_obj = get_field_object( 'field_5062e62519095', $product->id );
            if (!empty($field_obj['choices'])) $sleeve_grade_choices = $field_obj['choices'];
        }

Further down, after I fetch the custom fields into $disc_grade and $sleeve_grade, I check if those grades are an index value in the lists, then switch in the description if they are:

if (!empty($disc_grade_choices) && !empty($disc_grade_choices[$disc_grade])) $disc_grade = $disc_grade_choices[$disc_grade];

Always erring in the side of safety, of course, because you cannot guarantee a given plugin or theme is going to be there.

The code isn’t rocket science, I know, but may be useful to someone. Thanks again.

— Jason

Brilliant! You’re a star ?? I seldom think of looking in that “screen options” drop-down panel, and forget it contains contextual display options.

I will be using this to expand the grade codes of second-hand disks in this shop:

https://www.soulbrother.com/shop/turn-you-to-love/

Just a simple code is stored (M and M in that example), but I would like to display the full description of those codes, which is defined in the ACF field.

I’ll post the code I use, then close this ticket.

That’s great – thanks. Your example uses this to get the custom field opject:

$field_obj = get_field_object( 'field_506d7b9428874', $post_id );

The “field_506d7b9428874”, where would that come from? I’m assuming it is the custom field ID, but I cannot see that in the ACF admin screens since it is all AJAX and these codes don’t appear in any URLs. Do I need to look at the page HTML source to get that? Or can I just use the “field name” slug as it appears in the admin screen?

— Jason

I’ve changed our indexes to compound indexes, but cannot see any real difference. Since we have relatively few (i.e. two) connection types, there is not much narrowing-down the compound index can do.

On the other hand, it did not slow things down, and the p2p_type index on its own will never be of any use, and will never be used anyway, assuming the database optimiser gets things right. I would personally add it in as the first column on compound indexes for both the “to” and “from” links. That would make the assumption that rows are never selected on “to” or “from” without also having a “p2p_type” in the selection for context. If that assumption is incorrect, then there is no harm leaving it as it is.

Oh well – no real advice there: do it, or don’t do it ??

Yes, that looks spot-on. So that I understand it correctly, so long as that filter returns *something*, then that return content will replace the entire summary for that post?

The way I want to use it, is to display products from a WooCommerce shop. To do that, we have a function we can call up to display a single product, which uses customised formatting (through templates) so we would not want any of the output generated by this plugin. If that is how this filter works, then that is exactly what we are looking for.

— Jason

You do replace the existing loop with the new code, don’t you? The loop is already in the plugin around line 213, and the additional code introduces the filter, the condition (import or skip).

I have put a copy of my modified version of this plugin here:

https://academe.co.uk/2012/10/wordpress-csv-importer-plugin-skipping-duplicates/

Hopefully that will help you.

Blue, this may help you:

In my theme functions.php, I have added this action:

add_action('init', 'my_canvas_hotfix_remove_filters', 999);

The “hotfix” function is then:

function my_canvas_hotfix_remove_filters($query = NULL)
{
    remove_filter('pre_get_posts', 'woo_exclude_categories_homepage', 10);
    return $query;
}

That allows the Posts 2 Posts admin panel to work. Whatever the woo_exclude_categories_homepage filter is, we don’t use it and don’t miss it.

With this in place, the front-end widget works *some* of the time, but we have not followed that up, as we do not use the front-end widget (we link posts with no public pages, and so just operate it through the APIs).

I have raised this as a ticket with WooThemes over a week ago, and not had any response yet. So I have no idea if this is something they see as their problem. What would be ideal is for WooThemes to talk to the developer of this plugin directly. One side, or both sides, is not playing fair with the WP query hooks, or perhaps this is a bug in core WP? Whatever it is, it is something deep inside the Canvas theme that I have not been able to dig out.

— Jason

I’ve solved this same problem using a slightly different approach. Instead of removing the hook, I’ve just overridden the template in my theme. The related products are queried in the WooCommerce template, so overriding the template removes that overhead (and it was an overhead of several seconds for me, as the query was randomising up to 10,000 products, before picking five, and that was heavy lifting for the database).

This method also means I can put my own alternative “related products” into the template.

The template is:

{your-theme}/woocommerce/single-product/related.php

Just create an empty file in that location and the related products will be gone.

— Jason

Now tested, 213 of csv_importer.php:

$skipped = 0;
        $imported = 0;
        $comments = 0;
        foreach ($csv->connect() as $csv_data) {
            $csv_data = apply_filters('csv_importer_validate', $csv_data, $this, $skipped + $imported + 1);
            if (!empty($csv_data) && $post_id = $this->create_post($csv_data, $options)) {
                $imported++;
                $comments += $this->add_comments($post_id, $csv_data);
                $this->create_custom_fields($post_id, $csv_data);
            } else {
                $skipped++;
            }
        }

That filter adds all sorts of possibilities. I am using it in my theme functions.php like this:

add_filter('csv_importer_validate',  'my_csv_importer_validate', 10, 3);

    function csv_importer_validate($csv_data, $importer, $row_number)
    {
        // In here I check if the item has already been imported,
        // based on a "key" custom field. If it has, then I raise a
        // a warning:
        // $importer->log['notice'][] = 'Post key ' . $csv_data['key'] . ' already exists';
        // then return false, and that skips the row. Otherwise I return
        // $csv_data and the row loads as normal.
    }

So, an this filter be added to this plugin? Please? Pretty please?

Around line 217 of csv_importer.php I have added the marked code (untested):

foreach ($csv->connect() as $csv_data) {
            $csv_data = apply_filters('csv_importer_validate', $csv_data); // Call up validation filters
            // Only create post if validation filters did not throw away data
            if (!empty($csv_data) && $post_id = $this->create_post($csv_data, $options)) {
                $imported++;
                $comments += $this->add_comments($post_id, $csv_data);
                $this->create_custom_fields($post_id, $csv_data);
            } else {
                $skipped++;
            }
        }

That allows me to create a custom filter to sanitize any of the data, and also to validate it. In the filter, by returning FALSE instead of the data array, the row can be skipped.

I would probably also pass in the record number, so that can be logged in any validation errors that are subsequently logged. Also pass in $this so that the $this->log['error'][] can be used to send the error or warnings (aka notices) to.

Even if the import does not do updates of posts that already exist (according to the defined “key” field), which would be awsome, the ability to at least skip over posts that have already been loaded would be ideal.

Perhaps if you add a filter to this plugin, that fires on each record before it is created (being given both the core post fields *and* any additional custom fields) then the check for duplicates can be handled in an external plugin.

I’ve put some details here:

https://stackoverflow.com/questions/12809525/getting-hold-of-metadata-when-creating-a-post-in-wordpress

I see what is happening now. The CSV importer will create the basic post first with all its core fields. That is the point at which the save_post action fires. *Then* it adds the custom field data to the post, which is too late for my code in the save_post action to see.

Looking again, the action may be firing, but one or more of the conditions it contains could be causing it to abort.