TYPO3 Core

Kasper, could you please have a look at this? I don't dare to fiddle with the WS internals, but this seems to be a real problem.

I had a bugreport on Page TSconfig before 4.0 was released but fixed it back then - or concluded that it wasn't a problem.
I don't have time to check this now, but I would like to ask for specific steps to reproduce the problem since I fear I will find that it works for me if I test since it worked last time.
About the -1 : Sounds like a bug, but I will have to take a closer look.
It will take a while until I get around to look at this. Probably some months.

This problem is somehow a duplicate or at least closely related to 0003249.

@Kasper Skårhøj: Perhaps have a look at issue #16040 for a configuration that showed the error. I don't know whether the problem occurs with the default draft-workspace or not, I just noticed it with a custom workspace. In the live-workspace everything was ok.

edit: I just noticed that this problem also, even with my patch, occurs, if a workspace-version of the root-page with the TS-config exists.

Another note: It is really important to know that this doesn't seem to happen to e.g. bold text formatted with <b></b>. It only happens with <span>-elements, as they seem to be removed in the default RTE-config, and this is obviously the configuration that is used in custom draft-workspaces.

Here is the configuration that doesn't work here with an unpatched version of the T3 core:

Page TS-Config:

RTE.default { # contentCSS muss die Definition der Klassen enthalten, die der RTE anzeigen soll
contentCSS = fileadmin/templates/css/test.css
classesParagraph = box-hinweis, box-warnung, box-info

showButtons = blockstylelabel, blockstyle, textstylelabel, textstyle, formatblock, bold, italic, strikethrough, subscript, superscript, left, center, right, orderedlist, unorderedlist, outdent, indent, insertcharacter, line, link, image, table, user, acronym, findreplace, spellcheck, chMode, inserttag, removeformat, cut, copy, paste, undo, redo, showhelp, about, toggleborders, tableproperties, rowproperties, rowinsertabove, rowinsertunder, rowdelete, rowsplit, columninsertbefore, columninsertafter, columndelete, columnsplit, cellproperties, cellinsertbefore, cellinsertafter, celldelete, cellsplit, cellmerge
  toolbarOrder = blockstylelabel, blockstyle, space, textstylelabel, textstyle, bar, space, formatblock, bar, linebreak, fontstyle, space, fontsize, space, bar, cut, copy, paste, bar, bold, italic, underline, bar, strikethrough, subscript, superscript, bar, lefttoright, righttoleft, bar, left, center, right, justifyfull, bar, undo, redo, bar, orderedlist, unorderedlist, outdent, indent, bar, textcolor, bgcolor, textindicator, linebreak, emoticon, bar, insertcharacter, line, link, image, table, user, acronym, bar, findreplace, spellcheck, bar, chMode, inserttag, removeformat, bar, showhelp, about, linebreak,  toggleborders, bar, tableproperties, bar, rowproperties, rowinsertabove, rowinsertunder, rowdelete, rowsplit, bar, columninsertbefore, columninsertafter, columndelete, columnsplit, bar, cellproperties, cellinsertbefore, cellinsertafter, celldelete, cellsplit, cellmerge

1. einige Elemente in der Absatzformat-Liste verstecken
   hidePStyleItems = pre,address,h1,h2

showStatusBar = 1
  enableWordClean = 1

useCSS = 1

showTagFreeClasses = 1

enablePersonalDicts = 1

removeTags = center, o:p, sdfield, h1, h2
  removeTagsAndContents = style,script
  hideTags =

proc {
    allowTags (
      a, abbr, acronym, address, blockquote, b, br, caption, cite, code, div, em, h1, h2, h3, h4, h5, h6, hr, i, img, li, link, ol, p, pre, q, sdfield, span, strong, sub, sup, table, tbody, td, th, tr, tt, ul
    )
    keepPDIVattribs = style, xml:lang, style

entryHTMLparser_db = 1
    entryHTMLparser_db.tags {
      span.fixAttrib.style.unset = 0
      span.allowedAttribs = class,style,align
      p.fixAttrib.style.unset = 0
      p.allowedAttribs = class,style,align
      img >

keepNonMatchedTags = protect
    }
  }
}

htmlarea ext-config:

Minimal configuration
Enable compressed scripts (I don't think that this is related to the problem, but you'll never know)

We've got the same problem! This is a nasty bug. It took us weeks to findout, it was a bug. Does anybody knows when it's gonna solved...?

@Bas: You could try to apply my patch and then report if it works afterwards. This could perhaps help Kasper and the other members of the core-team to solve this issue quicker.

how can i install this patch on a windows server?

Andreas, did you also notice troubles with page access control? I couldn't figure out which page permissions TYPO3 uses or should use: the ones from the current workspace? always from live?

Bas, I just uploaded my patched class.t3lib_befunc.php. Copy it to the t3lib/-dir of your TYPO3-Installation and it should work.

@Martin: No, but I just checked it, and there seem to be some strange issues with the access control. If I set access rights in a draft-workspace in a whole branch, the changes are only applied to some pages (I suppose it's those pages of which no draft-version exists. Normally the draft-version should be edited if it exists, at least to my mind).
I'm not really decided whether the access rights of the live-page should be used everywhere or if access rights should be versioned, too. It seems as if the core-team has decided to version access-rights, but I'm not sure.

Ok, I just made a test with a custom workspace and three pages (all subpages of the same parent). One was unversioned, one had a new version of an element and one was a completely new page version. I changed the access-rights of the parent-page and all subpages, e voilà, only the unversioned page and the parent page changed. The other two were left unchanged, so I suppose that there is a bug in the function to find a perhaps already existing version.
I also checked the database if new versions of the two already versioned page were created, but that's not the case. The new versions were simply untouched, as the original versions were.

Martin, I further investigated this issue and found a solution. I submitted a report and the patch-file under id 3666.

I have just refined the patchfile a bit to make patching easier. Please use 3544_new.patch instead of 3544.patch. (Could one of the admins please delete the old file?)

I will take care of this. However I cannot say if it will be fixed in 4.0.1 because it could lead to troubles which we should test in another RC first. So probably you will have to wait for 4.0.2 to see this fixed.

Too late now for 4.02, but I think this (and some other) workspace issue should be resolved in 4.0.3.

The patch works for me, thanks

Andreas, there was a 2nd change in your patch which contains a hook which I'm not going to use here. Please be aware of that.

Problem still persists in 4.0.3rc1
As already mentioned: After applying patch_new everything's fine

I will post a message on the bugs-mailinglist so hopefully the bug will be fixed in 4.0.4. I'm quite optimistic ;-)

Michael, you are right - the hook was from my patch for 3531. Don't know how it got into this patch here...

Please pay attention! After applying the patch provided by Michael Stucki TYPO3 throwed a DB error (something like: "t3ver_oid not in table")!
When I change the line
$rr = t3lib_BEfunc::getRecord($table,$uid,'pid,t3ver_oid');
to
$rr = t3lib_BEfunc::getRecord($table,$uid);
according to 3544_new.patch
everything works again.
Please consider this before this fix goes into SVN.

has this already been resolved in 4.0.4 now?

What is the problem - the patch works, why isn't this integrated in core ?
Now everyone who works with workspaces has to apply this patch, so please integrate it.

Steffen, did you notice Helmuts comment? He reports that the patch is not working, nobody confirmed, nobody objected.

If we don't get any feedback, then nothing happens...

The attached patch works quite similar to 3544_new.patch except that it doesn't contain a hook which has absolutely nothing to do with the entry here.

I'm gonna commit this into Trunk so you should check out 4.1rc1 to see if it fixes the problem.

- michael

Committed.

Sorry, I forgot: Once the patch has been proven to work in 4.1RC1, it needs to be committed for 4.0.5 as well. So this is still pending...

ok, alright - never had the probs with this, sry.
Anyway i meant the 3544_new.patch

Could you try to get this into the next release of the 4.0-branch? In 4.1 it is already fixed...

I don't think that 4.0 will be maintained any longer. Why don't you just patch your installation? It's everything attached on this page...

The problem is not just my installation... I wrote the patch myself, so I know about the error and the fact that there's a fix available. But many others don't, and this is a really annoying bug you won't expect.

If there are security-critical bugs in 4.0, I think there will be new releases, so it won't hurt to have this bug fixed in 4.0.6 if it ever comes out.

Fixed in TYPO3_4-0, TYPO3_4-1 and Trunk now!