Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Existing labels get overwritten #27

Open
htuscher opened this issue Nov 9, 2015 · 1 comment
Open

Existing labels get overwritten #27

htuscher opened this issue Nov 9, 2015 · 1 comment

Comments

@htuscher
Copy link

htuscher commented Nov 9, 2015

I discovered, that the error handling of DOM objects in PHP is pretty stupid:

If eg. during the buildSourceForXlfFile method an error occurs, the resource pointer of the DOMDocument gets an empty body without any Exception to be thrown.
It's even worse: as prepareDomDocument stores the resourcePointer to the DOMDocument in a local static variable, the LanguageFileService continues working on an empty body and just appends the new labels into it and writes the file afterwards. So the old labels are lost.

So one possible solution is to always re-read the file (bad for I/O) and do some integrity checks, like cloning the DOMDocument and comparing the count of the trans-unit nodes before and after insertion:

        $dom = $this->prepareDomDocument($translationPathAndFilename);
        $initialLanguageNodeCount = $dom->getElementsByTagName('trans-unit')->length;
        $dateNode = $dom->createAttribute('date');
        $dateNode->nodeValue = date('c');
        $dom->getElementsByTagName('file')->item(0)->appendChild($dateNode);
        $body = $dom->getElementsByTagName('body')->item(0);

        $tmpDoc = new \DOMDocument();
        $cloned = $body->cloneNode(TRUE);
        $tmpDoc->appendChild($tmpDoc->importNode($cloned,TRUE));

        foreach ($dom->getElementsByTagName('trans-unit') as $node) {
            if ($node->getAttribute('id') === $identifier) {
                return TRUE;
            }
        }
        $this->createXlfLanguageNode($dom, $body, $identifier);
        $newLanguageNodeCount = $dom->getElementsByTagName('trans-unit')->length;
        if ($newLanguageNodeCount < $initialLanguageNodeCount) {
            /** @var \DOMDocument $initialDom */
            $initialDom = self::$documents[$translationPathAndFilename];
            $xml = $initialDom->saveXml();
        } else {
            $xml = $dom->saveXML();
            self::$documents[$translationPathAndFilename] = $dom;
        }

But I'm not happy with that solution as it looks pretty hacky. Any suggestions on that?

@NamelessCoder
Copy link
Member

I think re-reading the file after writing each label (possibly combined with integrity checks to confirm it actually was written correctly and restoring it if it wasn't) would be the way to go. Don't worry too much about I/O performance on this one - FLLL is explicitly a development-only extension with big warnings attached to using it in production ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants