Plugin Authors: Changes for 6.1 release


limetech

Recommended Posts

fixed it with the following:

 

<form name="app_install" method="POST" action="/update.htm" target="progressFrame">

<input type="hidden" name="cmd" value="/plugins/<?=$appname;?>/scripts/rc.<?=$appname;?>"/>

<input type="hidden" name="arg1" value="install"/>

<input <?=$app_disabled;?> type="submit" id="STDSMBUTTON" value="Install"/>

</form>

 

apparently, the arguments must come as a separate input value and can't be appended onto the command value.  Crappy, because this method may completely break unraid 5 functionality.

Link to comment

I seemed to perhaps run into another small problem. On Unraid 6.1 I am not able to pass more than 9 arguments from PHP to the RC file.

 

The arguments are named arg1, arg2...arg9,arg10...

 

I think when it hits arg10 it is being picked up as arg1 again.  It's possible that there is something I'm not aware of preventing the rest of the values from being passed.  Do you have any suggestions, or have you come across this before?

Link to comment

I seemed to perhaps run into another small problem. On Unraid 6.1 I am not able to pass more than 9 arguments from PHP to the RC file.

 

The arguments are named arg1, arg2...arg9,arg10...

 

I think when it hits arg10 it is being picked up as arg1 again.  It's possible that there is something I'm not aware of preventing the rest of the values from being passed.  Do you have any suggestions, or have you come across this before?

 

Nothing in webGui uses more than 1 or 2 args and I set the limit to 10.  "10 args aught to be enough for anyone" - apparently not, this will require a new release.

Link to comment

I seemed to perhaps run into another small problem. On Unraid 6.1 I am not able to pass more than 9 arguments from PHP to the RC file.

 

The arguments are named arg1, arg2...arg9,arg10...

 

I think when it hits arg10 it is being picked up as arg1 again.  It's possible that there is something I'm not aware of preventing the rest of the values from being passed.  Do you have any suggestions, or have you come across this before?

You might be able to reduce those args by either using update.php and #file to save config settings or converting some of the bash script to use php instead. All I use now is a start and stop script.

Link to comment

I've encoded them down to one argument sent from the PHP file and in the RC file is decodes the argument back into all the pieces.

 

Maybe it is good to know that Dynamix has built-in support for reading and saving settings.

 

For reading the settings, you can use the function "parse_plugin_cfg" at the beginning of the page, like this:

$cfg = parse_plugin_cfg("plexconnect");

This will store all settings in the array $cfg.

 

Next you need to include the #file parameter in the form field, for example

<form markdown="1" method="POST" action="/update.php" target="progressFrame">
<input type="hidden" name="#file" value="plexconnect/plexconnect.cfg">

Parameter Depth description:
: <input type="text" name="depth" value="<?=$cfg['depth']?>"/>
...
more parameter fields
...
 
: <input type="submit" name="#apply" value="Apply"><input type="button" value="Done" onclick="done()">
</form>

 

Link to comment

just to clarify - a few questions:

 

* Can I run shell_exec() on system utilities without using a wrapper script ?

* Can I run commands in /usr/local/sbin using shell_exec() without a wrapper script ?

* What would be the best practice to keep plugin compatibility for unRAID 6.0 and prior?

 

Link to comment

 

 

just to clarify - a few questions:

 

* Can I run shell_exec() on system utilities without using a wrapper script ?

* Can I run commands in /usr/local/sbin using shell_exec() without a wrapper script ?

* What would be the best practice to keep plugin compatibility for unRAID 6.0 and prior?

 

You can run shell_exec() within the page. The wrapper scripts are for POST/GET situations.

Link to comment

 

 

just to clarify - a few questions:

 

* Can I run shell_exec() on system utilities without using a wrapper script ?

* Can I run commands in /usr/local/sbin using shell_exec() without a wrapper script ?

* What would be the best practice to keep plugin compatibility for unRAID 6.0 and prior?

 

You can run shell_exec() within the page. The wrapper scripts are for POST/GET situations.

 

So in exec() and exec_shell() I can run any command from any folder? not limited to the plugin folder?

 

 

Link to comment

 

 

just to clarify - a few questions:

 

* Can I run shell_exec() on system utilities without using a wrapper script ?

* Can I run commands in /usr/local/sbin using shell_exec() without a wrapper script ?

* What would be the best practice to keep plugin compatibility for unRAID 6.0 and prior?

 

You can run shell_exec() within the page. The wrapper scripts are for POST/GET situations.

 

So in exec() and exec_shell() I can run any command from any folder? not limited to the plugin folder?

Yeah commands through php like this will still work. Just POST commands like from a form have to be wrapped.

$apache_version = shell_exec( "/usr/sbin/httpd -v | grep version | sed -e 's/^Server version: Apache\///'" );

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.