Forms PHP Plugin: Does access from external files as source of code actually work?

[alastairwalker]

I am running Joomla 3.2.2 using FB 3.1 full release.

My problem relates to the use of files as a source of php code scripts using the form php plugin.

If I place php code in the text area, the code executes fine.

If I place that same code in a file and load it using the PHP file source, it does not work.

I have tried running the supplied 'dump.php' file. When the code script is placed in the text area, the script works correctly. If I try to execute the script using the PHP File source, no data is displayed.

Any advice? Am I missing something really obvious? The Process Script setting in all cases is 'On Before Store'.

Alastair

 

[jfquestiaux]

Have you tried with the "dump.php" and "onAfterProcess".
If that does not work, try to set the joomla error reporting to "maximum" and see if you have any warning or notice.

Maybe there is a access right issue to the "script" directory?

Also, as always with issues, upgrade first to the latest gitHub version and test again.

 

[alastairwalker]

Many thanks for those pointers.

I am running on a WAMP (localhost) (Uniform Server) so the rights issue should not be a problem here.

Regarding changes to objects in Github, is it possible to do a 'changes to object search' to see what objects were changed and when, and the nature of the change?

Maybe I am just unaware of what types of information can be retrieved.

(From a configuration management and change control perspective, I tend to be very cautious in making global changes - unless I am quite sure what the impacts will be.)

Many thanks,

Alastair

 

[cheesegrits]

You can see the full commit history in github, and inspect individual files for their history, and view a "blame" history for individual files (which shows you line by line what the last commit was that affect that line). How to use github is all documented on (surprise surprise) github.

Running PHP from files on the form plugin works fine, it's something I do on a regular basis. As JFQ says, your best bet is to crank error reporting up to maximum, and see if you get anything informative either on the page, or in your error log.

If nothing happens using the dump.php, then it looks like for some reason the file is not being run at all, as it ends in an "exit", and would be very obvious that it is running (you'd get a blank page with just the submitted form data dumped on it).

We can be pretty sure we have the correct path to the file, as we do this before we attempt to run it:

            if (!JFile::exists($php_file))
            {
                throw new RuntimeException('Missing PHP form plugin file');
            }

... so if we had the path wrong, you'd get a runtime error puked up.

The only remaining possibility I can think of is that you have a Windows style file path (using \ and drive letters), and there is some difference between the way J! checks for exists(), and PHP's require(), such that PHP isn't able to find the file. We don't do nearly as much testing of Fabrik on Windows servers as we do U**X,, and we occasionally see issues arising from the directory separator difference.

So you might want to edit the plugin code, ./plugins/fabrik_form/php/php.php, and around line 460 should be this:

// OK, it's a form submit method, so handle it this way
$php_result = $require_once ? require_once $php_file : require $php_file;

Stick a ...

var_dump($php_file);exit;

... in there, to make sure that a) the code is getting that far, and b) sanity check the file path. if the code is getting that far, you could try remov9ing the var_dump and replace it with a line that manually sets the full path in UNIX style, see if that makes any difference.

$php_file = '/full/path/to/script.php';

-- hugh

 

[alastairwalker]

Thank you very much for these detailed comments!

I will run my debugger on the code, now that I know where to look!

I will see what I can come up with.

Alastair

 

[alastairwalker]

Ok - I have had a chance to catchup with this.

The problem seems to be the difference between the Windows character (i.e. \ ) used for separating out folders, and the Unix convention (i.e. /) . The following string is what is trapped by my debugger for the filename:

D:\SPI-LAB\Projects\SCN2\Construction\UniServer\www/plugins/fabrik_form/php/scripts/Actor-Name-Details-iss_de_01_F_01_setup-id-user.php

(from line 417, file php.php, variable $php_file).

Alastair

 

[Bauer]

Just finding the problem was the only problem.

Use the str_replace function to make it right.
e.g. If you stored that path/filename to the variable $filename, just add this line right after...
$filename = str_replace('\','/',$filename);

 

[alastairwalker]

So I guess the way to determine whether a WAMP is being used as the host (instead of a LAMP) is to check whether the file path contains a '\'. If so, then replace all '/' with '\'.

Many thanks for all inputs. I guess we can close this thread.

Alastair

 

[felixkat]

You shouldn't really need to replace '/' with '\'.

Unix only ever accepts '/' whilst windows allows either. For this reason we usually apply '/' wherever possible, otherwise if you migrate from a Windows box to Unix it will break. This also keeps a standard across the code as well, it could well be possible that this may need to be changed in some places not covered yet though.

You would also need to do

$src = str_replace("\\", "/", $src);

note the double slash as the first one needs to be escaped. This is to replace backslash with forward slash.

I use a windows box for development and I don't recall any issues with a PHP form plugin script not being found, so double check this really is the issue.

Another gotcha that I think is with the plugin is that linking to a script is a normal PHP script therefore it will need the

<?php

tag whereas if you are passing into the code box you don't need it. I'm pretty sure this is with the plugin and have got caught out before when copying and pasting to and from each option.

 

[alastairwalker]

Yes - can you believe it!

I confirm that the problem was simply that the '<?php' was missing at the start of the file!

Finally - this thread can be recorded as Closed!

Many thanks for pointing me in the right direction!

Alastair

 

[felixkat]

Ha ha, as I say it always slips me up.

I'll make a note to add to the tooltips, maybe we can add a check on the external file when it's selected on the backend.

 

[Bauer]

You shouldn't really need to replace '/' with '\'.

You would also need to do

$src = str_replace("\\", "/", $src);

note the double slash as the first one needs to be escaped. This is to replace backslash with forward slash.

oops

Anyhow I like threads about 'bugs' that end up being caused by an 'overlook' of some minor detail like this. Glad to know we're all only human - and I'm not the only one plagued with 'silly mistakes'. i.e. Welcome to my world.