New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paste (copy/move), drag-n-drop and localisation bugs #573

Closed
NamelessCoder opened this Issue May 29, 2014 · 73 comments

Comments

Projects
None yet
@NamelessCoder
Copy link
Member

NamelessCoder commented May 29, 2014

This issue is the single place to report any type of issue of this type:

"My record is incorrectly positioned, contains incorrect values or was not created as expected after performing a paste/drag-n-drop command or after creating a localised version of the original record"

If your bug fits this description, report it here!

If any bugs in the mentioned areas still exist after May 28th 2014 please report them here instead of creating new issues. Before you report problems, make sure your Flux repository is checked out on the development branch and that you have pulled (or possibly reset) to obtain the latest changes.

Currently known bugs in copying:

Related core patches:

https://review.typo3.org/#/c/30633/ which ensures passing the field name while TYPO3 iterates over fields of a record. Without this patch, the logic which retrieves files stored in FlexForm references, may in some cases fail to detect the existence of said references, because Flux receives a NULL field name and thus may return an incorrect Form instance (read: resolves the Provider with highest priority for the table while ignoring the field name in priority verdict) which does not contain the correct definitions for the record field currently being processed. Furthermore, due to Flux tracking which Provider was called with a certain field, Flux was unable to execute any but the first Provider detected through this logic in TYPO3. Applying the patch passes the field name and Flux returns the correct data structure when TYPO3 iterates record fields to detect file references in FlexForm fields.

https://review.typo3.org/#/c/30632/ adds an error prevention for records which have FlexForm fields that contain references that were not correctly processed (due to the bug above). Install this patch only if you are being faced with an Exception when attempting to edit affected records.

Currently known bugs in moving:

  • "Move record up" using sorting arrows causes record to disappear when child content record is second in list.

687474703a2f2f692e696d6775722e636f6d2f6d697659336d632e706e67

Currently known bugs in drag and drop:

  • After dropping a content element from one colPos to another and then immediately thereafter using the "insert content after" link associated with the content record that was moved, the created content element is created inside the original colPos value. The content object may become invisible in page editing mode - to retrieve, use the list view and set proper colPos and as needed, Relations values.

Currently known bugs in localisation:

@Idleworks

This comment has been minimized.

Copy link

Idleworks commented May 31, 2014

Hi,
I don't know if this is a bug or a missing feature. I already mentioned in #558 (see last two posts).

At the moment localizing an element with its child elements works only once. After that there is no way to localize new child elements.
I think this i an important feature for multilanguage sites!

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 2, 2014

@glucka That one sounds like a traditional "missing dependency injection because of missing injection method in class reflection cache" and if that's the case, it is solved by clearing the (system) cache.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 2, 2014

@glucka You should be on the workbench/commands branch when testing this - we have still not merged the changes to the development branch.

@danilobuerger

This comment has been minimized.

Copy link

danilobuerger commented Jun 2, 2014

What changes?

@glucka

This comment has been minimized.

Copy link
Member

glucka commented Jun 2, 2014

@NamelessCoder sorry, i had an older development branch version. (git config problem)
The translate works fine now.

  • FCE childs with language property 'All' are still translated.
@Inkdpixels

This comment has been minimized.

Copy link

Inkdpixels commented Jun 2, 2014

Env & Steps to reproduce this bug
Env: TYPO3 6.2, flux development(d18957c)

  1. Create an Element with the viewhelper <flux:field.inline.fal /> which has the option multiple=TRUE.
  2. Add multiple FAL relations/images to the Element.
  3. Copy the Element/Page of the Element.

Expected result
A plain copy of the original record should be in place with all of the original FAL records.

What happens instead?
The element is copied, but doesn't have any of it's original FAL records.

@Inkdpixels

This comment has been minimized.

Copy link

Inkdpixels commented Jun 2, 2014

Env & Steps to reproduce this bug
Env: TYPO3 6.2, flux development(d18957c)

  1. Create an Element with an content area (flux:form.content)
  2. Insert this Element into your page record
  3. Insert another fluidcontent element/TYPO3 standard element into the content area of your element which you've created in step 2
  4. Add the content record from the third step into your TYPO3 copy clipboard
  5. Paste the record.

Expected result
A copy of the original created element should be added to your chosen destination

What happens instead?
The copy gets pasted into the list record of the page, but the element itself isn't visible in the page module.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 9, 2014

Update for #573 (comment)

The issue appears to be related to the core's copying of any record type: when copying a record which has a TCA-based relation to sys_file via sys_file_reference the record data is correctly copied. But when the relation is stored with a field name that is inside a flexform XML (the sys_file_reference will for example point to a field name called mySpecialImageFiles rather than for example images in the tt_content table).

It appears that the proper copying of references to files, is somehow triggered by or depends on the TCA configuration for the field, which means copying of FAL resources by flexform field name currently fails.

This is a core bug but I will continue to investigate it and possibly create a fix.

Side note: the copied record's XML data value for the field that was incorrectly copied will be the original records reference count. When copying the record, this value is for some reason because the COUNT() of references is zero, recognised as an UID value of a sys_file record which is then attempted referenced. The resulting state of the record can therefore sometimes be that one file reference exists, but is pointing to an unexpected file because the old reference count is being used as if it were a single UID.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 9, 2014

Update for #573 (comment)

https://review.typo3.org/#/c/30632/ is created to solve the first part of this problem.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 9, 2014

Update for #573 (comment)

https://review.typo3.org/#/c/30633/ is created to solve the second part of this problem.

@johanneslumpe

This comment has been minimized.

Copy link

johanneslumpe commented Jun 13, 2014

Copy/pasting an element from an FCE to the main column fails. It will copy the element, but not show it in the row. The same goes for pasting as a reference.

Cutting and pasting an element from an FCE to the main column does not do anything at all.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jun 13, 2014

Cutting and pasting an element from an FCE to the main column does not do anything at all.

Fixed by e91f919

@arnekolja

This comment has been minimized.

Copy link

arnekolja commented Jun 27, 2014

I had the problem that I could not place plugins in grid columns. Today I stumbled across #565 and then tried the current development branch - it solved my problem. I was able to drag and drop a tx_news plugin CE into a grid column.

Just a little success message for your pleasure :)

@patrickleonhardt

This comment has been minimized.

Copy link

patrickleonhardt commented Jun 30, 2014

Hi, I use the new fluidbootstraptheme and the new dev versions of flux and co. I am able to create for example a powermail plugin outside a row and drag it into it. But it's not possible to create a plugin directly inside the row.

@twirsing

This comment has been minimized.

Copy link

twirsing commented Jul 16, 2014

Hi, I can't get rid of "Copy default content elements" of CE "Column Row" (with child CE) does not show translated child CE" - Problem. When using flux 7.1 staging, fluidcontent 4.1 dev and fluidpages 3.1 dev I reveice an error "Fatal error: Call to a member function preparedGet() on a non-object in /var/www/ext_versions/fluidcontent_versions/fluidcontent_4_1_dev/Classes/Service/ConfigurationService.php on line 266". Apparently the recordService never gets injected.

@bjo3rnf

This comment has been minimized.

Copy link
Member

bjo3rnf commented Jul 16, 2014

Hi @twirsing,

the mentioned service is only available in the dev branch of flux.

Cheers
Björn

@twirsing

This comment has been minimized.

Copy link

twirsing commented Jul 16, 2014

Thanks Björn for the instant reply. When using the dev branch I get another error. Fatal error: Call to a member function get() on a non-object in /var/www/ext_versions/flux_versions/flux_7_1_dev/Classes/Configuration/BackendConfigurationManager.php on line 176

@twirsing

This comment has been minimized.

Copy link

twirsing commented Jul 16, 2014

problem solved. Properly emptying the caches 'Important Actions/Clear all cache' in Install Tool and it works, Thanx for the directions to @bjo3rnf

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 25, 2015

I fixed a few of the issues mentioned here on an older version about a year ago. I wrote functional tests for them, so its easy to find out when stuff breaks again. Unfortunately, on the current development version, my version of the class ContentService is totally broken. I’m currently investigating the matter, trying to find out which change outside ContentService broke the tests.

If you’re interested in my code, head to my fork here on Github: https://github.com/andreaswolf/flux/tree/working-content-service-tests

The mentioned test case is in https://github.com/andreaswolf/flux/blob/working-content-service-tests/Tests/Functional/Service/ContentServiceTest.php.

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jul 25, 2015

@andreaswolf thx
Maybe the best way would be, if we add tests in a WIP branch and resolve everything. Better a broken test as no tests at all. Target to close this issue.

What do you think?

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 25, 2015

Nevermind the tests, guys. I can fix those that break - if you focus on the behavior I'll do the tests afterwards.

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 25, 2015

I cannot really focus on the behaviour, as I don’t know how it should work. I just created a testsuite according to my client’s descriptions of what broke for them, and fixed those issues one by one. The resulting tests and the reworked ContentService worked a year ago, but I cannot get the tests green after rebasing onto the current development branch. See my fork (branch development) for the version I’m currently working on.

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 25, 2015

Ok, I found the reason why my tests break: The ContentProvider is not called anymore for regular content elements (at least in my test), as my content elements have a CType set, but there is none defined in the provider. Therefore, the check in trigger() fails.

I have no clue if this is because I use flux in a wrong way or if something is really broken. Glad for any hint into the right direction :-)

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 27, 2015

Hi Andreas,

ContentProvider should trigger on any record from tt_content when the field pi_flexform is included in the field list (see links below). Could this be the cause for your tests failing? If so, I should think you can simply set an empty string as $record['pi_flexform'] on your database record test fixture.

https://github.com/FluidTYPO3/flux/blob/development/Classes/Provider/ContentProvider.php#L41 defines triggering table and field name.
https://github.com/FluidTYPO3/flux/blob/development/Classes/Provider/AbstractProvider.php#L197 shows the triggering method that checks table and field, among other things.

It is possible that the trigger method does something unexpected, but I'm hoping it is just because of the expected field name. If all else fails you can create a fixture Provider and register that, or mock the resolveConfigurationProvider* method(s), but I'm sure you know all this ;)

Please ping if I can assist with more info! Anything I can do to help.

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 28, 2015

Hi Claus,

thanks for the pointer. Unfortunately, this did not fix the problem: I stepped through AbstractProvider::trigger() and the problem is that $contentObjectType is not set in ContentProvider. As my content records do have a content type already, the check $matchesContentType fails.

Apart from that, I would like to stay away from mocking as long as possible. These functional tests should test the actual default behaviour as I would expect it from Flux. If my tests do make false assumptions, these need to be fixed instead :-)

Additionally, I wonder why ContentService::pasteAfter is triggered by such an exclusive check. As far as I see, it makes sense to execute this method after every paste operation, right?

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 28, 2015

@coding46 you were picking at this issue a while back, right? Issues with the trigger() method on ContentProvider? What @andreaswolf notes here is actually correct and may be an edge case that happens on first saving the record; we may need to not only check explicitly if $record['CType'] is NULL, but also if it isempty()`. I'm not sure what TYPO3 posts in this case but I expect an empty string.

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 28, 2015

No, CType contains (at least in my test cases) an actual value like "text". trigger() already checks if the configured value matches the one in the record or if both are empty. But both these checks are useless, as they won’t catch the general case that all records need to be processed after they were inserted. Or am I missing something?

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 28, 2015

I think what has happened here is that originally, we did not need to trigger any Provider unless the record we were operating on (via TCEMain/DataHandler) actually contained a Flux-enabled field. Earlier, the Provider was responsible mainly for things like trimming the Flux-enabled fields and analysing/removing inherited variables. And we had "pure" TCA relations as our way to support localising all children of a particular column and cascading deletions; etc.

But at some point we lost the ability to depend on the various parameters being passed from the page module to our code - there was a switch from using actual URL parameters to using XHR with harvested variables. And we were unable to affect these variables correctly in order to make the TYPO3 core itself cause all these things - for example, adding the parent content element UID and column name. Since then we have implemented numerous fixes, the most ugly of which is the use of large negative integers for colPos values, stored in a temporary session variable, so that our Provider can translate this large negative integer to a set of parent UID and column name. Bad, bad, bad. But the only way we had available.

At this point (sorry about the history lesson here but I think it's relevant or I wouldn't bother you) we began facing issues: non-Flux-enabled content elements were not being correctly processed when for example we added new content in a Flux content column. Putting two an two together it becomes quite obvious why we have these problems - it is, of course, since we now depend on a Provider for every single content record even if the record has nothing to do with Flux. We are in this situation because of the recent changes that switched from calling a URL to harvesting and doing an XHR. Specifically: we are no longer able to prefill the "defaultValues" array with dynamic variables and so the "new content" editing form never receives these variables.

It should be the solution to adapt ContentProvider in a way that it triggers (at least) once per content record regardless of anything configured in this record. The only trigger variable should be: "is this record from tt_content?". If it is, our ContentProvider needs to operate on it or relationships will fail because of all of the above history.

On a side note this should also mean that we can completely remove the LightWeightProvider. It seems to have been created to get around this issue but it only partially solves it, in that it only listens for a limited set of commands - where the ContentProvider would be listening to all commands as it should.

@NamelessCoder

This comment has been minimized.

Copy link
Member

NamelessCoder commented Jul 28, 2015

Hi Andreas,

Would you mind trying your functional tests on top of the linked pull request? I have adapted ContentProvider to make sure it triggers this once per tt_content record as mentioned and have discarded the LightweightProvider at the same time. It may not solve the issue but at least the code you're testing should then be executed.

@andreaswolf

This comment has been minimized.

Copy link

andreaswolf commented Jul 28, 2015

Claus, will do tomorrow. Thanks for taking care! :)

andreaswolf added a commit to andreaswolf/flux that referenced this issue Jul 29, 2015

[BUGFIX] Ensure ContentProvider triggers on every tt_content record
For a full back story about this patch, please see GitHub discussion starting from:

FluidTYPO3#573 (comment)
@Marc-Bauer

This comment has been minimized.

Copy link

Marc-Bauer commented Jul 30, 2015

Hi,
I have fixed the problem with moveing content elements in flux columns (see patch)

Index: typo3conf/ext/flux/Classes/Service/ContentService.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- typo3conf/ext/flux/Classes/Service/ContentService.php   (revision 104)
+++ typo3conf/ext/flux/Classes/Service/ContentService.php   (revision )
@@ -13,6 +13,7 @@
 use TYPO3\CMS\Core\DataHandling\DataHandler;
 use TYPO3\CMS\Core\SingletonInterface;
 use TYPO3\CMS\Core\Utility\GeneralUtility;
+use TYPO3\CMS\Extbase\Utility\DebuggerUtility;
 
 /**
  * Flux FlexForm integration Service
@@ -208,11 +209,15 @@
            } elseif (0 <= (integer) $relativeTo && FALSE === empty($parameters[1])) {
                list($prefix, $column, $prefix2, , , $relativePosition, $relativeUid, $area) = GeneralUtility::trimExplode('-', $parameters[1]);
                $relativeUid = (integer) $relativeUid;
+               $relativePosition = 'top';
                if ('colpos' === $prefix && 'page' === $prefix2) {
                    $row['colPos'] = $column;
                    if ('top' === $relativePosition && 0 < $relativeUid) {
                        $row['tx_flux_parent'] = $relativeUid;
                        $row['tx_flux_column'] = $area;
+                       if($GLOBALS['BE_USER']->workspaceRec['uid'] != 0) {
+                           $row['t3ver_wsid'] = $GLOBALS['BE_USER']->workspaceRec['uid'];
+                       }
                    }
                }
            } elseif (0 > (integer) $relativeTo) {
Index: typo3conf/ext/flux/Classes/Provider/LightweightProvider.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- typo3conf/ext/flux/Classes/Provider/LightweightProvider.php (revision 103)
+++ typo3conf/ext/flux/Classes/Provider/LightweightProvider.php (revision )
@@ -11,6 +11,7 @@
 use FluidTYPO3\Flux\Service\ContentService;
 use TYPO3\CMS\Core\DataHandling\DataHandler;
 use TYPO3\CMS\Core\Utility\GeneralUtility;
+use TYPO3\CMS\Extbase\Utility\DebuggerUtility;
 
 /**
  * LightweightProvider for moved records
@@ -52,6 +53,20 @@
     */
    public function postProcessCommand($command, $id, array &$row, &$relativeTo, DataHandler $reference) {
        $moveData = $this->getMoveData();
+//     DebuggerUtility::var_dump($moveData);
+       if(empty($moveData) === TRUE) {
+           $callback = $this->getCallbackCommand();
+           if (TRUE === isset($callback['paste'])) {
+               $pasteCommand = $callback['paste'];
+//             DebuggerUtility::var_dump($pasteCommand);
+               $parameters = explode('|', $pasteCommand);
+               $parameters[1] = 'colpos-18181-page-'.$parameters[1];
+               $moveData = $parameters;
+           }
+       }
+//     DebuggerUtility::var_dump($moveData);
+//     die();
+
        $this->contentService->moveRecord($row, $relativeTo, $moveData, $reference);
    }
 
@xf-

This comment has been minimized.

Copy link
Member

xf- commented Jul 30, 2015

looks interesting, includes Workspaces :)
Do you want to create a Pull Request?

@Marc-Bauer

This comment has been minimized.

Copy link

Marc-Bauer commented Jul 31, 2015

yes of course if have done it.
including a bug fix for copy content elements in flux content columns. :) Including Workspaces too ;)

andreaswolf added a commit to andreaswolf/flux that referenced this issue Aug 4, 2015

[BUGFIX] Ensure ContentProvider triggers on every tt_content record
For a full back story about this patch, please see GitHub discussion starting from:

FluidTYPO3#573 (comment)

galoppi added a commit to sitegeist/flux that referenced this issue Aug 4, 2015

@cgrossde

This comment has been minimized.

Copy link

cgrossde commented Aug 5, 2015

I just tested copy and paste with the latest 6.2 version of Typo3 (branch: TYPO3_6-2) and Flux (branch: development).

When I copy a standard text element I get the following error:

Uncaught TYPO3 Exception
#1257246929: "" is not a valid template resource URI. (More information)

TYPO3\CMS\Fluid\View\Exception\InvalidTemplateResourceException thrown in file
/var/www/html/typo3_src/typo3/sysext/fluid/Classes/View/TemplateView.php in line 338.

17 TYPO3\CMS\Fluid\View\TemplateView::getTemplateSource()

/var/www/html/typo3conf/ext/flux/Classes/View/ExposedTemplateView.php:
00134:    $parsedTemplate = $this->templateCompiler->get($templateIdentifier);
00135:   } else {
00136:    $source = $this->getTemplateSource();
00137:    $parsedTemplate = $this->templateParser->parse($source);
00138:    if (TRUE === $parsedTemplate->isCompilable()) {

16 FluidTYPO3\Flux\View\ExposedTemplateView::getParsedTemplate()

/var/www/html/typo3conf/ext/flux/Classes/View/ExposedTemplateView.php:
00109:   $this->baseRenderingContext->setControllerContext($this->controllerContext);
00110:   $this->templateParser->setConfiguration($this->buildParserConfiguration());
00111:   $parsedTemplate = $this->getParsedTemplate();
00112:   $this->startRendering(AbstractTemplateView::RENDERING_TEMPLATE, $parsedTemplate, $this->baseRenderingContext);
00113:   $viewHelperVariableContainer = $this->baseRenderingContext->getViewHelperVariableContainer();

15 FluidTYPO3\Flux\View\ExposedTemplateView::getStoredVariable("FluidTYPO3\Flux\ViewHelpers\FormViewHelper", "form", "Configuration")

/var/www/html/typo3conf/ext/flux/Classes/View/ExposedTemplateView.php:
00066:  public function getForm($sectionName = 'Configuration', $formName = 'form') {
00067:   /** @var Form $form */
00068:   $form = $this->getStoredVariable(AbstractFormViewHelper::SCOPE, $formName, $sectionName);
00069:   if (NULL !== $form && TRUE === isset($this->templatePathAndFilename)) {
00070:    $form->setOption(Form::OPTION_TEMPLATEFILE, $this->templatePathAndFilename);

14 FluidTYPO3\Flux\View\ExposedTemplateView::getForm("Configuration", "form")

/var/www/html/typo3conf/ext/flux/Classes/Provider/AbstractProvider.php:
00288:      $viewContext->setVariables($variables);
00289:      $view = $this->configurationService->getPreparedExposedTemplateView($viewContext);
00290:      $form = $view->getForm($section, $formName);
00291:     }
00292:    }

13 FluidTYPO3\Flux\Provider\AbstractProvider::getForm(array)

/var/www/html/typo3conf/ext/flux/Classes/Provider/AbstractProvider.php:
00632:   */
00633:  public function postProcessDataStructure(array &$row, &$dataStructure, array $conf) {
00634:   $form = $this->getForm($row);
00635:   if (NULL !== $form) {
00636:    $dataStructure = $form->build();

12 FluidTYPO3\Flux\Provider\AbstractProvider::postProcessDataStructure(array, "No source value in fieldname "tx_templavoila_ds"", array)

/var/www/html/typo3conf/ext/flux/Classes/Backend/DynamicFlexForm.php:
00073:   $providers = $this->configurationService->resolveConfigurationProviders($table, $fieldName, $row);
00074:   foreach ($providers as $provider) {
00075:    $provider->postProcessDataStructure($row, $dataStructArray, $conf);
00076:   }
00077:  }

11 FluidTYPO3\Flux\Backend\DynamicFlexForm::getFlexFormDS_postProcessDS("No source value in fieldname "tx_templavoila_ds"", array, array, "tt_content", "")

galoppi added a commit to sitegeist/flux that referenced this issue Aug 6, 2015

NamelessCoder added a commit that referenced this issue Aug 6, 2015

Merge pull request #873 from sitegeist/bugfix/573/sorting-to-top
[BUGFIX] for issue #573: move record up to top position

NamelessCoder added a commit that referenced this issue Aug 8, 2015

[BUGFIX] Issue #573: move record up to top position
# Conflicts:
#	Classes/Service/ContentService.php
@eckonator

This comment has been minimized.

Copy link

eckonator commented Aug 11, 2015

There is currently still a bug with multilingual sites. If I switch in backend to Modul "Web" -> "Page" -> Langauge-View and there creating 2 content elements and move one of them down, the translation goes to the fluid content area if i do the same in translation column. Is it already known? I think there goes something terrible wrong and the backend runs into a memory limit error. After this, i can't revisit this page in backend and have to delete it directly in phpmyadmin. Tested with the current development branch at TYPO3 6.2 LTS.

bug-transaltion-moving

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 93 bytes) in /var/www/testproject/html/typo3conf/ext/flux/Classes/View/PreviewView.php on line 499

@robsonrobi

This comment has been minimized.

Copy link

robsonrobi commented Aug 11, 2015

The same problem exist in TYPO3 7.4 (#886)

@xf-

This comment has been minimized.

Copy link
Member

xf- commented Aug 11, 2015

Hi,
this issue and big reference list is closed.
Looks like a issue is in translation and position. Please use new issue crated by @robsonrobi #886

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment