[TYPO3-dev] moving records in offline workspaces

Kasper Skårhøj kasper2006 at typo3.com
Mon Mar 6 12:04:22 CET 2006


Hi Peter,

> as some of you might have noticed theres currently (talkin bout
> 4.0beta3) no way to move records in any non-live workspace.
> Trying to simply change the order of content-elements in web>page- 
> module
> gives the error-msg
>
> Move attempt failed due to workspace restrictions:
> Could not remove record from table "tt_content" from its page "xxx"
> Could not insert record from table "tt_content" in destination PID  
> "xxx"
>
> which cant be correct: there are no restrictions for content-elements.

While the error message lacks usability (ie. it doesn't describe the  
problem correctly in the context) it _IS_ correct that content  
elements can't be moved unless they are a new version in a workspace.

 From "Inside TYPO3":

<snip>
“Element” versions are the most basic form and also the simplest.  
Whenever possible I would prefer this type because of the simplicity.  
However “Element” versions cannot take their environment into  
account. So moving an “Element” version to another page or even  
within the same page is impossible (or so complex to implement that  
we didn't even try).

</snip>

<snip>

●Moving records

●Records that are related to "Page" and "Branch" versions of a page  
can be moved internally or to other "Page" or "Branch" versions as  
long as the source and destination root points has a stage that  
allows it.

●New records created with a place holder element can be moved freely  
around except into other "Page" and "Branch" versions.

●Generally, the stage of a moved record has to allow for editing  
plus regular permissions for moving are observed.


</snip>



Since (in another mail) you seem "alarmed" that no one has reported  
the moving-issue as a bug it is clear to me that you have not read  
the latest workspace related changes made to "Inside TYPO3" and  
"TYPO3 Core Api". A compilation of relevant pages has been published  
along with the beta-test announcement in 2005. However I can now  
point out that these documents can be checked out in the latest  
versions from CVS, module "CoreDocs" found in the "typo3" project on  
SourceForge.


Notice especially:

<snip>moving an “Element” version to another page or even within  
the same page is impossible (or so complex to implement that we  
didn't even try).</snip>


Considering that what you _can_ move already imposes very complex  
permission checks in workspaces, I can assure you that I really mean  
it very seriously when I write that it is "so complex to implement  
that we didn't even try".



>
> diggin deeper into this im thinkin about the needed *concept* for  
> moving
> records in offline workspaces. i see different scenarios that
> t3lib_tcemain::moveRecords() should take care of.
>
> - Changing the order of two elements on the same pid
> seems pretty clear:
> If two records on the same pid shall change their order both records
> have to be an offline version before.

Requirement but not enough.
The complexity of pids/sorting fields is NOT to change it in an  
offline version but to _preview_ it in frontend/backend! Trying to  
implement such a preview/reflection is incredibly complex! (you can  
find some explanation to this if you read about workspaces in  
relation to backend/frontend applications in "TYpo3 Core Api")


> If the workspace is not configured to "Disable auto-versioning when
> editing" and one or both records dont have a version in the current
> workspace, tcemain should create the needed versions otherwise spit an
> error.
> Changing the order of the offline-versions should result in the same
> change online after publishing.
>
> so far - so good.
>
> but what to do if a record is moved to another pid as its current?
>
> cant help it, but the only idea i have to create a record with
> t3ver_state=2 on the current pid and a version of the record (and
> versions of all affected records, see above) in the right place at the
> target-pid feels like loads of overhead both in database and work and
> understanding for the editor that will have to publish on two pages to
> simply move one record.

Now, this idea is on the other hand a great suggestion for a possible  
compromise!
It would be relatively simple to implement moving of any element as a  
question of "deleting" from original location and "creating" in new  
location. Usability wise this could be transparently done. Overhead:  
Yes, but only possibility.

BTW: the moving problem proposes two scenarios of using versioning:

Using old column-based content element method (sorting in columns):  
Use "Page" versioning and you can move as you like (also to other  
pages with "page" versions)!
Using TemplaVoila: Use "Element" versioning and you can move as you  
like! (since the sorting order is insignificant for templavoila!)



For now the solution for moving records will not be implemented  
before the next version at earliest!

- kasper




>
> is anybody out there with me?
> did anyone allready work on this?
> whats the plan?
>
>
> greetinx to those workin during weekends ;)
> pekue
> _______________________________________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.netfielders.de
> http://lists.netfielders.de/cgi-bin/mailman/listinfo/typo3-dev


- kasper

"A contribution a day keeps the fork away"
-------------------------------
kasper2006 at typo3.com | +45 20 999 115 | skype: kasperskaarhoej |  
gizmo: kasper_typo3






More information about the TYPO3-dev mailing list