Copy/Paste broken with Flux 5.3 and TYPO3 4.7.10 about flux HOT 26 CLOSED

Sounds like issue #16. I have explained a small workaround for this.
Take a look at this issue, maybe it helps.

kind regards
Heiko

from flux.

That's what I thought, too. However, the observed behavior is not that the element is inserted in the wrong place, but rather that it is not even pasted at all.

from flux.

ok ... sounds strange
This weekend I will take a deeper look using Typo3 V4.7.x and Flux, maybe I run into same troubles.
I will tell you my results

kind regards

from flux.

Ok, I got the same problem

from flux.

Hi Heiko,

Can you investigate which of the record's values are set incorrectly - or if the problem is that no copying/moving takes place at all?

from flux.

"copy" and "paster after" will lost pid and sorting.
Every copy will be pasted at pid 0 and sorting 0.

This issue is very close to mine, so at first I will check this one, and check mine later.
I noticed that the pasting process will complete be rewritten. Maybe my problem will be solved too, if we fix this one.

kind regards
Heiko

from flux.

Thanks again Heiko. The zero'ed values point to the record not being postprocessed correctly. This should happen in Flux's ConfigurationProvider as needed by the action being taken (move/paste copy/reference). If you need my eyes on it just let me know - until then, I'm holding off investigation and hoping you can pinpoint the source, as it could be affected by some local factors like workspaces, translated content etc.

from flux.

Problem is this line:

within this screenshot you see that every variable ($pid, $subCommand, $relativeUid, $uid, $possibleArea, $possibleColPos) will be set to an empty string "".

Now i have to check how the "pasteCommand" will be delivered in Typo3 V6. It seems that there are differences.

kind regards

from flux.

Typo3 6.0.x runs into same problem. Syntax of "pasteCommand" is the same:
like: tt_content|-13 = [TABLE] [PIPE] (minus)[REFERENCE-UID]

I think there is some more logic needed espacialy for gridelements, fluidcontent / flux and templavoila

I'm verry sorry, but I have to make a break for this weekend.
I hope I can spent more time tomorrow or next weekend.

Kind regards
Heiko

from flux.

Hi Heiko,

I think there is some more logic needed espacialy for gridelements, fluidcontent / flux and templavoila

I am afraid you're absolutely correct about that. But since TV and GE should have their own processing logic, maybe the better solution here is to somehow identify if the command is actually one used by Flux and only trigger if so?

I'll investigate this - and take the opportunity to clean up the methods related to parent-element detection (unifying the services made it clear some are redundant or too complex). I will of course let you know what I find out.

Cheers,
Claus

from flux.

Thanks for this info :)

Please be aware: gridelements or templavoila-fces can be nested within a flux container.
I'm currently not sure how the commands will be build in this case.

At this time I'm not sure if templavoila is compatible to gridelements.
In worst case everything can be nested within everything :D (multiple times and backwards and ........)

Kind regards
Heiko

from flux.

Please be aware: gridelements or templavoila-fces can be nested within a flux container.

Absolutely - if the solution is to check the parent, it should only be the immediate parent :)

I also don't know about TV + GE compat, but they should be supported individually at least. And if a solution can be made which skips commands for the two, it would be completely up to each of them to ensure compatibility.

from flux.

Thank you both so far for investigating! I agree, the primary goal should be to ensure Flux working properly with the core, independently from TV and gridelements. And if you can manage to find a solution which enables other extensions to provide inter-operability, that would be even greater.

from flux.

hi,
I noticed some similar behavior on the localize-command in TYPO3 6.1beta2, i.e. when testing fluidcontent_bootstrap FCEs. Nested CEs inside i.e. an Accordion tab dont get translated, the corresponding translated FCE is empty.

This is ofc bad and was working in previous TYPO3 4.6/4.7 compatible versions of FLUX. As long as this isnt working, fluidcontent isnt usable for production 🈂️

from flux.

ok, I got the error - in Tx_Flux_Provider_Configuration_ContentObjectConfigurationProvider, line 178 you get the $oldRecord from database, but without the field "pid". Later you have a condition which uses the pid-field and inside that condition you localize child records. But that condition is ofc never matched, because you dont retrieve the pid field. Fix for that: replace SELECT-Statement with:

$oldRecord = $GLOBALS['TYPO3_DB']->exec_SELECTgetSingleRow('uid, pid, ' . $languageFieldName, $this->tableName, "uid = '" . $oldUid . "'");

from flux.

PS: Oh, I see this issue is already solved in master branch :), but not in the TER version...

from flux.

just for the record: apparently, fgerards problem is different from this one, so the copy/paste issue is still open.

from flux.

hi,

today I tried the FLUX 6.0.0 TER Version with TYPO3 6.1.0.
Sadly, since i think TYPO3 4.6 the copy/paste problem still exists. So Flux and all extensions depending on it are not usable in production, because the users cannot copy/paste content elements in the backend. During pasting the elements land in the ID=0 master knot and not on the page. I remember we once solved this problem in the TCEMain-Hook, why does it keep coming back into Flux ?

from flux.

I just finished the migration of a big site from fed to current TER major versions (http://fedext.net/news/new-major-versions.html) of fluidpages, fluidcontent and VHS. I also upgraded Flux to current 6.0 version and ran the update script in fluidcontent.

Unfortunately, the copy/pase error still persists: content elements are still pasted to pid=0. The behavior is being observed independently from gridelements. Maybe the colPos of the concerned content elements is relevant? It shows "-42".

It is extremely important for me to fix this copy/paste issue. Is there any war I can help you?

from flux.

Hi @moger-xx,

I'm assuming it happens somewhere between /typo3conf/ext/flux/Classes/Provider/Configuration/ContentObjectConfigurationProvider.php:167 and /typo3conf/ext/flux/Classes/Provider/Configuration/ContentObjectConfigurationProvider.php:311 but I'm not sure which exact one is being triggered in your case - it all depends on exactly how you perform the "paste" command (through icon after element, in top of column, in another column, on another page, through clickmenu or...).

If you can pinpoint which operation is failing I'm sure I can fix it quickly.

Cheers,
Claus

from flux.

Hi Claus,

I use TYPO3 4.7.10. When I copy a tt_content element (UID 50356) after another (UID 50353) via the PAGE module by clicking on the icons in their context menus, i have the following variable situation in

/typo3conf/ext/flux/Classes/Provider/Configuration/ContentObjectConfigurationProvider.php:275

$command = copy
$id 50356
$row Array [107 ] with uid = 50356 as first element
$relativeTo -50353

When I proceed, I have the following variables:
line 280: $pasteCommand tt_content|-50353
line 281: $parameters Array [2]
0 tt_content
1 -50353
line 282: $pid is empty

So apparently the pid is not being set correctly because the information is unavailable from $parameters.

When commenting out $record['pid'] in line 302, the paste operation works, but elements are inserted at top of the page. When also commenting out $record['sorting'], it works fine.

So I can confirm heiko's findings for Flux 6.0.

from flux.

Hi Moritz,

Please see if the PR linked here helps the situation - your information helped a lot so I knew where to look for the incorrect values and how to fetch them in an alternative way. The PR may not be the perfect solution but it should work (also on 6.x). The issue was indeed that the $pasteCommand does NOT contain the expected values when NOT using the custom Flux paste icons - which of course are only available on 6.0. The same situation applied also when pasting through the clickmenu (and very likely also when pasting in the top of a root column but this, I did not test, as the current solution already nullifies values that aren't recognised), on both 4.x and 6.x branches as far as I can deduce.

from flux.

Hi Claus,

the mentioned PR solves the Problem in TYPO3 4.7.10. I tested copying/cutting and pasting via Clickmenu in page module, also across pages, and also from page view to list view, pasting on top of a column. It also works with nested content elements (FCES). Thank you for looking into this!

from flux.

Thanks for the feedback and testing, Moritz! Closing this one - finally.

from flux.

Just encountered this problem again with TYPO3 6.1.5 and Flux 6.0.2.
When I copy/paste any content element via the list module, the pasted content element gets the pid '0'.
Flux is the only installed extension, that uses Xclasses.

from flux.

Recently mentioned bug is fixed. We are aware of an issue with localisation of child content - but this issue can be closed.

Cheers,
Claus

from flux.