Documentation missing: "colPos" for flux:grid.column – which value?

[TostaTosta]

Hi,

I am trying to update a huge Website from TYPO3 6 to TYPO3 8. I learned, that some “template files must be migrated to add "colPos" for each flux:grid.column”. I wonder what is supposed to be the value of the added attribute colPos since I find no hint in the changelogs or anywhere else. Documentation doesn’t seem to be up-to-date yet.

I have template code like this:

<flux:grid.column name="content.{iteration.index}" label="{f:if(condition: panel.panel.title, then: panel.panel.title, else: 'Content, panel {iteration.cycle}') }" />

Note: I did not develop this particular website, and I’m afraid I’m not experienced in TPO3fluid. :-(

Thanks for helping me on!

— Tosta

[grimmcreative]

<flux:grid.column colPos="1" name="somename" label="somelabel" />

the colPos value can be from 0-99

[TostaTosta]

Thank you. But which of 0-99 to choose? The value does have a meaning, doesn’t it?…
The former documentation says: “Use the name attribute for grids in content elements, and the colPos attribute for grids in pages templates”. With up-to-date flux, colPos has become mandatory. How can I determine the correct colPos value?

[samowitsch]

@TostaTosta i have here the same problem migrating flux to current version. I have nested content elements and i have no clue what i should do? Should i add the attribute colPos with the 18181 stored in database? I don't know... the first try running the flux update script in extension manager was not successfull 😞

[chriskrj]

Did you rename your FCEs from flux_contentname to yourextname_contentname before running the update script?

You could do something like this:

UPDATE tt_content 
SET CType = LOWER(
                REPLACE(CType, 'flux_', yourextname_')
            )
WHERE CType LIKE 'flux_%';

[samowitsch]

@chriskrj Thx for your feedback. Yes i renamed the CTypes in database (mentioned here FluidTYPO3/fluidcontent#424). And after a check it seems that the update script did its job BUT where i am not sure is how to handle flux colPos where is now a mandatory field.
Should i change all my templates for content elements (for example a two column wrapper) and add colPos="18181" to it (because this was the colPos flux used before)? Or how should that work? The update script generates its own colPos numbers? I am a little bit confused 😉

[chriskrj]

In your Flux Forms you should only use numbers from 1 to 99 everything above is deprecated. so if you have 2 columns just use colPos=1 and colPos=2 for you columns. Flux generates his own colPos value to the database. Id of the element + 0 + colPos Value i think. colPos Value=18181 isn't used anymore.

<flux:grid>
  <flux:grid.row>
    <flux:grid.column label="Col 1" name="col1" colPos="1">
    </flux:grid.column>
    <flux:grid.column label="Col 2" name="col2" colPos="2">
    </flux:grid.column>
  </flux:grid.row>
</flux:grid>

[samowitsch]

@chriskrj i have changed my page templates using colPos from 1 to 99 so far so good.

But like i said i have for example a content element as an two column wrapper using flux:grid.column. Before colPos was optional and now it is mandatory. Before colPos was 18181 (internal?).
And now? Should i add now this attribute or not? With which value and how does i affect the update script? Or is my thinking to complicated and everything ist fine 😉

See my colPos from tt_content. flux generates new colPos numbers? I am not shure for what? I am confused...

colPos 
0 <= colPos<=99 used in page templates
1
2
3
10
20
30
40
60
65
70
18181 <= old 'automatic' colPos from flux before migration
18281 <= this and below generated thru flux update script?
18381
18581
18681
24081
24481
24781
25881
27781
28981
30681
31681
31881

[chriskrj]

@samowitsch i actually think, that the Flux update script doesnt worked out well in your case.
And Yes dont use colPos 18181 even if this was the colPos Value before. These should be updated.

Maybe you have a older DB Backup so u can try these update steps again?
Workflow should be:

1. rename CTypes in database
2. add colPos 1 to 99 in your flux Forms
3. use Flux Update Script.

One more question. Do you use Fluidpages?

[NamelessCoder]

@samowitsch The formula for calculating colPos values is $parentRecordUid * 100 + $localColPosValue where $localColPosValue is always a value between 0 and 99 that you put in your template, regardless if it is a page or content element template.

The new colPos values can then be reversed programmatically:

$originalLocalColPosValue = $record['colPos'] % 100;
$parentRecordUid = (int)floor($record['colPos'] / 100);

This is why your colPos values look the way they do - and why 18181 is no longer used except in the one edge case where your parent record's UID is 181 and your local colPos value is 81 because 181 * 100 + 81 = 18181.

Migration script

In order for the migration script to work, the following must be true:

1. The templates must all be updated to remove the parsing error warnings you get in the EM upgrade script. Remove any template files you no longer use. The CType in database must also be corrected or Flux can't resolve the template file used by a given record.
2. The colPos values you selected must be between 0 and 99 (zero is a perfectly valid value).
3. Once a record is migrated - which may have happened incorrectly if you did an earlier step with templates that weren't correct - the column tx_flux_migrated_version gets filled with a version number. If you wish a record to be re-processed you'll need to clear this field manually.

Additional info about migrating can be found in #1542, including SQL queries that can fix your colPos values if for some reason you can't use the EM upgrade script to do it.

[samowitsch]

@chriskrj yes, i use also fluidpages and fluidcontent_core (but that is another story 😢)
@NamelessCoder thx for feedback. Ok, that means also my content elements have to use a colPos between 0 and 99. I ignore the colPos 18181 for now, curious where it comes from. I never used colPos 81 (as far a i know 😉 ) and content element with uid 181 is no wrapper element 🤔.

[NamelessCoder]

I ignore the colPos 18181 for now

If you still have that in the database after correcting your templates and migrating through EM, then that indicates one or more CTypes are not correct and/or do not resolve the right template file. If the file cannot be resolved, the Grid is not read and no records get migrated.

[samowitsch]

Just a noob question: where does the limit 99 come from? From TYPO3 core?

[NamelessCoder]

The limit is a consequence of the multiplier 100 which is arbitrary (could have been 1000 or 10000 too), but was chosen after asking users if they were likely to ever create backend layouts with more than 100 columns (the overwhelming answer was no). The smallest possible multiplier was chosen to prevent colPos values from growing needlessly large.

This limit has to be imposed because a value of for example 100 in a parent UID of 123 means the resulting colPos becomes 123 * 100 + 100 = 12400 which can't be reversed correctly (see the formula above: the resulting reversed parent UID would be 124 not 123, and local colPos value would be 0 not 100).

[NamelessCoder]

Closing due to inactivity - I assume you found answers to your questions and solutions to your problem!

[typoworx-de]

I'm also running into this migration from TYPO3 v7 (flux/fluidcontent/fluidpages) -> TYPO3 v8 with to flux+fluidpages (migrating fluidcontent to flux integration).

I have a bunch of flux ce's lost their grid-colum children for some reason. I already migrated namespaces for CType and tx_fed_fcefile. The CE for Flux-Content-Element looks to work so far. But all childrens are lost and I don't understand the logic for migrating the colPos that has been missing/was obsolete in TYPO3 v7 since migrating to TYPO3 v8.

The flux:grid.column is using name="content.{i.index}.{iteration.index}" and I've tried all possible things trying to recover the missing (now mandatory) colPos attribute. This is really frustrating.

I'm now running flux v. 9.2.0 and fluidpages 4.3 (which seems to be the only possible option for composer and TYPO3 8.7).

Does anyone have a hint for me?

[typoworx-de]

Okay... figured out it colPos seems to be the parentRecord.uid. But now I'm running into other issues... for some reason 'flux:grid.column' inside Slider-Template using f:for and flux.grid.row is always reusing same label and name attribute for all occurances inside loop. What the hell is going on there.

[NamelessCoder]

@typoworx-de Normally I don't reply to issues that have been closed for this long, but in this case the info may help others searching for migration information.

Please read through this issue to understand the calculation of new colPos values. The colPos is not merely the parent UID, it is $parentUid * 100 + $localColPos where $localColPos is the colPos="0" for example (unique values, do not reuse in the same template!), that you manually added to all occurrences of flux:grid.column as preparation for the migration.

So if parent record's UID (value of old tx_flux_parent field) is 123 and your column in the template has colPos="0" then the new colPos value of all child elements inside that column would be 12300 because 123 * 100 + 0 = 12300. If colPos number in template was 8 then the new colPos value is 12308 because 123 * 100 + 8 = 12308.

This is what gets done by the migration script which is triggered as extension upgrade script: https://github.com/FluidTYPO3/flux/blob/development/class.ext_update.php#L101

So:

• If your templates use flux:grid.column then each and every occurrence of columns must have a colPos attribute value which is unique in that template, using numbers between 0 and 99.
• If your template has multiple flux:grid.column which all have the same colPos attribute value then any child in either of the columns which share colPos value, will have the same final colPos value.
• You can still have a name attribute with values like content.{num1}.{num2} but you must have a colPos value that is unique for every column.
• Having multiple depths of dynamic columns is not advisable since it gets harder to assign unique colPos values to each column. You would need a counter that increments for every iteration of the inner loop (you can do this with <f:variable name="counter" value="{counter + 1}" /> at the end of the inner loop, and <f:variable name="counter" value="0" /> outside and before both loops to initialize the {counter} value. Then use colPos="{counter}" in each column)
• Do not change the name attribute until you are completely done migrating using the extension update script! If you do, the script will be unable to determine the new colPos value for child records.

Your problem description is a bit unclear but the symptom sounds a bit like you are not using unique colPos values, did not use a raw integer as colPos, or used values outside the allowed range of 0-99 (the reason for this limit is described in earlier comments).