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

dblog give me :

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).

file permissions are 664,but these permissions works for another website,only this one doesn't work among 7 upgraded websites.

Status:Active» Closed (fixed)

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, 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.

update 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

Status:Closed (fixed)» Postponed (maintainer needs more info)

It'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.

line339 :

<?php
$uri
= 'public://js/wysiwyg/wysiwyg_' . $name . '_' . drupal_hash_base64($init) . '.js';
?>

i deleted the original folder before downloading and installing the dev version...
info files :

; Information added by drupal.org packaging script on 2013-05-13
version = "7.x-2.2+17-dev"
core = "7.x"
project = "wysiwyg"
datestamp = "1368409370"

Ok, good. Let's also check the drupal_add_js() lines below that.
They should be

<?php
         
if (!$init_exists && !file_unmanaged_save_data($init, $uri, FILE_EXISTS_REPLACE)) {
           
drupal_add_js($init, array('type' => 'inline') + $default_library_options);
          }
          else {
           
drupal_add_js($uri, $default_library_options);
?>

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?

the module code :

<?php
// Check whether the editor requires an initialization script.
     
if (!empty($editor['init callback'])) {
       
$init = $editor['init callback']($editor, $library, $profile);
        if (!empty(
$init)) {
         
// Build a file for each of the editors to hold the init scripts.
          // @todo Aggregate all initialization scripts into one file.
         
$uri = 'public://js/wysiwyg/wysiwyg_' . $name . '_' . drupal_hash_base64($init) . '.js';
         
$init_exists = file_exists($uri);
          if (!
$init_exists) {
           
$js_path = dirname($uri);
           
file_prepare_directory($js_path, FILE_CREATE_DIRECTORY | FILE_MODIFY_PERMISSIONS);
          }
         
// Attempt to create the file, or fall back to an inline script (which
          // will not work in Ajax calls).
         
if (!$init_exists && !file_unmanaged_save_data($init, $uri, FILE_EXISTS_REPLACE)) {
           
drupal_add_js($init, array('type' => 'inline') + $default_library_options);
          }
          else {
           
drupal_add_js($uri, $default_library_options);
          }
        }
      }
?>

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.

That 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's dpm($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.

i don't know how to do that...i get devel enabled yet.

Ok, 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.

Status:Postponed (maintainer needs more info)» Active

doing this :

<?php
function _locale_parse_js_file($filepath) {
  global
$language;
 
// The file path might contain a query string, so make sure we only use the
  // actual file.
 
$parsed_url = drupal_parse_url($filepath);
 
$filepath = $parsed_url['path'];
 
// Load the JavaScript file.
 
$file = file_get_contents($filepath);
 
//debug pb d'editeur apres upgrade D7
dpm($filepath)
?>

but get in drush :
$ drush --uri=http://d7-grawitz.vmdev cc all
PHP Parse error:  syntax error, unexpected T_STRING in /var/www/drupal7/includes/locale.inc on line 1495
Drush command terminated abnormally due to an unrecoverable error.                               [error]
Error: syntax error, unexpected T_STRING in /var/www/drupal7/includes/locale.inc, line 1495

and error 500 on the page..

You'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().

ok make change but what is a semi-column ?

actually i do:

<?php
function _locale_parse_js_file($filepath) {
//debug pb d'editeur apres upgrade D7
dpm($filepath);
  global
$language;
 
// The file path might contain a query string, so make sure we only use the
  // actual file.
 
$parsed_url = drupal_parse_url($filepath);
 
$filepath = $parsed_url['path'];
 
// Load the JavaScript file.
 
$file = file_get_contents($filepath);
?>

actually on edit node mode :

sites/all/modules/galleryformatter/theme/infiniteCarousel.js
sites/all/modules/galleryformatter/theme/galleryformatter.js

Sorry, 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 like http://d7-grawitz.vmdev/sites/d7-grawitz.vmdev/media/js/wysiwyg/..., we've got a problem...

depending content type node i get informations or not :
in better case (but never on edit mode) =>
on VBO page for example

public://js/wysiwyg/wysiwyg_ckeditor_uWMoMQ7qlhtyf-cFJlMTazsAxhCeS88weKBiAtXujAQ.js
sites/all/modules/media/js/wysiwyg-media.js
public://js/wysiwyg/wysiwyg_tinymce_VxxRIlcaFmzHlghU8SsOGCZd5TC_PCxyhQAlqydMALE.js

in worst (in general case of edit mode): nothing appear...
and textfield area is empty..

That 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.

Issue summary:View changes

I'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...

Sounds 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.

Hmm, 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...