msenate

Hmm, I’ve been updating the plugin separately, you can give it a try here to see if it works for you! https://github.com/msenateatplos/multi-twitter-widget

Cheers

// Matt

I used a slightly different fix, fails silently at the moment, but could easily log an error or display the previous error message. Maintaining improved version of this plugin here: https://github.com/msenateatplos/multi-twitter-widget

user step:

// Create an XML object from curl'ed content
                        if ( ! $content === false )
                        {
                                $xml = new SimpleXMLElement($content);
                                $feeds[] = $xml;

                                // Let's save our data into uploads/cache/
                                $fp = fopen($cFile, 'w');
                                if ( ! $fp )
                                {
                                        $output .= '<li style="color: red;">Permission to write cache dir to <em>'.$cFile.'</em> not granted</li>';
                                }
                                else
                                {
                                        fwrite($fp, $content);
                                }
                                fclose($fp);
                        }
                        else
                        {
                                // Content couldn't be retrieved... failing silently for now
                        }

search step:

// Create an XML object from curl'ed content
                        $xml = new SimpleXMLElement($content);
                        $feeds[] = $xml;

                        if ( ! $content === false )
                        {
                                // Let's save our data into uploads/cache/twitter/
                                $fp = fopen($cFile, 'w');
                                if ( ! $fp )
                                {
                                         $output .= '<li style="color: red;">Permission to write cache dir to <em>'.$cFile.'</em> not granted</li>';
                                }
                                else
                                {
                                        fwrite($fp, $content);
                                }
                                fclose($fp);
                        }
                        else
                        {
                                // Content couldn't be retrieved... failing silently for now
                        }

You’ll have to follow the instructions time.ly provides for the calendar available on their site, I had to replace the themes for it to work properly.

Indeed, post if you find something viable.

Okay, I got this fixed. You need to upgrade to the version available at https://time.ly/

They have not pushed the patch to their WordPress plugin repo (or at least it has not made it to be live).

You may have implemented some ai1ec themes which will need updates as well (plus any custom templating or styling).

I don’t have all the details, but this seems like a very nasty, disingenuous move on the part of time.ly. I’m skeptical of the motivation of forcing users to download a new copy from their website (which is misleadingly labelled “premium”).

I’m in an active search for a replacement for all-in-one-event-calendar. Please link me if you know of one.

Needed to upgrade to WordPress 3.5, saw the plugin was using deprecated functions, so reformatted it to use the object-oriented plugin format (permits having multiple widgets now), and various other little tweaks.

For that and any future changes (pending a note from the plugin creator), see this: https://github.com/msenateatplos/multi-twitter-widget

I had the same problem, the “Create profile” link is misleading terminology since it really means “Create Guest Author profile”.

I’ve applied the filter to disable now as well, especially important on a multisite install. Will note if there is any remaining trouble.

I’d like to leave this issue as unresolved since there is limited compatibility of guest authors with multisite. We can resolve once there is a work-around or support.

Sat on this for a bit… started investigating Custom Post Types with Sitewide Tags. Apparently there is some support for CPTs with the filter described here:

https://www.ads-software.com/support/topic/plugin-wordpress-mu-sitewide-tags-pages-grabbing-custom-post-type-posts?replies=9#post-2461367

I implemented and refreshed Sitewide Tags, but limited success as of yet… have resource limitations on develop environment so need to debug…

Aha, okay well if there’s a place I can submit a ticket with more details and follow on the dev thread, let me know.

As for switch_to_blog(), I agree with the hesitation…

Right now it seems that if there is not some more elegant global-level solution for multisite than a custom hack, I’ll have to choose not to use the guest author feature. Despite not hearing similar requests as of yet, the Sitewide Tags configuration of a Multisite install alongside an implementation of Co-authors Plus is fairly standard. I imagine there is interest, but it has yet to become visible.

I’m thinking about the wp-signups table as an example, but agree much complexity is avoided with the use of custom post types…

Just had a thought, maybe this can be used: https://codex.www.ads-software.com/Function_Reference/switch_to_blog

Wondering if it’s overkill…

Calling coauthors_posts_links(); on the primary blog does not retrieve the guest author, presumably because that guest author is only really stored with respect to the particular blog for which it is a custom post.

Correct. The best approach would probably be to save the guest author data to a global table, and then directly query the global table. You could hook into Co-Authors Plus and add a syncing action that creates or updates the profile data in the global table on save.

Fair, but I would like to know if there is any plan to incorporate this into future Co-authors Plus development. Your suggestion, akin to a Sitewide Tags type of solution, would be non-trivial, and I’d be wary of taking it on in earnest for a production environment unless there were other folks who planned to implement and support it. Still weighing options and work-arounds…

Further, I had some odd behavior for a while that must have corrected itself (perhaps it was a migration triggered by calling some specific function?) where guest authors’ posts_link did not display, basically since get_author_posts_url() was coming back null

Odd. Let me know if it comes up again.

I’ll test explicitly as I move from dev to staging environments and see if it happens again.

Thanks.

Though I agree this thread should not be resolved, and the hack above is not the desired functionality…

I Turned those changes into a simplified patch I’m employing:

Index: jetpack/jetpack.php
===================================================================
--- jetpack/jetpack.php (revision 3732)
+++ jetpack/jetpack.php (working copy)
@@ -272,7 +272,7 @@
         * Is Jetpack active?
         */
        function is_active() {
-               return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );
+               return true; // return (bool) Jetpack_Data::get_access_token( JETPACK_MASTER_USER );
        }

        /**
@@ -2211,7 +2211,7 @@
                $role = $this->translate_current_user_to_role();
                $is_connected = Jetpack::is_active();
                $user_token = Jetpack_Data::get_access_token($current_user->ID);
-               $is_user_connected = $user_token && !is_wp_error($user_token);
+               $is_user_connected = true; // $user_token && !is_wp_error($user_token);
                $is_master_user = $current_user->ID == Jetpack::get_option( 'master_user' );
                $module = false;
        ?>

To apply the patch use, save the snippet above as jetpack_localhost.diff then issue this command:

patch -p0 -i ~/jetpack_localhost.diff

I simply added an is_network_admin() check to this function so that settings link does not display on the network admin plugins page:

/** Add links on the plugin page (short description) **/
add_filter( 'plugin_row_meta', 'yd_wpmuso_links' , 10, 2 );
function yd_wpmuso_links( $links, $file ) {
        $base = plugin_basename(__FILE__);
        if ( $file == $base && ! is_network_admin() ) {
                $links[] = '<a href="options-general.php?page=yd-wpmu-sitewide-options%2F' . basename( __FILE__ ) . '">' . __('Settings') . '</a>';
                $links[] = '<a href="https://www.yann.com/en/wp-plugins/yd-wpmu-sitewide-options">' . __('Support') . '</a>';
        }
        return $links;
}

Having the same issue as of today “have data = false”. I made the plugin’s API request manually in my browser and it worked fine. Further, this plugin has been running for a while and only bugged out today. It’s back and working now, but this seems to imply the necessity of a deeper caching component.

+1, indeed. Considering making the switch and this is the only thing holding me up.