Viewing 12 replies - 1 through 12 (of 12 total)
  • crzyhrse

    (@crzyhrse)

    I can confirm this… see this thread for more detail…
    https://wordpress.org/support/topic/media-upload-page?replies=8#post-6824824

    Like your plugin a lot for what it does so nicely… Hoping I can continue to use it…

    Kind regards…

    crzyhrse

    (@crzyhrse)

    I’ve done some experimenting and find that it is when the “Hide on WP-ADMIN” check box is unchecked that this issue occurs… So seemingly the way the scroll to top button is implemented on the Admin page is what is interfering with the media upload page…

    I am continuing to use WPFront Scroll Top, it being in my experience the best of its field, so to speak, but also to say that its use on the admin page has been helpful… So hoping a fix might enable it to work there as well, without interfering with media uploading…

    Kind regards…

    Plugin Author Syam Mohan

    (@syammohanm)

    Hey guys,

    I tested this, but it worked fine for me.

    This plugin allows you to display the scroll top button on wp-admin too. And it excludes ajax requests using the DOING_AJAX constant. If you have a plugin/theme which does ajax but not using the WordPress recommended way (not setting DOING_AJAX const), you will have this issue.

    Use the WP-ADMIN setting to disable the scroll top button on wp-admin. That should fix the conflict.

    Thanks

    Syam

    crzyhrse

    (@crzyhrse)

    Hi Syam,

    Thanks for your response here…

    So then it is a conflict of some sort between this plugin and the EWWW plugin, apparently regarding how to engage the Admin page via AJAX…

    The first post in this thread is from the EWWW plugin author.. The two of you clearly have different takes on this… Here again is the link I posted above that goes to the thread in that support forum where there is some discussion about this issue from that perspective…
    https://wordpress.org/support/topic/media-upload-page?replies=8#post-6824824

    Th code realities behind this are way beyond me… Would you be able to discuss this directly with the EWWW plugin author…?

    The EWWW plugin has become essential for me, and your very great plugin I can continue to use of course on the front end, but it has also been helpful on the backend… More though at this point is simply my curiosity about if there is a solution for this, a way that both plugins can mutually engage the backend/admin area… ?

    Kind regards…

    Thread Starter nosilver4u

    (@nosilver4u)

    Syam, a little more information may be necessary for you to replicate the issue. I hadn’t installed the plugin myself, my only experience had been with crzyhrse’s dev install where I had seen the behavior.

    So, I installed it on my own server, with no other plugins active. I left it active on admin pages, since this is necessary to replicate the issue. When uploading images to the standard Media Library, the AJAX response gets intercepted by WPfront Scroll Top, and produces this output:

    44156 <div id="wpfront-scroll-top-container"><img src="http://dev.shanebishop.net/wordpress/wp-content/plugins/wpfront-scroll-top/images/icons/1.png" alt="" /></div> <script type="text/javascript">if(typeof wpfront_scroll_top == "function") wpfront_scroll_top({"scroll_offset":100,"button_width":0,"button_height":0,"button_opacity":0.8,"button_fade_duration":200,"scroll_duration":400,"location":1,"marginX":20,"marginY":20,"hide_iframe":false,"auto_hide":false,"auto_hide_after":2});</script>

    The result is that the upload still completes, but WordPress does not know this, and the page still displays “Crunching….” and instead of a thumbnail, it displays the post ID (44156), giving the appearance of a broken upload.

    It seems async-upload.php may define DOING_AJAX a little later than some of the other AJAX calls, so perhaps you simply need to defer your check a little bit.

    Plugin Author Syam Mohan

    (@syammohanm)

    Can either of you give me a step by step replication procedures?

    Thread Starter nosilver4u

    (@nosilver4u)

    All I did was install the plugin, ensure the admin-side feature was still enabled, and then went to Media->Add New and uploaded an image.

    crzyhrse

    (@crzyhrse)

    Hi Syam,

    I notice you updated this just yesterday, but the issue continues… It occurs on production sites but I can also affirm that it occurs on a clean WP install updated to 4.2 and with just this plugin, no mods and no content…

    As nosilver4u suggests, ensure the admin-side feature is enabled and then go to Media->Add New and upload an image… You should see, also as described, that the upload completes but WordPress doesn’t know it, leaving the upload page continuing to display “Crunching….” and instead of a thumbnail, it displays the post ID, which gives the appearance of a broken upload…

    And of course the added detail that nosilver4u offers above, regarding the AJAX response getting intercepted by WPfront Scroll Top…

    Kind regards…

    Plugin Author Syam Mohan

    (@syammohanm)

    Thanks guys. Now I’m able to reproduce this. The reason I was not able to reproduce was, it only happens if you use the “Add New” in the menu. If you upload using the “Add New” available next to the “Media Library” title within the Library page, it works fine and I was using this option to upload. I’ll soon have a fix.

    Thanks again,
    Syam

    Plugin Author Syam Mohan

    (@syammohanm)

    @crzyhrse, can you contact me, I’ll send you a version to test.

    https://wpfront.com/contact/

    Thanks

    Syam

    I’ve sent you a message with my email…

    What you sent me seems to have fixed it… Thanks for being on top of this… If I could give you a sixth star I would… 🙂 As it is you can mark this thread resolved… Kind regards…

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘uploads broken’ is closed to new replies.