TYPO3 Core

This bug seems to be related to 3531. Perhaps Zach's fix is even more applicable than mine - could someone check this?

This patch works generally, but there's something important missing:

either

if ($table == 'tt_content') {
....
}

if ($table != 'pages') {
....
}

Because if this is applied to a page you get into more troubles: if you create the page with the "big button" New page in the "Page" module and create a content element immediately afterwards the content is tied to the placeholder page and not the draft one and so the content elements "disappear".

someone should take care of this and implement the patch

Changing the priority for this.

Hm, I think, it should be the second of Wolfgang's two options, because the first doesn't affect other versionized tables, so e.g. tt_news would still be affected by the new bug my patch introduced.

Of course, the Patch works generally, but after installing, in templa voila all new content elements from users in a workspace are always inserted as reference. So I had to remove the patch to get my editors work normally.

Thomas, which version of TV do you use? pre-1.3-versions had a bug that created all new content-elements as references (see #3143) . This is fixed in 1.3.

I use 4.0.4 with TV 1.3. The only thing of Zach´s code I added is the recommended if clause against 'pages'.

The error occurs only in a custom workspace. In a live workspace the patch works fine.

I am experiencing the same Problems in typo3 4.1.1 with tt_news(2.5.0) mm-relations to categories.
Will this be fixed in the core in near future?

I can confirm the issue with tt_news. Categories of news-items are lost after publishing!

This makes tt_news nearly unusable in a workspace-enviroment, because the categories must be added manually in live-workspace after publishing.

Okay meanwhile I fixed this for me (tcemain_patch4_1_1.diff &tt_news_patch2_5_0.diff) , but I think the query s I manipulated in tt_news slow things down! I cant't optimize this atm but at least it works.

thanks, for the patch.
But I have the prob, that after installing the patch everything else in the workspace won't function. All content elements will get lost after live switching. Very bad.
I made this little very, very dirty hack for tt_news. So it works only for tt_news.

class.t3lib_tcemain.php

// NSA ZACH PATCH BEGIN
if(strpos($TCA[$table]['ctrl']['title'], "tt_news")){
$this->substNEWwithIDs[$id] = $phShadowId;
}
// NSA ZACH PATCH END

please excuse my bad english and my little programming skills

Problem is still virulent in the neXt Typo3 Version 4.2.0alpha1!!!!
Let's start a run on this medusalem bug.
The trophy of 100bugs, I mean Euro will wait for a working patch, which we exceptionally can slip the developer team (despite feature freeze) - this should be happen the next two weeks or so, I guess. Hope you (mr. or mrs. core developer) will support this.
*A.

Cast Iron Coding will put up another 50 euro to sponsor this issue. Let's get it fixed, as it's really stopping us from encouraging our clients to fully adopt workspaces.

Try this Zach, and let me know if it works, or send me your extension where the mm tables are in. works for me at the few mm tables i've tested - for pages or content elements.
look at the typo3 version. tested this only for typo3 4.1.3 & the 4.2 alpha1

Thanks Andreas, but your extension has no effect on my typo3 4.1.3.

News categories are still lost after publishing news entries from workspaces.

hello thomas buss, it took some time to figure it out - as_mmswap-typo3-4.1.3-ttnewssup-0_0_1. if it works for you please support this ;-) . what i know you need the latest tt_news (2.5) version for element versioning.
prix (at) typotemp.com

I have tried the patch for dam_ttcontent and not dam_ttnews (but it should be the same problem since both are two-way MM fields). Unfortunately the patch does not work for me. It doesn't seem to have any effect :-(

Tested with 4.1.4 and 4.1.5-dev

Hello Francois,
These extensions doesn't work with the typo3 MM system, and this path right now just look on publishing if there is a MM table registered in the table to publish. Kasper nows of this problem (MM tables & workflow) - prob. it will be solved until february next year. If I will find time I'll have another look at it. even though - try to keep up good mood.

I have been looking at a related bug

If you have a mm reference in table A to something that is in draft mode in table B and then publish the object in table B it breaks the mm reference.

I think a solution to this is to trawl all the way through the $TCA looking for anything with a type = 'db' and an 'allowed' that includes table B. Then if it is a MM relation updating the MM table or if it isn't updating the field in table A

I am trying this, but at the moment it appears that the dynamic part of the TCA for a lot of the tables isn't being loaded. Is there any way of forcing it to load?

thanks

Hi all,

please check whether this has been fixed with Kasper's latest changes in trunk or the upcoming 4.2 beta1. If that is the case please provide some feedback here, so that we can mark this issue as resolved.

I agree. I have reported my patch back to issue 3531 but it also solves the problems described here. So I think you can close it!

... oh, and maybe Zach and Andreas wants to know where to send the money...? :-) Please send me an email about it.

fixed by Kasper in 4.2beta1