Coping from article source does not work anymore - depends on size #214

konus1 opened this Issue May 17, 2016 · 11 comments


None yet

4 participants

konus1 commented May 17, 2016

Version Information

  • WordPress: 4.5.2
  • MultilingualPress: 2.4.3

Steps to Reproduce

  1. create a article more than 3901 characters long.
  2. Use the button "quellbeitrag kopieren" (copy source article) in the translation area in dashboard of exisiting article
  3. translation area on dashboard turns grey and nothing is copied

Full Description

Hello, after the new Version 2.4 on most of my existing (published) articles I am not able to copy the source article text to the translation area any more. There is no error log in the browser console.

I think it is a size issue of the source text. If the source article contain more the 3901 characters (including all spaces and cr) the copy command is not successful any more.

2016-05-17 16-24-42_beitrag bearbeiten beta-dresden fur kinder wordpress

@konus1 konus1 changed the title from Coping from article source does not work anymore - depens on size to Coping from article source does not work anymore - depends on size May 17, 2016
tfrommen commented May 17, 2016 edited

I cannot reproduce this.

I created a new post, pasted 3901 1s into its content, saved the post, and copying the content via the Copy source post button works without a problem. Even twice the amount does.

I tested this both with SCRIPT_DEBUG turned on and off, just beacause this led to JavaScript misbehavior some days ago.

Can you provide more information on this?
Can you disable all other plugins, and use a default theme?
Anything else?

konus1 commented May 17, 2016

I can reproduce it even with all other plugins turned off and with Twenty Sixteen default theme. After entering more than 3880 .... 3949 characters (depending of title length), with or without saving - the copy source post button does not work any more. Strange.

I am on PHP Version 7.0.6 at the moment and use Firefox 46.0.1 or Chrome Version 50.0.2661.102 m
I switched from http to https at the same time of the update.

I tested it with wp_debug true and false, but did not find a difference.

I have no other idea what could help to solve the puzzle.

konus1 commented May 26, 2016 edited

My problem still exists. How can I help to find the bug?

tfrommen commented Jun 9, 2016

Sorry, we discussed this (more than once), but cannot reproduce this.

  • Default theme, and no other plugins active - but it's still wrong.
  • Multiple browsers - in none it's right.
  • Switched from http to https, but everything (besides the Copy source post functionality) is working totally fine...
  • Debug and no-debug - no difference.

Is this correct so far?

Can you please summarize (again) what you do exactly?

  • WordPress 4.5.2
  • MultilingualPress 2.4.3
  • Create a post (does the post type matter?).
  • Click the Copy stouce post button.
  • Meta box fades out...
  • ...and that's it. Right?

Do you have any MU plugins installed?

Copying the data is done through AJAX. What do your browser dev tools tell you about the request and response?

How did you come up with the size idea in the first place?
Did you try on a post with a lot of content, it didn't work, and then you removed some of the content, which made it work again...? Or is it just that with most longer posts this isn't working (anymore), while short posts always seem to work...?

Chrico commented Jun 9, 2016 edited


it seems this issue is related to the Apache configuration LimitRequestLine [1] which limits the size of GET-parameters.

CopyPost uses this.model.fetch() [2], which does a GET-Request.


Since we're sending data for validation in CopyPost to the backend, it would be better to use which does a POST-Request.

Note: If you're using save instead of fetch, than please also check the listenTo [3].



@tfrommen tfrommen added javascript and removed cannot reproduce labels Jun 9, 2016
konus1 commented Jun 9, 2016 edited

@Chrico I tested your solution and it looks like you solved the problem. Many thanks!
@tfrommen Please inform me, if you still need more information.

Yeah, I think this can be closed now!


No, I think we should fix that in the code. So please leave it open for now.

tfrommen commented Jun 9, 2016

Hi @konus1,

we may have (found and) fixed this, finally. :)

Please have a look at the new branch. Does this (still) work for you?

Kind regards,

@tfrommen tfrommen added a commit that referenced this issue Jun 9, 2016
@tfrommen tfrommen Adapt tests. #214 704e3d8
@tfrommen tfrommen added a commit that referenced this issue Jun 9, 2016
@tfrommen tfrommen Fix test. #214 b7c7911
tfrommen commented Jun 14, 2016 edited

Hi @konus1,

did you have a chance to check out the according branch? Does this work for you?

Kind regards,

@tfrommen tfrommen added this to the v2.4.4 milestone Jun 14, 2016
@tfrommen tfrommen self-assigned this Jun 14, 2016
konus1 commented Jun 14, 2016

Yes I tested it and can confirm, it is also working with the linked branch

@tfrommen tfrommen modified the milestone: v2.4.5, v2.4.4 Jun 27, 2016

Fixed in 214b8ef.

@tfrommen tfrommen closed this Jun 27, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment