ellatrix / wp-front-end-editor

Front-end Editor for WordPress
https://wordpress.org/plugins/wp-front-end-editor/
340 stars 87 forks source link

I can activate but don't publish or edit posts #173

Closed ggsalas closed 9 years ago

ggsalas commented 9 years ago

Hi Avryl, Today I have update the plugin and also test downloading the zip from github and i can't use it.

The error is that the plugin don't do anything. I made a video: http://screencast-o-matic.com/watch/c2QDYCnWZS

You can try this error on my test site, but if you need admin password, I send it by email: URL: http://ggsalas.staging.wpengine.com/wp-login.php User: test Pass: wpuf*01

The only plugin I have active is yours: http://i.imgur.com/RpFDCdQ.png

Thanks and best regards

ellatrix commented 9 years ago

Hi! I can't see fee.js... Not sure why it's not included.

ellatrix commented 9 years ago

Any PHP errors?

ggsalas commented 9 years ago

I can't see php errors. This are the files on my instalation: http://i.imgur.com/mZEV3j8.png

bryanwillis commented 9 years ago

The issue is specific to wpengine and/or nginx @ggsalas.

I ran into a similar issue a few months back with wordpress modal login from codecanyon that lets you change the admin_url() to anything you want. After spending way too much time trying to fix the modal login plugin since it's support was virtually non-existant, I was able to figure out a few things...

First wpengine uses a hybrid of nginx and apache.

I've found that sites using nginx commonly run into issues with plugins or themes requiring absolute paths to /wp-admin/. wp-admin directory, admin_url(), and admin ajax can be tricky sometimes where the relative $scheme can cause problems with ajax url loading static assets from the wp-admin folder.

On top of that, wpengine does some of its own rewrite tweaking found in it's mu-plugin:

$cdn_admin_replacement_regexes[] = "#${re_src_st}${re_path0}/wp-(?:admin|includes)/${re_path0}\\.(?:css|js|png|gif|jpe?g)${re_qstr}${re_src_end}#i";
$cdn_admin_replacement_regexes[] = "#${re_src_st}${re_path0}/wp-admin/load-s(?:cript|tyle)s\\.php${re_qstr}${re_src_end}#i";

They do this because they rewrite the static admin files to its cdn and then caches the files. I've already opened a ticket with them that they need to come up with a better way to do this because it causes issues with several plugins and causes errors occasionaly.

After briefly checking the code of wp-front-end-editor, I'm inclined to think it's not the caching issue in this particular situation since your demo shows you on a staging server.

My best guess is that this issue is more due to the wpengines nginx server than the rewrites themselves. Wpengine also just did a major update to their servers about the same time this issue occured so it could have to do with that. Perhaps wp-admin is being blocked or ssl issues in the conf.

Anyway, here are some guesses on a fix...

Include the relative scheme in admin ajax: admin_url( 'admin-ajax.php', 'relative' );

After looking at the chrome dev tools I got this error:

(index):1 Failed to load resource: the server responded with a status of 404 (Not Found) http://example.com/some-post/images/wpspin_light-2x.gif The content on the server and the content in the editor is different. This may be due to errors. fee.min.js:1

'wpspin_light-2x.gif' is loaded with a relative path, which it expects comes from the wp-admin folder directly. The relative issues with this issue might be causing similar problems with other ajax scripts.

We could try the output buffer to fix this although it could get messy:

if (!is_admin()) {      
        function wp_admin_asset_fix_buffer_callback($buffer) {
           $wrong_spinner_url = trailingslashit( (is_ssl() ? 'https://' : 'http://') . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'] ). 'images/wpspin_light-2x.gif';
           $right_spinner_url = admin_url('images/wpspin_light-2x.gif');
            $buffer = preg_replace($wrong_spinner_url, $right_spinner_url, $buffer);
            return $buffer;
        }
        function wp_admin_asset_fix_buffer_start() {
            ob_start("wp_admin_asset_fix_buffer_callback");
        }
        function wp_admin_asset_fix_buffer_end() {
            ob_flush();
        }
        add_action('wp_head', 'wp_admin_asset_fix_buffer_start');
        add_action('wp_footer', 'wp_admin_asset_fix_buffer_end', 999);
}

It would be good to see if anyone else had a nginx config that isn't hosted on wordpress. This would at least tell us if it's wpengine only or nginx in general.

solhuebner commented 9 years ago

If you need a Dev server to play around I can get you full SSH / admin access to that one. 4 Cores / 2 GB RAM / 40 GB SSD with Ubuntu 14.04.01 / WordPress 4 with Nginx. Unfortunately I do not have time to check on my own at the moment...

bryanwillis commented 9 years ago

Hey that would be awesome rugwarrior. I was thinking about testing a vagrant virtual box or something like that but just got a new comp and wasn't looking forward to installing a bunch of stuff that I ususally don't use. I'm probably not the best person to do this, and I could be totally wrong on this, but I'm pretty sure what I mentioned above has to do with it. I'd definitely be willing to try and figure it out if you got a server. I'm also in contact with wp-engine and they wanted to recreate this issue so it might be good for them to have even!

solhuebner commented 9 years ago

Hi @bryanwillis please check your mails :)

ggsalas commented 9 years ago

Hi @bryanwillis, I have send your response to wpengine and get an answer. I hope this andwer helps to @avryl to resolve this problem, because I think that must be many other hostings where the plugin don't work:

Hi Gabriel,

Thank you for clarifying. Unfortunately, after reading that link you provided, I would have no idea on how to correct this so that the plugin works. Our server set up is indeed run on nginx and apache.

The person responding to that thread is indeed correct that the problem isn't caching though because our staging sites do not use any type of caching at all.

Since we are not the developers of the plugin, we are not able to correct the plugin in order to work on our platform. I would recommend speaking to the developer and trying to see if they have a way to get this to work on our platform.

I am sorry that I am not able to provide any concrete answers on how to get this plugin to work on out servers. Please let me know if you have any questions.

Mike Price | Technical Specialist WPEngine - Finely Tuned WordPress

Best regards, Gabriel

ggsalas commented 9 years ago

Hi @bryanwillis you could find a solution to the wpengine servers? I think this plugin must resolve this because is a wordpress specific hosting. I have disappointed with the wpengine answer.

Thanks and best regards, Gabriel

bryanwillis commented 9 years ago

Sorry for late response here guys.

Thanks @RugWarrior for the server but thankfully I didn't have to dive too deep into figuring this out. After seeing your comment @avryl it dawned on me what was causing the problem.

@ggsalas I've found that to be the typical answer wpengine will give you! When they don't know whats wrong with their wpengine plugin or server they'll say it's not their problem and the plugin author has to figure it out. Kinda sucks if you ask me that they don't do more to help fix these issues considering the problem is caused on their end.

Anyway, here's a side by side of the plugin scripts that are being rendered on my wpengine acount and bluehost account:

screen shot 2014-10-24 at 12 07 32 am

Both fee.js and autosave.js arent loading on wpengine because of their script dependencies not regestering.

Anyway, I remembered doing a google search to see if wpengine was affected by the "heartbleed" virus back in april, but ended up on an article on how wpengine disables the "heartbeat" script because it can slow down a site when making several calls with admin-ajax.php to the databse.

I did a grep search of my wp install and found the wpengine heartbeat class:

mu-plugins/wpengine-common/class.heartbeatthrottle.php
<?php
/**
 * A class for throttling back the heartbeat of a WordPress page. This class controls
 * the heartbeat rate and even disables the heartbeat for all pages except post editing
 * pages. 
 */
class WPE_Heartbeat_Throttle {
    /**
     * Register the actions/hooks that make this throttle work.
     */
    public function register() {
        add_action( 'init', array( $this, 'check_heartbeat_allowed' ), 1 );
    }
    /**
     * Check that heartbeat is allowed for this page and deregeister it if not. 
     */
    public function check_heartbeat_allowed() {
        global $pagenow;
        /**
         * Filter the pages where heartbeat.js is allowed to load.
         *
         * @since 2.1.13
         *
         * @param array $heartbeat_allowed_pages Array of pages where the heartbeat.js file is allowed to be loaded.
         */
        $heartbeat_allowed_pages = apply_filters( 'wpe_heartbeat_allowed_pages', array( 'edit.php', 'post.php', 'post-new.php' ) );
        if ( ! in_array( $pagenow, $heartbeat_allowed_pages ) ) {
            wp_deregister_script( 'heartbeat' );
        }
    }
}

Luckily it looks like there is a filter so all we need to do to fix the front end editor plugin on wpengine is this:

<?php 
if (class_exists('WPE_Heartbeat_Throttle')) {
  function fix_fee_plugin_missing_hearbeat_scripts( $wpe_heartbeat_allowed_pages ) {
    $wpe_heartbeat_allowed_pages = array(
        'post-new.php',
        'index.php',
        'admin.php',
        'edit.php',
        'post.php',
    );
    return $wpe_heartbeat_allowed_pages;
   }
add_filter( 'wpe_heartbeat_allowed_pages', 'fix_fee_plugin_missing_hearbeat_scripts' );
}
solhuebner commented 9 years ago

You are welcome :-) And great finding!

ggsalas commented 9 years ago

Hi @bryanwillis you are a genius!!!

I have pasted your code on functions.php and the plugins works well.

Tank you and best regards

ellatrix commented 9 years ago

Thanks for helping each other out. :)