[TYPO3-core] Moving of elements (records) and pages in workspace

[Kasper Skårhøj]

Hi Martin et al,
Hi core team.

I take this opportunity to provide my view on it:

First of all, workspaces was designed in a way that had the least  
possible impact on the Live website in terms of compatibility, bugs  
etc. As you all should know, previews in the draft / custom  
workspaces is made possible through overlays of records.

The problem of changing the ordering of elements or pages is, that  
the process of displaying content in a draft/custom workspace is like  
this in both frontend and backend:
- Select all Live records
- Look for overlays of those and apply if found.

This flow works well for created, changed and deleted records.  
However, it doesn't work for moving.

If we were to implement a preview of moved pages or records we would  
have to extend the "Select all Live records" step to "Select all Live  
records - and, oh, btw, check if in the workspace there are records  
which are somehow marked to be inserted somewhere in this order/pid -  
or which has been moved away from it". That is just the preview side  
of it. On top, the ordering mechanism in tce_main would have to be  
changed because if you want to insert any element between two which  
has sorting numbers 12 and 13 a completely new set of sorting numbers  
will be applied on the live records which cannot happen.

My gut feeling is that implementing this additional processing that  
checks if records are moved to a selected set of records will be  
quite complex to achieve. However, thinking about it now makes it  
somehow more clear that it could be possible. After all we are post- 
processing settings like hidden/starttime etc also. And assuming that  
we can log whereto people want to move record in some way we might be  
able to pull it off without messing everything up.

I will work for Dassault Systemse on workspaces in the end of June  
and thus there is a chance that they will ask for the same feature  
and through that I might be called in to give it a shot...


And now to some feedback on Masis mail:


> Prerequesits:
>
> * Merging of versions
>
> It must be possible to merge all element versions (page and  
> content) into one new page version. Furthermore this must be  
> possible for branch versions as well (merge all page and element  
> versions into a new branch version).
>
> This merging feature must have an API and should have a UI (see  
> below).
>
> Note: whether the actual moving operation described below is  
> implemented or not, IMHO the merging feature (with the UI) makes  
> sense anyway.

Yes.
However, it would be interesting to investigate what practices people  
have around usage of workspaces. For a templavoila website I don't  
think anything but element versioning should be used. And I'm kind of  
critical to the real value of page/branch versioning also!

>
> * Coupling of versions
>
> It must be possible to couple two or more versions within a  
> workspace. Coupled versions change their state synchronously and  
> are published at the same time as well.
>
> This coupling feature must have an API, but there is no need for a  
> UI to couple versions manually.

This could be solved on the UI level, but I see what you mean.

>
> Optional changes:
>
> * UI for page version merge
>
> Web>Page will show a "Merge versions" button, when it encounters  
> versioned elements and/or the page record itself is versioned.
>
> * UI for branch version merge
>
> The versioning info (invoked via context menu of the page tree) has  
> an option to create new branch versions. The UI needs to be  
> extended to warn the user that the new branch version will merge  
> all existing versions.
>
> Related info: bug #5022 describes the  problem when a new branch  
> version is "layered on top" of existing page and element version.  
> Currently they are "shadowed" and so are lost to the users.
>
> Required changes:
>
> * Automated page versions of target and source pages when moving  
> elements
>
> When you move elements TYPO3 will create a new page version of the  
> source and the target page (unless such versions exist already). If  
> necessary it will automatically merge any element versions into new  
> page versions. The page versions are coupled to make the move  
> operation atomic.
>
> * Automated branch versions of target and source parent pages when  
> moving pages
> .
> When you move pages TYPO3 will create a new branch version of the  
> source and target page (ie. the old and new parent page). If  
> necessary it will automatically merge any element and page versions  
> into new branch versions. The branch versions are coupled to make  
> the move operation atomic.

I understand what you mean and yes, it would be a way to solve moving  
things around. However, I think the impact is far too big. Say people  
move a page on the first level of a site and a complete branch below  
gets versioned! Most likely that is not what the user intended and I  
foresee huge amounts of waste data in many systems due to a simple  
need, something people wouldn't trade for just noting down that a  
page has to be moved at some point.

So I'm not much in favour of this approach and as it is now I would  
prefer to investigate moving in the element versioning paradigm which  
is much more agile in the first place.


BTW:
When I worked in Paris in March I tried to optimize their site. I  
found that SQL statements in the backend selecting records in a  
workspace are scanning the whole table! The reason is that they look  
up records like this: "where (t3ver_oid=X OR uid=X)" Because it is an  
OR operation the index table is NOT used at all and it cannot be used  
according to MySQLs own explanation of how indexes work. It should  
say that both t3ver_oid and uid is in the same index together. But  
even thought you could imagine this to work, MySQL doesn't use it -  
hence it scans the whole table in the Web>List module! I don't know  
yet how to solve this issue. It is only found in the backend I believe.


- kasper





>
> Notes:
>
> * Version type restrictions
>
> The algorithm described above does not address the problem what  
> happens if a workspace has disabled page or branch versions.  
> Possible options are to disallow moving if it is not possible to  
> create the necessary versions or to weaken the limitations. For  
> this there are two more options: always allow auto-creation of all  
> version types or a new setting for workspaces that enables auto- 
> creation of version types explicitely.
>
> * New UIDs of records
>
> The element-move alogrithm does not address the problem that some  
> operations create new UIDs for elements. This problem can IMHO be  
> solved by introducing an "object id" which is used for relations  
> and HTML linking. The object id stays the same for all versions of  
> on "object" (ie element). This means that once the first verision  
> of an element is created the object id is copied to all new  
> versions of it. Unfortunately this is not compatible the existing  
> implementation of TYPO3. Anyway, this probem is out of the scope of  
> this document.
>
> Masi
>
>
>
>
> Martin Kutschker
> Consultant
> ACTIVE SOLUTION Software AG
> Ziegelofengasse 33
> A-1050 Wien
> Tel. 	+43 1 532 78 03-30
> Fax 	+43 1 532 78 03-33
> martin.kutschker at activesolution.at
> www.activesolution.at
>
> Firmensitz Wien - Handelsgericht Wien - FN 208229w
>
> <Ingenieurbuero.jpg>
>
>
>

- kasper

----------------------------
NOTICE: NEW EMAIL for 2007: kasper2007 at typo3.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.netfielders.de/pipermail/typo3-team-core/attachments/20070509/2b8bcfde/attachment-0001.html