Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi
after upgrading from D6, the body content is display but when i go on edit mode, i can't modify the body field content because it's empty, disabling editor doesn't change this behaviour.
is someone aware on this ?
thanks
Comments
Comment #1
aiphesdblog give me :
file permissions are 664,but these permissions works for another website,only this one doesn't work among 7 upgraded websites.
Comment #2
TwoDAh, that's a known issue in 7.x-2.2. Please update to 7.x-2.x-dev or enable
allow_url_fopen
in your PHP config.A mistake tries to load a small init script generated by Wysiwyg for TinyMCE over HTTP instead of grabbing it locally, which some installations don't like because of the previously mentioned setting (common on shared hosts). Wysiwyg 7.x-2.x-dev corrects this and opens the file locally instead.
Comment #3
aiphesupdate the module to dev version and still get the error, empty cache doesn't change anything..
Warning : file_get_contents(http://d7-grawitz.vmdev/sites/d7-grawitz.vmdev/media/js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js): failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known dans _locale_parse_js_file() (ligne 1488 dans /var/www/drupal7/includes/locale.inc).
User interface Wysiwyg (wysiwyg) Module Enabled 7.x-2.2+17-dev
Comment #4
TwoDIt's still adding the file to the script list using an absolute URL, when it should look like "public://js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js".
In wysiwyg.module, could you please verify that the function
wysiwyg_load_editor($profile)
(near line 302) contains a line like$uri = 'public://js/wysiwyg/wysiwyg_' . $name . '_' . drupal_hash_base64($init) . '.js';
near line 339?If not, I'm guessing you extracted the -dev snapshot over the existing wysiwyg module installation and wysiwyg.module was not replaced, but wysiwyg.info (containing the version info) was.
Comment #5
aiphesline339 :
i deleted the original folder before downloading and installing the dev version...
info files :
Comment #6
TwoDOk, good. Let's also check the
drupal_add_js()
lines below that.They should be
I just noticed that in this case, the server has not yet tried to actually open the file yet because it's unable resolve the domain, most likely because it isn't accessible over the internet so it's not in any DNS records. The question is why it even tries that...
Have you tried removing the file sites/d7-grawitz.vmdev/media/js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js too? I don't think it will fix it, just want to know it will at least get recreated again.
Btw, are you using any modules which alter the URL or cache files?
Comment #7
aiphesthe module code :
actually the website run on lamp server hosted by w7 virtualbox installation.
i'm not using cache module, and i use pathauto, only this website know this error.this is strange because it's a multisite install, but separate DB and different folder for files storage.
Comment #8
TwoDThat is the correct code.
Are the sites live or can you temporarily modify (or step through with a debugger) the _locale_parse_js_file() function and print out the
$filepath
argument (with devel.module'sdpm($filepath)
or similar so we can have a look at what that function actually gets?I'm only interested in the JS file created by Wysiwyg so you can skip the rest of the files here. You may need to clear the cache for it to actually run.
Comment #9
aiphesi don't know how to do that...i get devel enabled yet.
Comment #10
TwoDOk, once you have downloaded and enabled the Devel module, find the _locale_parse_js_file() function in drupal/includes/locale.inc and insert
dpm($filepath)
just inside it at the top.That will print out the value of that variable as a Drupal message box every time it's being called. If there are many script files to parse for translations it will be called many times, so prepare for a lot of output. Go to a node editing form so we're sure the Wysiwyg scripts will be loaded, clear the Drupal cache in a different browser window, refresh the page. That should trigger a full search for translatable content, and it should come across the init script added by Wysiwyg.
Dig through the output and find the init script and paste the entire file path it printed out for it here.
What I want to know is whether the locale parsing is responsible for turning it into an absolute URL (it shouldn't be), or if the path was already an absolute URL when it got there, which is why we're printing out the value.
You can then remove the line you added in locale.inc so it won't print out this all the time.
Comment #11
aiphesdoing this :
but get in drush :
and error 500 on the page..
Comment #12
TwoDYou're missing a semi-colon after the dpm() call. Sorry I didn't include it earlier.
Also, move it right above the line starting with global. I want to see the values of $filepath before it gets changed by the call to drupal_parse_url().
Comment #13
aiphesok make change but what is a semi-column ?
actually i do:
actually on edit node mode :
Comment #14
TwoDSorry, that was a typo, fixed it above. Your code is already correct.
You should see files starting with
sites/d7-grawitz.vmdev/media/js/wysiwyg/...
in that output after clearing the Drupal cache and navigating to a node edit form. If it looks likehttp://d7-grawitz.vmdev/sites/d7-grawitz.vmdev/media/js/wysiwyg/...
, we've got a problem...Comment #15
aiphesdepending content type node i get informations or not :
in better case (but never on edit mode) =>
on VBO page for example
in worst (in general case of edit mode): nothing appear...
and textfield area is empty..
Comment #16
TwoDThat function is only called when a new script file is to used on the page and thus must be parsed for translation strings, which won't be on every page refresh since it remembers which ones are done until the cache is cleared.
The paths you have there do look correct, I wonder why you keep getting that error...
I'll try to reproduce it on my machine and get back if I find something.
Comment #17
jorisx CreditAttribution: jorisx commentedI'm not sure if this is the right place, but I recently upgraded from 6 to 7 and when I edit the old nodes the body is empty. But in view mode the body is still there. I've no clue why and where to start looking to solve this
I've switched of wysiwyg but the body stays empty whenever i try to edit it...
Comment #18
TwoDSounds like there's an error preventing the editor from reading or writing to the original textarea. Don't save the node when the field is empty or you'll likely lose the content.
Check the browser's developer tools and JavaScript console for errors, with JavaScript optimization disablrd in Drupal or you'll get the wrong filename and line numbers.
Comment #19
jorisx CreditAttribution: jorisx commentedHmm, I've just disabled "content translation" and "local"
now the body of the nodes are empty in view mode?! and when I switch back and just enable "local" the body of the nodes reappear again.
I tested 2 different nodes, one was Language neutral and the other was in Dutch
The "language neutral" one is still empty when i go to edit..
And just looked into 20 other language neutral nodes, and I was able to view the body of those in edit mode?!
Strange...
Comment #20
TwoDIf you disable the Locale and Content translation modules you essentially disable support for having different field values per language, and all other multi-lingual support. Drupal will then default to load the value from the "no/undefined" language (which is why form fields usually have '-und-' as part of their internal names). If there is only a Dutch value stored for the body field, you won't see a value when editing the node using "no" content language. Wysiwyg does not currently care which language is loaded, it just uses whatever is in the textarea when editing a field.
Comment #21
Overflowed CreditAttribution: Overflowed commentedHi all.
I read on top of this thread:
Ah, that's a known issue in 7.x-2.2. Please update to 7.x-2.x-dev or enable allow_url_fopen in your PHP config.
A mistake tries to load a small init script generated by Wysiwyg for TinyMCE over HTTP instead of grabbing it locally,
I'm suffering the same problem:
Warning: file_get_contents(): php_network_getaddresses: getaddrinfo failed: Name or service not known in _locale_parse_js_file() (line 1488 of /data/www/vhosts/drupal_test02/includes/locale.inc).
Warning: file_get_contents(http://test02.domain.com/sites/default/files/js/wysiwyg/wysiwyg_ckeditor...):
failed to open stream: php_network_getaddresses: getaddrinfo failed: Name or service not known
in _locale_parse_js_file() (line 1488 of /data/www/vhosts/drupal_test02/includes/locale.inc).
My frontend server has no Internet access (traffic can't go outside). The sitename URL resolves to a public IP address and I'm not allowed to modify /etc/hosts in the server to add a local resolution for the sitename. So, if the PHP is trying trying to include() the JS file from http://sitename/... instead of public://... is a real problem for me ...
It would be possible to get the bug fixed in the stable version? I don't want to put the development version in a production system and if I patch the code manually I can loose the fix with a future module update.
Thanks.
Comment #22
TwoD@Overflowed, You can apply the patch from #1802394-4: Warning: file_get_contents from 7.x-2.1 to 7.x-2.2 to correct it manually until the next release, which will be based on 7.x-2.x-dev.
I'm closing this issue again since it has drifted away from the original problem.