Jump to content

getLanguageValue($lang); gives me complete <HTML>


Soma
 Share

Recommended Posts

I have a module that hooks after into Pages::save. I then read text from the page (multilanguage) to save to another page's text field.

So using the getLanguageValue() like this:

$text = $page->body->getLanguageValue($lang);
$otherpage->setLanguageValue($lang,$text);

The body is a textarea TinyMCE field with HTML option turned on, and the target field just a textarea field.

However the text is save to the field but in a strange format like:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><h2>Kontrolleure, Polizei & Video</h2><p>Auch für VPT-Zentralpräsident Kurt Nussbaumer ist Videoüberwachung «in der heutigen Zeit das einzige Mittel, um Gewalttaten, Aggressionen und Vandalismus einzudämmen. Parallel dazu muss aber die Bahnpolizei regelmässig eingesetzt werden.» Vor allem in Problemzügen sei eine verstärkte Polizeipräsenz unerlässlich, d...
 

How does this come to be?

Edit: I'm going crazy with this! Something that should take me a couple minutes is going to take me again hours...

As you see, also the umlaute are converted. I tried workaround this with strip tag and I did tried a html_entity_decode(), but as soon as I run it I get logged out (!) after it gets to the first ü.... wtf. Anybody have an idea what is happening?

Even after trying this I get just logged out!

$table = get_html_translation_table(HTML_ENTITIES);
$rev_trans = array_flip($table);
$complete_text = strtr($complete_text,$rev_trans);

How can this be?

Link to comment
Share on other sites

I now tried changing the hook to hook after Pages::saveReady instead of Pages::save

and you know what, it solves the <HTML> tags and Umlaute problem...(!?)

I'm not understanding how this could make a difference. I think I've run into a similar strange issue when using Pages::save that when switching to Pages::saveReady solved it. Ryan?

This is the complete code:

$this->addHookAfter("Pages::saveReady", $this, "hookAbsatzPageSave");

And the Method:

protected function hookAbsatzPageSave(HookEvent $event) {

    // saved page
    $page = $event->arguments("page");

    if($page->template->name != "absatz") return;

    $parent = $page->parent();
    $allchilds = $parent->children();
    $lang_save = $this->user->language;
        
    foreach( $allchilds as $absatz ){
        foreach($this->languages as $lang) {
            $this->user->language = $lang;
            $parent->absatz_text_index = '';
            $body = preg_replace('#<[^>]+>#', ' ', $absatz->body);
            $parent->absatz_text_index .= trim($body);
            $boxtext = preg_replace('#<[^>]+>#', ' ', $absatz->boxtext);
            $parent->absatz_text_index .= " " . trim($boxtext);
        }
    }
    $this->user->language = $lang_save;
    $this->pages->save($parent, array('quiet' => true));
    
}

Ignore the logic and quality of what I do here, it's just a workaround to get text from child pages to a parent page for easier searching pages.

----

BTW: Also wanted to note that I noticed when using TinyMCE and saving page without changing anything in the text it still throws message that body has been changed. Not sure what's about it and I think it is just confusing and has nothing to do with this I experience here.

Link to comment
Share on other sites

BTW: Also wanted to note that I noticed when using TinyMCE and saving page without changing anything in the text it still throws message that body has been changed. Not sure what's about it and I think it is just confusing and has nothing to do with this I experience here.

Experience the same over here with CKEditer (at least some dev versions ago). Looks like some js voodoo hits the contents and the purifier changes it back when saving. This results in some kind of vicious circle.

Can test tomorrow.

  • Like 1
Link to comment
Share on other sites

I removed it meanwhile, as I think I understood it wrong, but doesn't make any difference at all.

I just can't to get the page getting saved anymore when using addHookBefore("Pages::save",...) or addHookAfter("Pages::saveReady"...) , although the session says yx fields have changed and page is saved, but actually nothing gets saved.

Link to comment
Share on other sites

Thanks Wanze, not it's not. 

I somehow located the issue why the "absatz" page that triggers the hook doesn't save and its because of when I save the parent...

$this->pages->save($parent);

I tried all variations and no luck, as soon as I remove it the page I modify saves correct again. As soon as I add the $parent->save(); it doesn't save anything anymore to the page I'm editing.

Link to comment
Share on other sites

Soma, I'm not sure I follow everything here and agree it all sounds pretty odd. First things first, I think it'd be good to figure out where the HTML4 document is coming from. The only thing I can guess is TinyMCE is saving it this way, and you are just discovering it as a result of this debugging session? It almost looks to me like the HTML contents of TinyMCE's iframe window. If you still don't know where this is coming from, then I think we need to focus in on that cause it seems really odd (PW does not generate any HTML documents like that). What other modules are installed and running? Is it possible it's being added by some mod_security type Apache module (automatically adding an <html> wrapper around content it sees as HTML in a POST request?)

  • Like 1
Link to comment
Share on other sites

This is the current code:

protected function hookAbsatzPageSave(HookEvent $event) {

    // saved page
    $page = $event->arguments("page");

    // only for pages with "absatz" template
    if($page->template->name != "absatz") return;

    $parent = $page->parent();
    // to make sure setLanguageValue is working when saving page on front-end
    $parent->of(false); 
    $allchilds = $parent->children();
    
    // loop each language
    foreach($this->languages as $lang) {
        
        // start empty for this language
        $parent->absatz_text_index->setLanguageValue($lang, "");
        $new_text = '';
        
        // loop all children and collect texts for this language
        foreach( $allchilds as $absatz ){

            $absatz->of(false);

            $body = preg_replace('#<[^>]+>#', ' ', $absatz->body->getLanguageValue($lang));
            $new_text .= trim($body);

            $boxtext = preg_replace('#<[^>]+>#', ' ', $absatz->boxtext->getLanguageValue($lang));
            $new_text .= " " . trim($boxtext);

        }
        // save the text to the on parent page for the language
        $parent->absatz_text_index->setLanguageValue($lang, $new_text);
    }

    $this->pages->save($parent,array("quiet" => true));
}

@martijn no it's all correct, just loop all child pages and collect them and save the text to the parent. The text on the parent is saved correctly.

Edit: I think I got some fault you might was right, but corrected now, just am changing stuff forth and back, sorry. But It has nothing to do with the odd things I'm having.

  • Like 1
Link to comment
Share on other sites

Soma, I'm not sure I follow everything here and agree it all sounds pretty odd. First things first, I think it'd be good to figure out where the HTML4 document is coming from. The only thing I can guess is TinyMCE is saving it this way, and you are just discovering it as a result of this debugging session? It almost looks to me like the HTML contents of TinyMCE's iframe window. If you still don't know where this is coming from, then I think we need to focus in on that cause it seems really odd (PW does not generate any HTML documents like that). What other modules are installed and running? Is it possible it's being added by some mod_security type Apache module (automatically adding an <html> wrapper around content it sees as HTML in a POST request?)

Thanks Ryan for stepping in.

I'm not sure it has to do with the server. The <html..> I'm getting is loaded from the "absatz" pages AFTER saving. And in DB it's not there.

As soon as I change the hook to Pages::saveReady the <html..> wrap isn't there anymore. I also thought is has to do with the TinyMCE but not sure. It get's even more odd that when I add the string to the $this->message() it actually isn't there! Crazy.

It's soo strange as I'm loading the body from the saved page and not from a POST or anything. But I'm not sure what I can do to find out. Really strange thing with getting logged out when using html_entity_decode. So I also thought some security thing is happening. But I'll have to ask the server support to make sure.

After all, I would have get it working, it's just now that the "absatz" page I'm editing isn't saved anymore as soon as I use Pages::saveReady and $parent->save(). Kinda a lock I'm in.

Link to comment
Share on other sites

Some heureka.

Ok I know now where the <html> is coming from. I got a LinkAbstractor module I coded that replaced some things on loading-saving... 

$this->addHookBefore("FieldtypeTextareaLanguage::sleepValue", $this, "hookSleepValue");
$this->addHookAfter("FieldtypeTextareaLanguage::wakeupValue", $this, "hookWakeupValue");
 
In there I got some function to replaceDocumentIdsWithUrl()
$doc = new DOMDocument();
$doc->formatOutput = false;
$doc->preserveWhiteSpace = false;
$us_ascii = mb_convert_encoding($str, 'HTML-ENTITIES', "UTF-8");
$doc->encoding = 'UTF-8'; // insert proper
@$doc->loadHTML($us_ascii);
...
return $doc->saveHTML();

But not sure how to prevent that. But will try around.

Still the non-saving of the page i'm editing persists even when I turn off the LinkAbstractor and use addHookAfter and Pages::saveReady. As soon as I save the $parent. When I remove the $parent->save() it works, but I need to save the $parent as that's all what it is about. :/

Anyway I now will use Pages::save.

Link to comment
Share on other sites

Soma, glad you found the source of the HTML document. Regarding the saveReady, I think it may be problematic to try and save a page in there because it's going recursive. Calling a save() from saveReady triggers another save and thus another saveReady, and so on. I don't yet know why its working with some hooks and not others, but wanted to point out the potential for an infinite loop there. When recursion is involved sometimes things can get weird, or at least hard to debug. If it's possible to move it all to a saved() hook, that may be less prone to issues. While there would still be recursion there, at least it wouldn't interfere with the save order. Technically what you are trying to do should be possible by preventing an infinite loop from within your hook (which I think your template check is doing), but this is one of those scenarios that may require more abstract jumps and debugging than is worth the effort, at least if you can accomplish it in any simpler fashion.  

  • Like 1
Link to comment
Share on other sites

Thanks Ryan for the note, I'm very well aware of the possible recursion as I've done quite a lot of those save hooks for various things. I'm using a $pags->skip = true or a $page->save("field") to prevent it usually. Anyway it's not a problem or the problem here.

I stick with the addHookAfter Pages::save, as that's the only one that works correct as you said I also have no idea why saving parent in the hook when using  the Pages::saveReady fails to save the page I'm editing. But I noticed a similar behavior already with those two, just the opposite, where Pages::saveReady wouldn't work but a Pages::save would. So something going on that's not consistent across hooks that maybe should, I'm not sure as I don't see all behind it as you might could.

It's just that those things makes me wonder what really happened and leaves me in a dark room with a strange feeling.

I'm not sure what else I can do or say so you can maybe reproduce it. It's something I think "should" work and is nothing very special. Let me know if I can help if you can't reproduce the not-saving issue.

Link to comment
Share on other sites

$parent->absatz_text_index is reset in every loop to an empty string.

So it only contains value from the $allchilds->last(), last sibling from $page.

I finally tested the code again with multiple child pages and corrected what you mentioned, there was some logic error in there. :)

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...