Can't save page when textareaLanguage field (using TinyMCE) contains link or image

[neildaemond]

If I try to add a link or image into any part of a the 'default' box in a textareaLanguage field I get the following error when trying to save the page:

Error: Call to a member function getLanguageValue() on a non-object (line 363 of /var/www/ctw/wire/modules/LanguageSupport/LanguageSupportFields.module)
 

I've just recently changed a few textarea fields into textareaLanguage fields, then changed their options to use TinyMCE. I also have Page Link Abstractor enabled under the "Convert root URLs and page URLs: Prevents broken links when linked pages are moved" mode.

I think I've used this same configuration before without a problem.... Does anyone know how to rectify this?

Thanks,

[neildaemond]

uhm.. okay, I dont' know what I did (I really didn't do much except for more diagnostic testing), but it just started working.

Edit:  Nevermind, it doesn't work when adding links/images to the 'default' box/field... works under the alternate language box/field

[neildaemond]

It seems that there may be an issue with using Page Link Abstracter module with TextAreaLanguage.

Whether I'm using a rich-text editor (i tried both TinyMCE and CKEditor) or plaintext field which contains a link or image, the above error msg in OP is shown and the page doesn't save.

This only applied to the 'default' language, as I was able to save links and images in the language specific sections.

After disabling the Page Link Abstracter for the field in question, there were no more errors.

Unfortunately, I’m building my page under a sub-directory so being able to use page link abstracter will be nice.

[Soma]

Page link abstractor doesn't work with language text fields.

[ryan]

I didn't realize before that PageLinkAbstractor doesn't work in this scenario, so will have to put some time into correcting that. But for now I think the best bet is to just search/replace your DB dump when migrating it from dev to live (and this is what I do regardless). 

[neildaemond]

Thanks for the responses and good Idea Ryan, I'll try that if I have those kind of migration issues. I ended up upgrading my staging and dev server settings so that I don't need to work on sub-directories. It was a change I had been wanting to make

with virtual hosts on my staging server, the urls now look like "cilentname.mydomain.com" instead of "mydomain.com/clientname/"

For development within my own network, I updated my dev machine's /etc/resolve.conf so that the url "clientname" will resolve to the dev server ip. Again, setting up virtual hosts on my dev machine.

I feel much more confident adding links into content with the new setup and don't feel obligated to rely on pageLinkAbstractor too much

[valan]

+1. I'd also impatiently wait when Page Link Abstracter will marry TextAreaLanguage. Currently admins running multi-language sites have to do double work, updating changed links and it is not something admins like to do ))