10up / distributor Goto Github PK

While hierarchical post types aren't the primary use case, there are plenty of conditions – from custom hierarchical post types, to staging pages, to generic about pages shared across sites – where this is useful. Right now, I don't think we "think" about this at all - it just ignores the hierarchy attribute.

Near term, I think we just need to refine the UX to make it obvious that we're not going to do anything with hierarchy. I think that can just mean that – if the current post has a parent or child (in the literal sense, don't want to include things like media or drafts) – the "Distributor" toolbar menu explains / warns that parent / child relationships are not distributed.

I can see a potential future iteration that adds an option to "Include all child posts" (for a use case like a generic about page with subpages or learning module with several child items coming over).

I'm also not clear how - if at all - we handle showing hierarchy in the pull UI?

Wanted to see if there are any reasons we would not like to specify that in the composer.json.
This makes it easy for other projects using the plugin as a dependency in their composer.json file. Currently it goes to the vendor directory by default.

Took me a few moments to find out how to close the admin bar dropdown. Maybe a close button could be a useful addition.

Cheers!

This function tries to retrieve posts and figures out the query parameters, but some of the parameters in these classes are quite expensive and not server/scale friendly at all:

• post__not_in
• meta_query

We need to bundle meta endpoints into the plugin to offer full functionality on external connections.

We use phrases like "Distribute" and "Syndicate" interchangeably through the UI; let's take a pass at making this consistent, leaning toward things like "Distribute" instead of "Syndicate" in the menu interface.

Right now, I don't think there's any "easy" way (without figuring out the post meta) to show that a piece of content (post) has been syndicated / reposted / distributed on the front end, which I would think is a common use case on the front end.

I envision two parts to this (open to feedback).

(1) Create PHP function(s) to output this information. I'd imagine a "the_" type function which prints out the link site named and a preface that can be overridden with an optional parameter, like "Distributed from" (would not return anything if it was forked – maybe that can also be set with an optional parameter - or wasn't distributed). I'd also imagine a "get_the_" type function which could return an array of information: the name of the site it was distributed from, the link to the original, and maybe some other information like whether it was forked.

(2) In a later version, I can imagine an optional setting (off by default) that injects this information, for someone who doesn't want to edit code on each site. For example, it might "take over" the author byline (instead of "Post by [linked author name]" it could say "Post by [Site Name linked to original]", or be injected at the top of the post.

We have a pretty big network of sites. All of them need to show proper author information. I see that as of right now Distributor will set the distributed posts author to the authenticated users ID. I'd like to change this (and am willing to do the work myself). Here's two possible solutions:

1. The simplest method is to just pass through the user ID of the original post author and leave it up to admins to make sure their user IDs are synced across all sites. This gets a bit easier if you are using an SSO plugin of some kind.
2. Add a hook to the post creation (or use the existing dt_item_mapping for pull or dt_push_post_args for push filter) to allow passing the "correct" author ID based on the existing post author ID and what site we are posting to. This would require end users to have a map or database of current site author ID to external site author ID. Not the hardest thing in the world for a lot of admins to build, but still a pretty high bar. If people think this is the best route, I would most likely write my own solution and document it in README.md. Eventually, a UI could possible be created in Distributor to manage this.

Anyway, looking for feedback on which path to go down or a different path entirely. I'm looking to get this done ASAP and would of course submit any changes to the plugin back.

If there's only one site available to push content to, a simplified user interface will reduce clicks and cognitive overhead.
Mockup suggestion for one site: https://cl.ly/2o1F3r0v292i
Current screenshot: https://cl.ly/412a0h022N04

Hey guys, I'm testing this on both my beta site and the site I'm trying to link it to, and neither are firing the script when you click the "Distributor" button in the top bar of the post. I've tested with plugins all off and on, and with caching clear, and nothing's showing up.

Wordpress version is 4.9.4. Tested on both HTTP and HTTPS, with current version. Any thoughts?

Can you add the .DS_Store hidden mac file to the .gitignore.

.distributor-push-wrapper .as-draft should have a color set (white?). Currently it inherits a dark gray from the twentyseventeen theme and is not visible.

Notice: Undefined index: post in /REMOVED/wp-content/plugins/distributor/includes/classes/ExternalConnections/WordPressExternalConnection.php on line 127

Fatal error: Uncaught Error: Cannot use object of type WP_Error as array in /REMOVED/wp-content/plugins/distributor/includes/classes/PullListTable.php:384

Stack trace:

#0 /REMOVED/wp-content/plugins/distributor/includes/pull-ui.php(297): Distributor\PullListTable->prepare_items()
#1 /REMOVED/wp-includes/class-wp-hook.php(286): Distributor\PullUI\dashboard('')
#2 /REMOVED/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters('', Array)
#3 /REMOVED/wp-includes/plugin.php(453): WP_Hook->do_action(Array)
#4 /REMOVED/wp-admin/admin.php(224): do_action('distributor_pag...')
#5 {main} thrown in /REMOVED/wp-content/plugins/distributor/includes/classes/PullListTable.php on line 384

The above is displayed on the Pull Content screen when connecting to a site that uses the Force Login plugin.

When the Force Login plugin is not active everything in Distributor works as expected .

I use the recommended authentication method (Application Passwords).

Connecting and posting to the site using cURL or Python Requests seems to work fine whether Force Login is active or not.

Let me know if you need any more information.

Cheers!

The highlight that appears on selected connections makes me think those items can be clicked to un-highlight them (or remove them) from the list on the right. I recommend the item on the left is removed once it's selected. For short lists we could use a simple toggle, but that interaction breaks down once we have a longer, filterable result set. For extra credit, have a very quick (200-300ms) animation of the item moving from the left to the right to further reinforce what's happening.

It would be nice if current plugin updates would be supported via the GitHub Updater plugin one installed. I can submit a PR for this as it looks pretty simple to support.

This includes:

• Push
• Pull
• Connection checking
• Remote get

If the default behavior of the Pull Content view was showing me the latest posts on the multisite network, I could:

• get an overview of posting acitivity without leaving the plugin.
• avoid having to select an option from the drop down menu in most cases.

The is_vip checks work well for WordPress.com VIP sites, but they unfairly remove features from VIP Go. E..g the network connection with switch_blog could pass review on a VIP Go site, but would never be available

Similarly some checks assume too much, e.g.

			if ( is_vip() ) {
				$types_response = vip_safe_wp_remote_get( $types_path, array(
						'timeout' => 5,
					)
				);

Here the conditional should be if ( function_exists( 'vip_safe_wp_remote_get' ) ) { which would make the code more flexible and adaptable

We should be using current_time( 'timestamp' ) instead of time() to store dt_syndicate_time meta since there are instances where we can encounter a timezone difference in the published and synced time -> https://cl.ly/15022l2G2O2i

Distributor bundles extra fields when creating posts then uses that to side load images.

However on .com VIP this means broken images as the machines serving requests do not have write access. The result would be broken 404 images in distributor posts

We do have the core media endpoints that could be used, if distributor pre-populated the attachments prior to the request that would sidestep the issue and prevent the need for the extra rest data on push

In the meantime I'm working with our systems team to see if this can be remedied, though that will take some time and I won't have that information today

Hey

I'm probably missing something simple, but my test connections always get this message:

Limited connection established.
Push unavailable.

I'm using the suggested /wp-json endpoint and an Administrator login

This one will be simple.

Once some form of #68 gets implemented it won't make much sense to continue using a username/password combination for authentication. Even without #68 being implemented, username and password authentication usually is not the most secure or stable way to authenticate.

I'd like to gather feedback about implementing some form of two way handshaking between Distributor instances to allow for easier initial setup (only having to configure connections from one side, assuming the other side has "allow new connections" set) as well as long term authentication to the REST API using exchanged tokens specific to a single Distributor install instead of username/password. My personal recommendation for token management and authentication would be a forked version of the JWT plugin but instead of generating tokens from username/password, it would generate tokens if a proper request was presented from a previously authorized (via the initial setup handshake) request.

A lot of the groundwork for alternate authentication styles was completed via #58, my initial research shows a new authentication style should pretty much be drop in. I'm not necessarily suggesting username/password auth is even removed quite yet, i'm just looking for an alternative to be provided.

I'm the only user of multiple sites, actually a mutisite instance, and even I don't do my normal day-to-day edits as an Administrator. My normal account is an Editor. This plugin should have a the ability to set which roles can pull and publish content independently of the plugin configuration settings. As it is I don't see any capabilities define to even assign to existing roles. Perhaps that would be the first step is to add capabilities that someone could assign via a role management plugin.

These will be tricky. There might not be much we can do. However, there is a ton of logic in these files around display of connections. It would be awesome to test some of it.

Logging this as an issue to be followed up on:

With this filter, $post_arr is actually the distributed post ID.

https://github.com/10up/distributor/blob/master/includes/classes/InternalConnections/NetworkSiteConnection.php#L114

I pulled a piece of content that did not have a custom excerpt defined, but it takes a generated excerpt and saves it as an explicit custom excerpt.

From the site doing the pulling:

The plugin seems to have a few issues on multisite. My use case is I would like to have one blog in the multisite and have it shared across all the others. A total of about 30 sites.

1. Loading the pull page is very very slow.
2. Not all site the sites on the network are listed in the dropdown.
3. There is no distinction between post types when content is listed.

Setting up remote connections is causing some confusion with early testers; I think our warning messages might be a bit too vague.

Can we be a bit more specific in catching and explaining common failure use cases? Like the REST API not being available, not finding a secure connection (even linking to a recommended auth plugin), Distributor not being detected on the other end... ?

This issue was originally reported by @coenve who also provided the cod used to correct the issue in their testing. subscriptions may need attention as well.

I was missing support for custom post types. After a couple of hours of hacking and changing your code, I just got it finished and working.

You probably tried to create it on an earlier date, but if you use post_type instead of type as an url parameter, it doesn’t work. Wordpress doesn’t allow it, so I used type instead. Feel free you my code and maybe optimize it a bit. It works ☺

WordpressExternalConnection.php

$post = $this->remote_get( [ 'id' => $item_array['remote_post_id'] );
->

 $post = $this->remote_get( [ 'id' => $item_array['remote_post_id'], 'post_type' => $_GET['type'] ] );

if(empty($post_array['post_excerpt'])) {  unset($post_array['post_excerpt']); } 

BEFORE: $new_post = wp_insert…..

PullListTable.php

$remote_get_args['post_type'] = 'post'; ->

$remote_get_args['post_type'] = (!empty($_GET['type'])) ? $_GET['type'] : 'post';

In the form at the bottom of pull-ui.php

<input type="hidden" name="type" value="<?php echo $_GET['type']; ?>">
At the top of pull-ui after the connections select

<select id="ptype" name="type" method="get">

                                        <?php

                                                $local_post_types = get_post_types(array('public' => true, 'publicly_queryable' => true));

                                                foreach ($local_post_types as $ptype) :

                                                        if($ptype == $_GET['type']) { $selected = true; } else { $selected = false; }

                                        ?>

                                                        <option <?php selected( true, $selected ); ?> data-pull-url="<?php echo esc_url( admin_url( 'admin.php?page=pull&type='.$ptype.'&connection_type=' . $type . '&connection_id=' . $id ) ); ?>">          

<?php echo esc_html($ptype); ?></option>

                                        <?php endforeach; ?>

                                </select>

Only thing you have to change is the .JS-file that the url changes if people use the select box.

wp-admin/admin.php?page=pull&type=<POSTTYPENAME>

For the plugin to work on WP.com it'll need to use the OAuth2 Authentication .com uses, the basic Auth mechanism won't work/pass review

Being able to trigger a syndication for a subset of posts via a cron would be very helpful. The option of a time of day schedule or a recurring elapsed time would be ideal.

The interface should allow a query to be built using any combination of post data, taxonomies or metadata plus options like search, since, record limit, image limit, run time limit (to avoid timeouts), and rate limiting. Users, capabilities and roles would be great also.

A helper function would also be needed to restart the cron until it completes or fails. Obviously it would also need to store the URL of the site to push to or pull from. Custom post types should also be supported.

Maybe this should be a separate add-on plugin? Are there currently sufficient hooks to make that possible?

Problem
The Distributor plugin is missing it's name in the Screen Options area.

Solution
Give the plugin a name in the Screen Options area.

Hi Guys,

Is it possible to create a custom action/filter which allows us to add/edit meta fields of articles to the synchronisation?

The default action now is to synchronize all visible metafields, but not the ones that are invisible (starting with a _)

For example we us _yoast_wpseo_primary_category to create listings on our website and that meta field is by default not synchronized. Which I totally understand, but it would be nice to have a hook so I can add it to the synchronisation.

Hey guys, appreciate the update without the need to compile. I've got it working, but now my featured images sometimes move across and sometimes don't. Regardless of the outcome, Distributor reports back with "There was an issue distributing the post", and there's usually missing custom fields. Thoughts?

Great start, though. Much more reliable than any of the other syndication plugins I've seen and tested, and this is only the beginning!

I spotted a large number of these cases where HTML strings are turned into DOM nodes, either passed straight from a variable, or assembled with strings.

For example in assets/js/src/admin-external-connection.js:

						if (response.data.endpoint_suggestion) {
							endpointResult.innerHTML = ' ' + dt.endpoint_suggestion + ' <a class="suggest">' + response.data.endpoint_suggestion + '</a>';
						} else {
							endpointResult.innerHTML = dt.bad_connection;
						}

These should be using DOM node construction. I can see that in the above example, the bad connection may just be a language string, but in that scenario a text node should be created rather than blindly trusting the value is safe

I installed the plugin on a client site hosted on WP Engine and the plugin's core functionality of creating or managing the ads.txt file isn't working.

An ads.txt file already exists for the website. Loading up the plugin for the first time shows a blank textbox. Entering something in will save the changes on the page, but the ads.txt file won't change.

Deleting the ads.txt file on the server doesn't have any impact.

Hi guys.

I am having trouble in establishing a valid connection with our staging sites.

All of them are behind Basic HTTP Auth, and it looks like at the moment there is no way around it except removing it and using the recommend Application Passwords plugin.

Is this authorization type permanent solution? It could be an issue for any site that is behind Basic HTTP Auth for any reason.

We need to address this scenario.

Title says it all.

Could the chainlink icon in the All Posts admin space link back to the original post, rather than having to go into edit the post to see the source link in the admin notice?

There should be separate tests files for both NetworkSiteConnections.php and InternalConnections/NetworkSiteConnection.php.

For NetworkSiteConnection.php, we will need to test:

• Push
• Pull
• Remote get

I am using Distributor on a complex multisite installation serving landing page builder developed using ACF as the foundation.

We are handling images on sites via Delicious Brains WP Offload S3 plugin and when distributing a page, it copies all fields correctly except the image fields (possibly related to #77). The physical image is copied over to the destination site, with correct S3 URL, but it is not tied to the field, the image field is always empty.

I have distributed a dozen of posts and the image field was newer properly populated.

So far this is the only issue I have stumbled upon after using the plugin for a while in a pretty complex environment. Great job.

This one will be pretty simple.

Sync logging is stored in options/post meta. This will pose problems on high usage websites. We need to document.

Right now we are validating signatures within the API endpoint. This it the wrong filter to be returning a 403. We should be checking signatures on the rest_authentication_errors filter.