editing with ipad

Posted: Wed Aug 10, 2011 9:03 am

This will take care of your OS problem without the need for "switches" or other coding.

Code:

if (strstr($sAgent, 'iPad') && strstr($sAgent, 'OS 4')) {


   $advanced_editor = 0;


}

Posted: Wed Aug 10, 2011 3:23 pm

Yes, but we don't know what OS 5 will do. It may remedy the situation, it may not.

I'm perfectly okay with fixing the situation for the current IPADS with OS 4. Either your code or mine will do that. When OS5 comes out we can see whether we need a different fix.

I'm perfectly okay too with just leaving this out of the distribution and publishing the "fix" here and updating the published fix as appropriate. Those who want it can hack their mainfile.

registered · Posted: Wed Aug 10, 2011 7:20 pm

kguske wrote:

Sorry...let's not turn this into a fan boy fight over which platforms are better..

Agreed. Just consider, however, that iOS is here to stay and has a huge market share. I seriously doubt it will disappear. Does one really want to shut out such a huge market base? My company sure doesn't... we have to now consider all major O/S', devices and browsers. It is a huge shift for sure, but it is rapidly upon us all...

I think this ought to crack a little smile... but its not too far from the truth.

http://dilbert.com/strips/comic/2011-08-03/

Posted: Thu Aug 11, 2011 5:06 am

fkelly, in your previous post you said "IOS5 (the fixed version)" so I assumed that is what you meant Wink

Posted: Thu Aug 11, 2011 6:41 am

IOS5 should be the fixed version, but of course we don't know if the problem with editing content in a browser will be fixed until we see it.

Good comic M. Funny but scroll down a bit and you will see that the comic site is being spammed. I don't think it's an issue of us shutting out a huge market base. We need to keep the "difficulty" I reported in this thread in perspective. I "just" affects use of the wysiwyg editor. Many users can use our sites without that. We could create a bigger problem, and I'm sure some sites do, by using Flash. The work Spasticdonkey and Palbin are doing on increasing and standardizing our use of stylesheets is much more important than fixing this issue.

Posted: Thu Aug 11, 2011 7:04 am

I say we disable the editor for ipads now and worry about IOS5 when it is released.

Posted: Thu Aug 11, 2011 7:14 am

Code:

function wysiwyg_textarea

fkelly, is this function from mainfile.php?

palbin, should I replace

Code:

if (strstr($sAgent, 'iPad') && strstr($sAgent, 'OS 4')) { 


   $advanced_editor = 0; 


}

from the code fkelly posted in the mainfile.php?

Please specify where we could do the changes.

Question

Posted: Thu Aug 11, 2011 8:44 am

Yes, the function is from mainfile. I quoted the entire function for ease of anyone who just wants to replace it. Either Palbin's or my version of the if test will work. The usual precautions about modifying a production system apply, back up mainfile first so you can restore it quickly if you make some type of typo error or there are problems on your system. Then I'd test with both an IPAD and a non-IPAD system.

Posted: Fri Aug 12, 2011 6:43 am

Guys,

I recommend not adding the code to this function. There is code within the core modules of RN which look for the $advanced_editor setting to determine whether the data should have htmlspecialchars() applied prior to being placed into a textarea field. It would be better to add code to mainfile.php after the pull in of config.php/rnconfig.php to do the iOS check and change the editor variable.

Posted: Fri Aug 12, 2011 7:15 am

montego wrote:

Guys,

I recommend not adding the code to this function. There is code within the core modules of RN which look for the $advanced_editor setting to determine whether the data should have htmlspecialchars() applied prior to being placed into a textarea field. It would be better to add code to mainfile.php after the pull in of config.php/rnconfig.php to do the iOS check and change the editor variable.

Good call!

Posted: Fri Aug 12, 2011 7:48 am

Oops. Obviously that escaped me in the initial pass at this. I will look further at this in the next few days.

Posted: Fri Aug 12, 2011 12:23 pm

Actually, the only problem with the code I proposed is that we globalize $advanced_editor so that changes in its value are seen outside the function. All we really need to do is create one more variable: $wysiwyg_switch and initialize it to the value of $advanced_editor at the beginning of the function. Then run our tests for user agent and set $wysiwyg_switch to 0 if an IPAD is detected. Then use $wysiwyg_editor in the if statement while leaving $advanced_editor alone. Here's a revised copy of the entire function:

Code:




function wysiwyg_textarea($name, $value, $config = 'NukeUser', $cols = 50, $rows = 10) {


   global $admin, $advanced_editor;


   // Don't waste bandwidth by loading WYSIWYG editor for crawlers


      if ( isset( $_SERVER ) ) {


      $sAgent = $_SERVER['HTTP_USER_AGENT'] ;


   }


   else {


      if ( isset( $HTTP_SERVER_VARS ) ) {


         $sAgent = $HTTP_SERVER_VARS['HTTP_USER_AGENT'] ;


      }


      else {


         $sAgent = $HTTP_USER_AGENT ;


      }


   }


$wysiwyg_switch = $advanced_editor;


if (strstr($sAgent, 'iPad')) {


   $wysiwyg_switch = 0;


}


   if ($wysiwyg_switch == 0 || !isset($_COOKIE)) {


      echo '<textarea name="' . $name . '" cols="' . $cols . '" rows="' . $rows . '">' . $value . '</textarea>';


   } else {


      include_once NUKE_INCLUDE_DIR . 'fckeditor/fckeditor.php';


      $rows = $rows + 2;  // Add extra space for toolbars


      $oFCKeditor = new FCKeditor($name) ;


      $oFCKeditor->BasePath = './includes/fckeditor/' ; // 2.6


      $oFCKheight = $rows * 20;


      $oFCKeditor->Height = $oFCKheight;


      $oFCKeditor->ToolbarSet = $config;


      if (is_admin($admin)) {


         $oFCKeditor->Config['LinkBrowser'] = true;


         $oFCKeditor->Config['ImageBrowser'] = true;


         $oFCKeditor->Config['FlashBrowser'] = true;


         $oFCKeditor->Config['LinkUpload'] = true;


         $oFCKeditor->Config['ImageUpload'] = true;


         $oFCKeditor->Config['FlashUpload'] = true;


      }


      $oFCKeditor->Value = $value;


      $oFCKeditor->Create();


   }


}

Posted: Fri Aug 12, 2011 6:22 pm

But why? Why not just shut off the editor in one fell swoop so that code like the following (and there are others) don't fall over:

admin/modules/settings.php

Code:




   //The following has to be done in order to ensure XHTML compliance when the advanced editor is not being used:


   global $advanced_editor;


   if ($advanced_editor == 0) {


      $foot1 = htmlentities($foot1, ENT_QUOTES);


      $foot2 = htmlentities($foot2, ENT_QUOTES);


      $foot3 = htmlentities($foot3, ENT_QUOTES);


   }


   //End add.


   wysiwyg_textarea('xfoot1', $foot1, 'PHPNukeAdmin', '50', '10');


   echo '</td></tr><tr><td>'


      . _FOOTERLINE2 . ':</td><td>';


   wysiwyg_textarea('xfoot2', $foot2, 'PHPNukeAdmin', '50', '10');


   echo '</td></tr><tr><td>'

It may seem minor, but...

Posted: Sun Aug 14, 2011 3:21 pm

I would think the best spot to do the check would be in the config file because you can never be sure when the editor will be called.

Posted: Sun Aug 14, 2011 4:54 pm

@Montego ... yes but with the revised code I proposed I am not changing the value of the variable $advanced_editor. I am just not calling the fckeditor based wysiwyg texterea box when an IPAD is in use.

@Palbin ... yes, you can never be sure when the editor will be called. But if you look at the function wysiwyg_textarea() in mainfile ... are programs duplicating all that logic to go out to the includes directory and load up fckeditor? I think not. They are just calling wysiwyg_textarea(). So, if we have the correct logic in the mainfile function we fix it for everything else. No?

In fact, if we do what you are suggesting, Palbin, and change $advanced_editor in the config file then we create exactly the errors M. is warning about. No?

Posted: Sun Aug 14, 2011 6:15 pm

fkelly, your code is going to cause the error that montego is pointing out. If you are not going to load the editor then you must apply htmlentities() or htmlspecialchars(). Which is being done by this snippet of code:

Code:




   if ($advanced_editor == 0) {


      $foot1 = htmlentities($foot1, ENT_QUOTES);


      $foot2 = htmlentities($foot2, ENT_QUOTES);


      $foot3 = htmlentities($foot3, ENT_QUOTES);


   }

Under your scenario this snippet of code is not run and we would be dumping raw html in the textarea.

Posted: Sun Aug 14, 2011 6:38 pm

But I am not changing the value of $advanced_editor. That was the point of adding a second variable $wysiwyg_switch that was strictly "internal" to the function.

Posted: Wed Aug 17, 2011 6:35 am

fkelly wrote:

But I am not changing the value of $advanced_editor.

And that is our point. We don't think the function itself should change but instead the editor switch be shut off so that code already in place which is expecting that switch to mean editor vs. no editor in use goes about its business unharmed.

Posted: Wed Aug 17, 2011 8:12 am

Not sure how I missed the reply. Thanks montego.

Posted: Thu Aug 18, 2011 6:23 am

I concede. Smile

I surrender. I looked at your (Montego) coding example and once again you are right. Sigh. In fact, I think I just ran into a problem on my own site using my code ... it's in with deny user.

The fix for this will have to go in rnconfig. We will have to give some thought to the comments that will accompany it. We don't know if Apple will fix the problem in subsequent releases or not and their releases will post-date our next release of RN 2.5. Plus I have some question about whether we want non-administrative users editing content in the non-wyiswyg text areas. We could wind up with a lot of non-compliant content that way.

I will get back to it, I am up to my neck in other alligators right now.

Posted: Sat Aug 20, 2011 7:50 am

I think rnconfig.php should stay as much a configuration file as possible. I suggest instead putting the code as soon after the config files are loaded as possible within mainfile.php.

Posted: Wed Oct 12, 2011 3:55 pm

I had sort of "deep-sixed" this issue. I had a fix running on my web site that may have caused some compliance errors in border cases and I also had given up trying to administer my site using the IPAD at all. I clobbered a whole message once using the IPAD and said: "enough is enough". There is no doubt a solution that would fix the problem while not causing compliance issues: I just had other priorities plus I wanted to see if IOS 5 would resolve it.

So, after wrestling with the IOS 5 update all day (the Apple servers are swamped and issue all sorts of spurious error messages and troubleshooting recommendations) I got it to run. First thing after installing IOS 5 and restoring my apps I went to see if the WYSIWYG editor would work. It appears to. So, if you are trying to use an IPAD to administer a RN web site, even if just while traveling or sitting in the living room watching TV, I'd recommend the update.

I'd wait a week or two until the Apple servers settle down. I had the need to do it today since I am off traveling tomorrow and won't be carrying my big clunky laptop with me.