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

aiphes’s picture

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.

TwoD’s picture

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.

aiphes’s picture

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

TwoD’s picture

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.

aiphes’s picture

line339 :

 $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"
TwoD’s picture

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

          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?

aiphes’s picture

the module code :

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

TwoD’s picture

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.

aiphes’s picture

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

TwoD’s picture

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.

aiphes’s picture

Status: Postponed (maintainer needs more info) » Active

doing this :


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

TwoD’s picture

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

aiphes’s picture

ok make change but what is a semi-column ?

actually i do:

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
TwoD’s picture

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

aiphes’s picture

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

TwoD’s picture

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.

jorisx’s picture

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

TwoD’s picture

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.

jorisx’s picture

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

TwoD’s picture

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

Overflowed’s picture

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

TwoD’s picture

Status: Active » Closed (duplicate)
Related issues: +#1802394: Warning: file_get_contents from 7.x-2.1 to 7.x-2.2

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