[TYPO3-core] Moving of elements (records) and pages in workspace
kasper2007 at typo3.com
Wed May 23 22:22:20 CEST 2007
It's difficult to rely on Dassault in terms of time because my
experience is that priorities shift around all the time and urgent
matters require my attention quite easily. If I told them that moving
was solved they would say "yes, thank you" of course but whether its
a requirement or not is difficult to say.
Here is the deal; For 1000 Euro I'm willing to give it a serious try
since I have a renewed hope that it can be possible. But I know that
I will end up with an implementation with a todo list of limitations
to solve, but someone else could work on that from my description. So
for 1000€ I'm willing to bet that I can make a working implementation
which is acceptable as a basis for someone else to finish with regard
to a defined list of problems that would need to be tested and
solved. If I can't make anything useful at all, you will not have to
My schedule is difficult. But end of june is a probable time for me.
On May 13, 2007, at 23:05 , Sabina Loicht wrote:
> Dear Kasper, Masi
> and all of the other "workspacers" out there!
> First of all, thank you very much (esp. big thanx to Masi) for your
> involvement, ideas and suggestions to solve the current workspace-
> problem! Since plan2net placed some major complains about the
> current situation ;-) it's our turn now to place some suggestions.
> Please let us start with a short specification of the customers
> need, discussed:
> Our customer has a rather large editorial workflow.
> The whole TYPO3 installation is built around two different
> branches. One reflects the actual structure visitors can browse (we
> call this "public") and the other one contains all the articles,
> news and other records created and edited by the editorial stuff.
> Records from the editorial branch are referenced by "Insert Record"
> elements (there are some other nice concepts behind this website,
> but that's the part that fits the problem description).
> The homepage consists of a large amount of such elements as the
> update frequency is very high and the editorial staff shifts those
> elements around regularely as others e.g. become more important.
> The staff ideally has no access to the "Live" workspace. Not in the
> editorial branch nor in the public one.
> We now have the problem we all know about already... that it's not
> possible to move records in any workspace other than "Live"
> (element based).
> With more than 20 members of the editorial staff this is a rather
> critical problem on such a high demanded website.
> Our (poor) workaround currently is to hide the editorial branch
> when switching to the "Live" workspace (though the permission
> system seems to be broken regarding Workspaces and DB mounts too,
> but we fixed that).
> Since it's of course in the focus of our customer as well as in our
> own (since we intend to implement workspaces in some more
> installations in the future) we'd like to make the following
> suggestion to you, Kasper:
> as we already informed the Association, our customer is willing to
> pay EUR 1.000.- to get the problem solved.
> We would kindly ask you, Kasper, to tell us as soon as possible, if
> Dassault ask for similar functions.
> If so, we would like to add that money to the amount Dassault will
> If not, we ask to be informed as soon as possible to search for
> another solution....
> We know, that the need of our customer is not a uniqe one and
> therefore the approach to get that problem solved is really worth it.
> Thank you all again for your input and big efforts!
> Best regards,
> Sabina Loicht & Wolfgang Klinger
> At 15:49 09.05.2007 +0200, Kasper Skårhøj wrote:
>> 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:
>>> * 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
>>> Note: whether the actual moving operation described below is
>>> implemented or not, IMHO the merging feature (with the UI) makes
>>> sense anyway.
>> 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
>>> * 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
>>> 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.
>> 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
>>> * 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.
>>> Martin Kutschker
>>> 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
>>> Firmensitz Wien - Handelsgericht Wien - FN 208229w
>> - kasper
>> NOTICE: NEW EMAIL for 2007: kasper2007 at typo3.com
> Wir hoffen Ihnen mit diesen Informationen dienlich gewesen zu sein
> und verbleiben
> mit freundlichen Gruessen,
> S. Loicht
> Mag. Sabina Loicht
> plan2net e-consulting
> A-1190 Wien, Sieveringerstr. 37, AUSTRIA
> TEL +43 1 328 00 63 - 0
> FAX +43 1 998 79 48 71
> MAIL sl at plan2.net
> WEB www.plan2.net
> some of the latest plan2net-productions:
> http://www.sport1.at - Sport1, Oesterreichs groesstes Sport-Portal
> http://www.tuwien.ac.at - Technische Universitaet Wien
> http://www.austriantrade.org - Austrian Trade - WKO-Portal für die
> österreichische Außenwirtschaft
> ..... weitere Referenzen unter http://www.plan2net.at/referenzen
NOTICE: NEW EMAIL for 2007: kasper2007 at typo3.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TYPO3-team-core