ig_communitysites

Hi,

Thanks very much for getting back to me, and for your thorough reply.

1) It really connects with the third point – the one about having a list of any file changes since the last scan in the email. Once that facility exists – and we’ve put in a temporary hack to make it happen for now – then we’d quite often not need to go to the site to do a review at all.

As an example, if I deploy some custom theme or updated plugin code to all of our 125+ WP sites, then the monitor will rightly flag those changes at its next scan. If I look at the emails and can see that those are the only changes I’m being notified about, then I can be reasonably certain that all is well and that there’s nothing to review. Having to visit 125+ sites and delete the notifications is just rather a lot of time wasted at that point.

In other words, the occasions when we’d actually need to review notifications are far, far fewer than the occasions when we’d look at the list in the email, mark it as read and get on with the day. For that reason, it’d be great if the plugin could manage itself as much as possible, particularly when it comes to clearing up stale notifications.

But this is only how we’re using it. No offence taken if you decide to go down a different route. You can’t please everyone. ??

2) I can add .htaccess as an exclusion, but I assume that’d exclude all .htaccess files regardless of location. If I attempt to add /home/blah/public_html/.htaccess – thus being specific about one particular file – then I get a message about invalid characters. Am I missing something?

3) Awesome.

Best wishes,

ian.

Given the lack of a response, I’ve had to apply a hack to solve this issue. For what it’s worth, this is the revised code:

function nxs_removeAllWPQueryFilters() { remove_all_filters( 'posts_orderby' ); remove_all_filters( 'posts_where' ); remove_all_filters( 'posts_fields' ); remove_all_filters( 'posts_clauses' );
  remove_all_filters( 'posts_distinct' ); remove_all_filters( 'posts_groupby' ); remove_all_filters( 'posts_join' ); remove_all_filters( 'post_limits' );
  
  global $acf;
  if ($acf) 
    add_filter('posts_where',        array($acf, 'posts_where'), 10, 2 );
}

…so that reinstates the ACF filter. It seems very questionable to simply remove all of those filters without any consideration for what they might be doing, so I’d hope that a future update might take a more subtle approach and that we’d therefore be able to remove that hack.

I’ve done some further tracing through the code. The problem is in this function: nxs_removeAllWPQueryFilters which is called by nxs_snapPublishTo. Specifically, it’s with the removal of the posts_where filters which presumably ACF needs to be able to find its fields and save its data.

Can you look at that, please?

Definitely appears to be an issue here.

We’re using SNAP 4.1.1 and ACF Pro 5.6.7, with posts being published to Facebook. If we create and publish a new post, none of the ACF custom fields are stored; that appears to happen whether or not the post is being published to Facebook. The fields in question include standard text fields, so nothing special.

Curiously, the problem still occurs even if comment out these lines in SNAP:

add_action('edit_post', array($nxs_SNAP, 'NS_SNAP_SavePostMetaTags'));
    add_action('publish_post', array($nxs_SNAP, 'NS_SNAP_SavePostMetaTags'));
    add_action('save_post', array($nxs_SNAP, 'NS_SNAP_SavePostMetaTags'));

If I deactivate SNAP, however, ACF goes back to working correctly. So SNAP is definitely the culprit.

Any ideas, please?

This is now resolved: it was a conflict with another plugin (WP Inline Comment Errors), presumably caused by that plugin sticking its oar in during the AJAX call.

Yup, that seems fine now. Thanks very much indeed.

Thanks, John. Yes, it looks like that works very well. Great stuff.

Having done some further testing, it looks as if the only thing which stops it from working is that the custom fields are loaded into the taxonomy form via AJAX and so aren’t present when the initial qTranslate field setup takes place.

If I add something like this into edit-tag.js:

setTimeout(function() {
            qtx.addContentHookByIdC('acf-field-category-subtitle', form);
        }, 5000);

then the addContentHookByIdC call takes place after ACF’s AJAX call has returned and the acf-field-category-subtitle field is set up correctly for qTranslate.

(I realise that’s a very crude method! It hopefully demonstrates that the timing of the addContentHookByIdC call is the only problem, though.)

To be honest, it does cause us problems as we use taxonomies with custom fields quite a lot. I’m investigating whether I can get it working myself, so will post anything I manage to work out.

Thanks very much for your patience, John. You’re quite right: upgrading both your plugin (which was on v3.9.6) and ACF (which was on v4.3.4) means that it works out of the box. Bingo. I’m going to give myself a slap on the wrist for not trying an upgrade of ACF sooner.

So, there’s only one thing which doesn’t work…and I don’t imagine this is going to be an easy one! ACF allows you to add custom fields to taxonomies as well as posts. It adds those custom fields to the taxonomy/category form via AJAX calls. Any suggestions on how I can make those work?!

Thanks for your help, John, but that isn’t the issue. I have indeed set up the fields via their ID value, and that works fine on the form itself.

But it doesn’t work when the data is saved and passed through the $_POST array…because that uses the “name” attribute. Because of the way that qTranslate-X changes the field names, you end up with input name attributes like this:

fields[field_536b984656093]_edit

…which results in the data not coming through correctly in the $_POST array. When you change it to:

edit_fields[field_536b984656093]

it all works fine.

No, ACF just adds very basic, generic class attributes. Here’s an example field:

`<input type=”text” id=”acf-field-catalogue_item_metadata_contributor” class=”text” name=”fields[field_536b984656093]” value=”” placeholder=””>

So, here’s my attempt…

Firstly, I’ve copied the old ‘upload_path’ method from the old plugin:

// ikg/commsites - method taken from old tantan s3 plugin to generate sub-site prefix
    // no equivalent function in the current plugin as far as I can see
    // figure out the correct path to upload to, for wordpress mu installs
    function upload_path($path='') {
        global $current_blog;
        if (!$current_blog) return $path;
        if ($current_blog->path == '/' && ($current_blog->blog_id != 1)) {
            $dir = substr($current_blog->domain, 0, strpos($current_blog->domain, '.'));
        } else {
            // prepend a directory onto the path for vhosted blogs
            if (constant("VHOST") != 'yes') {
                $dir = '';
            } else {
                $dir = $current_blog->path;
            }
        }
        //echo trim($path.'/'.$dir, '/');
        if ($path == '') {
            $path = $current_blog->path;
        }
        return trim($path.'/'.$dir, '/');
    }
    // ikg/commsites - ends

…and that seems still to work all right. Then, I’ve found the new plugin code which generates the path to the file and inserted a call to that function there:

$prefix = ltrim( trailingslashit( $this->get_setting( 'object-prefix' ) ), '/' );
        $prefix .= ltrim( trailingslashit( $this->get_dynamic_prefix( $time ) ), '/' );
        // ikg/commsites - hack to add sub-site sub-domain to the path to recreate old tantan s3 functionality
        if (is_multisite()) {
            $site_prefix = $this->upload_path();
            if ($site_prefix) {
                $prefix = $site_prefix.'/'.$prefix;
            }
        }
        // ikg/commsites - ends

I haven’t had a chance to fully test that yet, but it does appear that the uploaded file ends up in the right place: in a folder named after the sub-site. Not a perfect solution, I imagine, but it might at least patch things up while that functionality’s built back into the new plugin.

It looks to me as if the code for adding the site prefix to the upload path simply isn’t in the plugin any more: I can’t see that it’s even attempting to add it anywhere.

There used to be an ‘upload_path’ method in the old Tantan S3 plugin for handling that prefix, which was called via an ‘option_siteurl’ filter, but it’s nowhere to be seen in the current code. Everything’s changed quite a lot, obviously, so it’s difficult to compare precisely…but I haven’t found any equivalent code from rummaging around. There’s a ‘get_base_upload_path’ method, but that explicitly states that it’s ‘without the multisite subdirectory’ in a comment.

As with you, Bob, we’re upgrading from an old 3.4.1 site which has already been uploading files to an S3 bucket with prefixes for each sub-site on the network. So we can’t really do that upgrade if the functionality is just going to disappear: we need that to be consistent.

(Scratches head.)

Had this problem too, and fixed by changing this:

function comment_status( $comment_id, $comment_status ) {
   if ( $comment_status == 'approve' ) {

to this:

function comment_status( $comment_id, $comment_status ) {
    global $comment;
    if ( $comment_status == 'approve' ) {

The problem seems to be that the shortcode function tries to load the comment data from the global $comment object, but doesn’t get anything back. The code change means that the comment gets loaded.

Hope that helps.