copy/paste broken in gridelements after install flux about flux HOT 29 CLOSED

Hi Claus, just only to tell you my current state:
It seems that this problem results in:

Tx_Flux_Provider_Configuration_ContentObjectConfigurationProvider
adjustColumnPositionBasedOnCommandUrl($id)

Line 301: if (strpos($relativeTo, 'x') !== FALSE) {

Pasting elements from the gridelements-comand seems to always provide an "(int)x(int)" command.
There is just only one difference ... if it is nested the first value is negative ... in root cols positive

For testing i have made the following changes:

        if (strpos($relativeTo, 'x') !== FALSE) {

            // Triggers when an URL-based copy/paste or cut/paste action is performed and
            // the target is a column directly in the page (i.e. not nested content column).
            // The implication: content-to-parent relationship should be nullified
            $row = array();
            $row['tx_flux_parent'] = $row['tx_flux_column'] = NULL;

            // heiko.hardt changed from: #####################################################
            // $row['colPos'] = array_pop(explode('x', $relativeTo));
            // to:
            $relativeTo = explode('x', $relativeTo);
            if ( (int)$relativeTo[0] >= 0 )
                $row['colPos'] = (int)$relativeTo[1];
            // change end ####################################################################

            $GLOBALS['TYPO3_DB']->exec_UPDATEquery('tt_content', "uid = '" . $id . "'", $row);

        }

I will test it tomorrow in depth

kind regards

from flux.

Hi Claus, this image should show the colpos handling using gridelements and backendlayouts in typo3 v4.7.7

At this time it works for me.
Would be nice if you can take a look at it.

Thanks

from flux.

Hi Heiko,

Thanks for your investigation! By looking at your patch and the graph below I can see that it should solve the issue you are experiencing. However, it may not be wise to override the $relativeTo parameter (if I recall correctly it's passed by reference and is used later after hook processing). Changing it to an array could cause problems, if nothing else then in other hook processors.

Have you tested possible impact on Flux content container elements? Force-setting colPos should have a negative impact on nested content elements in Flux content containers (they use colPos -42); we may need an additional check for the type of the parent record, only setting colPos this way if parent is in fact a grid element.

Excellent work on illustrating this - makes it totally clear what goes on, very much appreciated!

Cheers,
Claus

from flux.

Hi Claus, thanks for your answer. I will check it tomorrow.
You have done a great job. Thanks for this tools ^^

Kind regards

from flux.

Most likely this is the same bug which is causing the problem when you click the 'Copy Default Content Elements' button after creating a page_language_overlay record. It also happens when GridElements is not being used (on a TYPO3 6.0 install that is).

from flux.

Hi Claus, I have made a small test in Typo3 V4.7.7

To check the function i have set a break point at line 297, but this line wouldn't be entered.
No matter what i have tried to do, the function would be entered and returned at line 295.
Is it possible, that is only needed in Typo3 v6?

kind regards
heiko

from flux.

Hi Heiko,

To check the function i have set a break point at line 297, but this line wouldn't be entered.
No matter what i have tried to do, the function would be entered and returned at line 295.
Is it possible, that is only needed in Typo3 v6?

It may be that only 6.0 is using GET - if that's so, you could use Tx_Flux_Utility_Version to check if we're on 4.x and then look for the command being executed by inspecting POST (if this is where the command is located).

I'm fairly sure the command is given as a request parameter also on 4.7 - it's just a question of where…

Cheers,
Claus

from flux.

Hi Claus, thanks for your answer.

If I'm right flux (flexform.content) elements will always use colPos "-42".
Nesting will be handled within the fields "tx_flux_column, tx_flux_parent, tx_flux_children".
The technique using colPos as syntax "(-) int x int" currently seems only used by gridelements and maybe templavoila.
I will check this in Typo3 V6 and templavoila. This function feels like a workaround for gridelements/templavoila for me.

kind regards
heiko

from flux.

Hi Heiko,

If I'm right flux (flexform.content) elements will always use colPos "-42".

You're right.
Nesting will be handled within the fields "tx_flux_column, tx_flux_parent, tx_flux_children".

Correct.
The technique using colPos as syntax "(-) int x int" currently seems only used by gridelements and maybe templavoila.

It should also be in use on 6.0 when dropping elements in the top of Flux columns - but this is all from memory so I could be wrong about that. I am working on stabilizing Flux even more so I don't have time tonight to investigate that further.
I will check this in Typo3 V6 and templavoila. This function feels like a workaround for gridelements/templavoila for me.

If I am right about it being used on 6.0 it's more than a workaround - but if it is, we're in luck: the syntax appears to match that used by Gridelements on 4.x branches so we should be able to reach compatibility. Especially since Gridelements is the only D&D solution on 4.x and without it, it's rather irritating to work with FCEs.

Cheers,
Claus

from flux.

Hi Claus,

thanks for your quick answers,
I will check it at 6.0 tomorrow. I think you're right about the d&d behavior.
Tomorrow I will tell you details about it.

Many thanks for your time.

kind regards
heiko

from flux.

Hi Heiko,

thanks for your quick answers,

Same to you!
I will check it at 6.0 tomorrow. I think you're right about the d&d behavior.
Tomorrow I will tell you details about it.

Thanks, it's great to have additional eyes on this.
Many thanks for your time.

again - you too :)

/C

from flux.

Hi Claus,
I'm not able to get flux work with Typo3 V.6 :D. Not sure why ... I have changed the the preProcess using namespaces (so no exeption would be thrown), and I have tested it with latest master of Typo3.
Really strange... No flexform would be shown, and flexform content wouldn't be rendered.
I will take a deeper look at it tomorrow.

kind regards

from flux.

Hi Claus,

sorry for the delay. Now I have tested the workaround with typo3 v.6.0.0 without using gridelements and templavoila.
Whatever i try (new, copy, paste after, move) ... the $commandUrl is always empty.

Maybe you can take a look at it too.

kind regards

from flux.

Hi Heiko,

Any updates on this one? Is it perhaps related to this issue on 6.0 and does your install approach and setup differ from the one I describe in the bottom-most reply?

Cheers,
Claus

from flux.

Hi Claus, i know some of this troubles, and will answer them later, when im back home.
My workaround still works around ^^

Kind regards
Heiko

from flux.

Hi Heiko,

Radar ping ;)

Cheers,
Claus

from flux.

Hi Claus :)

sorry I'm currently not sure: are there open questions/tasks for me?
I was realy busy last weeks / month

kind regards
Heiko

from flux.

ah, ok .... reading helps :D

My last tests shows, that commandUrl was always empty, and i asked if you can take a look at it too.
I used my workaround (2nd answer) since 3 month and it still works :]
But that was a typo3 4.7.x project.

Kind regards
Heiko

from flux.

Hi Heiko,

Nice to see you back. Fully understand about being busy, can't be avoided :)

I was wondering about the $commandUrl being empty when using TemplaVoila on 6.0 - is this still the case? I am specifically thinking about this commit: ca02ece which should fix an issue with the returnUrl which would be likely to have an effect on TemplaVoila installs.

If you can confirm that on 6.0 + TV the git masters work as expected, then your proposed patch would be fine to add but should be enclosed by a check for the TYPO3 version (using Tx_Flux_Utility_Version for ease) and should default to the existing behaviour if version is not 4.x. If it is also necessary to make some additional adjustments for 6.0 + TV it would be ideal to include them in the same patch.

Would you like to / have time to make a PR with that change? If you don't just say the word, we have a team for that sort of thing :)

Cheers,
Claus

from flux.

Sure, I will check this once more with all stable versions of

• Typo3 4.7.x / BackendLayouts / GridElemenets/ Fluidpages / Fluidcontent / TV
• Typo3 6.0.x / BackendLayouts / Fluidpages / Fluidcontent / TV

but it took some time. I think I can publish the PR at sunday evening.

Is flux scheduled to be compatible with Typo3 6.0.x and gridelements 2.x?

Kind regards
Heiko

from flux.

Thanks a lot for looking into this one Heiko, really helps :)

Is flux scheduled to be compatible with Typo3 6.0.x and gridelements 2.x?

Yes on both counts - with Gridelements 2.0 support being considered nice but not vital, since I know how much of the TYPO3 logic it changes. Requiring Gridelements compatibility could be a huge task in maintenance and special cases and after all, it is Gridelements that is replacing the TYPO3 logic, making it incompatible.

Cheers,
Claus

from flux.

Hi Heiko,

Would you mind giving this one a whirl again - with the latest versions (TER should be OK)? There have been two fixes in relation to drag and drop and gridelements and I'm hoping they solved your issue as well :)

from flux.

Hi Claus, nice to hear :)

Sure I will test it. But I'm verry busy this week(end).
Would it be ok next weekend?

Kind regards
Heiko

from flux.

Sure I will test it. But I'm verry busy this week(end).

Should be just fine - no rush :)

from flux.

Hi @heiko-hardt !

Any news on that issue regarding your tests?

Kind regards,
Cedric

from flux.

Hi Cedric, sorry for the delay.

I'm verry sorry, but the problems still exist.

Environment 1: Typo3 v.4.7.14 / templating based on backend-layout / gridelements 1.4.1 / flux 6.0.1
Environment 2: Typo3 v.6.1.3 / templating based on backend-layout / gridelements 2.0.2 / flux 6.0.1

Kind regards,
Heiko

from flux.

Hi Heiko and community!

Are there any news about these problems?
We also have these with TYPO3 v. 6.1.6 / flux 6.0.1

Cutting a content element is impossible. If we cut it and paste it into another site there are always two elements with same ID. Further isn't it possible to insert a reference with the gridelement including content elements. They are always empty.

Thanks for your support,
Katharina

from flux.

Hi @KatExinit,

Would you mind trying this again with Flux 6.0.2 which was recently released? This version contains only bugfixes compared to 6.0.1 and hopefully the fix for your issue was included. If not, maybe this can then help. If (and only if) you use flux for your own plugins (e.g. not for nested content elements, not for page templates via fluidpages - truly, only for your own custom plugins as a replacement for flexforms) it should be very easy to upgrade Flux to the git master - and the git master solves even more problems in this regard, in particular @danilobuerger recently solved one that was a very likely candidate to mess with copying. EDIT: the reason I don't recommend an upgrade to the git master of fluidcontent/fluidpages also, is that this almost certainly involves a large amount of migration work which would further complicate a roll-back; a test upgrade of flux if used only with plugins, would be a much more manageable task.

@heiko-hardt this of course also applies in your case, but there is another possible cause: a bug fix was introduced around TYPO3 6.1.3 which would be required by Flux; if possible, please upgrade that core to 6.1.6. Since we will be dropping 4.x support completely very soon, I'm a little reluctant to make fixes for 4.x + flux + gridelements (but I certainly won't have any objections if you or anyone else locates the problem and makes a pull request!).

Hope this helps :)

Cheers,
Claus

from flux.

I am taking the liberty of closing this one due to inactivity; several copy/paste issues have been fixed in connection with logic cleanups in Flux - namely, more closely controlling the conditions required to trigger Flux. Also, bug fixes for the TYPO3 core itself has helped remove part of this problem (a missing fieldname, causing Providers to trigger too eagerly).

If the problems persist in the git development branch don't hesitate to let us know!

Cheers,
Claus

from flux.