[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