Opened 3 months ago

Closed 3 months ago

Last modified 3 months ago

#1729 closed defect (fixed)

php 7.1 a php 7.2

Reported by: guest Owned by: gogo
Priority: normal Milestone:
Component: Xinha Core Version: trunk
Severity: blocker Keywords:
Cc:

Description

Upgrading from php 7.1 to php 7.2 the pages where the editor is loaded, appear only as source code.
(this on MAMP development server,
while in the production server there are no anomalies).
Are there any variations of php 7.2 not yet supported by Xinha?
Is it possible to do something?

Change History (9)

comment:1 Changed 3 months ago by gogo

Untested, but sounds like a problem with your server setup/.htaccess file

There is nothing which requires PHP in Xinha itself, only if you use the PHP requiring plugins. Ensure you are using the latest version.

comment:2 Changed 3 months ago by guest

Thanks for your attention.

The problem also occurs by turning off each editor plugin.
But, in fact, the problem only occurs on my local MAMP and only with php 7.2.x, and fortunately not on the production server. With php 7.1.x I do not register any problem, either in local (MAMP 4 or 5), or in production.
Could it be something related to FastCGI mode, which is not configured on the local server?

comment:3 follow-up: Changed 3 months ago by gogo

Almost certainly an issue in .htaccess or your server configuration. Suggest you strip everything down to a minimal test case and examine errors in your web server logs and javascript console.

comment:4 in reply to: ↑ 3 Changed 3 months ago by guest

Replying to gogo:

Almost certainly an issue in .htaccess or your server configuration. Suggest you strip everything down to a minimal test case and examine errors in your web server logs and javascript console.

I think I found the cause, but not yet the solution.

For various reasons (including security) I wanted to customize the Xinha call / configuration by incorporating it into a php file, with the formula:
@header ("Content-type: application / javascript");

(I forgot about this!
However it always worked)

Now, only on my development server (MAMP), and only updating to php 7.2.x, this seems to generate the anomaly described: the page is displayed as a source

Maybe there is some constraint / configuration made by php 7.2 vs. 7.1?
Since I tested with the same server, only changing the loaded php version.

Thanks again for the help!

comment:5 follow-up: Changed 3 months ago by gogo

Without seeing your specific setup myself I don't think I can assist you in this, it sounds like your setup is somewhat unusual.

If you post your simplified test-case code both of the file that sets the Content-type, and the html page which includes that file in it's scripts, then I could maybe see something obvious.

comment:6 in reply to: ↑ 5 Changed 3 months ago by guest

If you post your simplified test-case code both of the file that sets the Content-type, and the html page which includes that file in it's scripts, then I could maybe see something obvious.

page width textarea code

<!doctype html>
<html>

<head>
 <meta charset="utf-8">
 <meta name="viewport" content="width=device-width, initial-scale=1.0">
      
<?php
 require_once('pers_conf_xinha.php');  // custom call xinha
?>
</head>

<body>
<div style = "width:400px; heigh:50px; border:1px solid #000; padding: 5px;" >
<form name="form_article" method="POST" action="" >
  
  <label for="text">text</label>
  <textarea name="text" id="text" cols="30" rows="10">
    text
  </textarea>
  <input type="submit" id="submit" value="insert" />
</form>
</div>
</body>
</html>

pers_conf_xinha.php

<?php @header("Content-type: application/javascript");

?>

<script type = "text/javascript" src = "xinha/XinhaEasy.js">
    
  // OPEN MY CONF  (with or without this)
  
  xinha_options =  { 
     
    // GENERAL 
    _editor_skin:   'none',
    _editor_icons:  'Crystal',
    xinha_editors: 'text',
    
    // LOAD PLUGINS
    xinha_plugins:  [ 'CharacterMap', 'CharCounter', 'CSSDropDowns', 'DynamicCSS', 'FindReplace','GetHtml','HtmlEntities',         
                      'InsertNote', 'InsertAnchor', 'Linker', 'MootoolsFileManager'], 
                      
    
    // etc.
    
       
  } 
  // CLOSE CONF     
         
</script>

comment:7 Changed 3 months ago by guest

Doing some tests I realized that eliminating the line:

@header ("Content-type: application / javascript");

the anomaly would not occur.
But I'm too little competent in the subject to understand why.
However, it works!
(Although I would like to understand why in the server (hosting) of production that same instruction does not give problems.)

Years ago, I had to put that line in the 0.96 configuration to turn XinhaCore?.js into XinhaCore?.php.

Now, if this can be a solution, there is only one other warning I read in the console, but I imagine this is a known and already considered problem somewhere else.

A synchronous XMLHttpRequest request on the main thread is deprecated due to the negative effects on the user experience. For more information see http://xhr.spec.whatwg.org/ XinhaCore?.js: 8248:2

comment:8 Changed 3 months ago by gogo

  • Resolution set to fixed
  • Status changed from new to closed

Yes you should not have that header call there at all, that is incorrect. Remove it is the correct action to take.

The difference will be because with your old PHP the header will likely never have been set (because FastCGI or lack of output buffering or something) and with your new PHP configuration you must be getting set (and it is wrong to do so).

As far as the async request, that is correct, I'll open a ticket to record that and look at removing the synchronous requests in future.

comment:9 Changed 3 months ago by guest

Thank you very much for your support and complete explanations, very useful for me.

On this occasion I sincerely thank everyone who collaborated in the creation of this editor, and for the spirit with which they spread and support. An extremely functional editor - the best -, which gives the opportunity to organize excellent UI even to those who otherwise would not have the competence to do all this on their own.
For my part, with the same spirit, I try to reciprocate by giving my contribution on the subjects of my knowledge, so that the network is an increasingly accessible and resourceful place.

Thanks again!

Note: See TracTickets for help on using tickets.