Extension talk:PhpTags/Flow

Previous page history was archived for backup purposes at Extension talk:PhpTags/LQT Archive 1 on 2015-06-25.

All demo links to foxway.org site are immediately redirected to a repair shop in Arizona. They should probably all be removed, or the place where they are hosted should be corrected.

~~~~

I am using MediaWiki 1.33

I have installed PhpTags and have this line in my LocalSettings.php:

$wgPhpTagsNamespaces = array( NS_WIDGET => true );

Then on a page (Widget:Grabber) I have this code:

<phptag> echo file_get_contents($_GET['url']); </phptag>

I save the page and view the Widget:Grabber page.

This produces the following error:

PhpTags Fatal error: Extension PhpTags is disabled for the namespace "Widget". in Command line code on line

I think the problem is in $wgPhpTagsNamespaces, but I cannot find any documentation on this wg variable.

maybe NS_WIDGET is not defined when the line `$wgPhpTagsNamespaces = array( NS_WIDGET => true );` is executed by PHP. Is there any error message? try to use 274 instead of NS_WIDGET, or move the line at the end of LocalSettings.php

and file_get_contents function will not work because PhpTags designed to provide safety access to PHP features.

Thanks for the 274 tip. It now says PhpTags Notice: Undefined variable: _GET in Widget:Grabber on line 2

PhpTags Fatal error: Call to undefined function file_get_contents() in Widget:Grabber on line 2 Is this a PHP error or a problem with the Extension?

Upgrading PHP version from 5.6 to 7.0.7 causes something wrong with comparisons.

For example, && and || operators in if block causes run of neither true block nor false, like I haven`t that IF at all.

Also there are some problems with ternary operator - sometimes it doesn`t work.

Rewriting all complex conditions with conjunction, disjunction or ternary to ( () * () != 0), ( () + () != 0) and IF operator solve an issue, and you can make your wiki much faster using PHP 7.0

thanks for the report. I'll test it on PHP 7.0

the issue still seems to be here

Tracked in Phabricator
Task T206296

Is there a feature to save data to a table in the database?

file_get_contents is not supported by PhpTags.

That woud be a security risk, because it could potentially enable web-clients to read web-server system files with passwords, and make any requests from the web-server to maybe intranet or other servers.

That would mean access to a lot of services which are normally trusted only to local connections.

But, How does it allow web-clients to make dangerous operations without password requirement? Why no password requirement?

simple hello-world works fine, but file_get_contents returns

PhpTags Fatal error: Call to undefined function file_get_contents() in Draft:TestPHP on line 2

Here's the sample code:

<phptag>
$foo = 'hello world!';
echo $foo;
</phptag>

<phptag>
$searchResults = file_get_contents('https://www.nature.com/articles/s41467-018-03445-z');
echo $searchResults;
</phptag>

How to enable file_get_contents?

It is not real PHP, it is just faster and powerful alternative for Help:Magic Words

And file_get_contents never should be enabled there by security reason.

thx, what's the security risk?

Read system files with passwords and make any requests from the server to maybe intranet or any other server including itself. A lot of services trust to local connections and allow to make dangerous operations without password requirement.

How does it allow web-clients to make dangerous operations without password requirement? Why no password requirement?

Sorry for the delay, I was hard busy. I meant that some services allows to make dangerous operations for clients who connected to localhost interface (127.0.0.1) because nobody can connect to localhost interface from the internet or other network. But if you provide uncontrolled access to the file_get_contents function, somebody can try to use it to hack your server.

Is there some way to pass a mediawiki template variable to the <phptag> section of code? For that matter, is there a way to have one or more outputs of the php become the result of a template parameter?

For example:

{{Template:TestingPHP

| parameter1 = 99+21

| parameter2 = {{#phptag: $foo = {{{argument1}}}; $bar = explode("+", $foo); echo $bar[1]; }}

}}

Ideally, the value of "parameter2" would become the second element of the $bar array (21), but instead I get a php error. It doesn't seem to like the curly-braces of template parameters.

Apologies if this is a stupid question. I'm still wrapping my head around php.

Hi, You going to use {{{argument1}}} as a PhpTags code, it isn't very nice idea and solution.

As a variant you may get access to argument1 by using special variable $argv for example

{{Template:TestingPHP

| parameter1 = 99+21 | parameter2 = {{#phptag: $foo = $argv['argument1']; $bar = explode("+", $foo); echo $bar[1]; }}

}}

Not sure what you want to do, see transclude example http://test.foxway.org/wiki/PhpTags/Transclude

Hi

I wrote you previously when the extension was foxway. Anyways I was wondering how the extension, and extensions, were going? From the gist that I gather I find the notion of magic expressions to be very interesting. Wondering when you think the extension(s) will be a high enough to be production ready?

On a secondary note, I gather, or think it was implied somewhere, that this series of interconnecting extensions is looking to be a replacement, or a faster version, of semantic mediawiki? Or was my understanding flawed in some way?

All the best to you.

Hi

I think "production ready" is a little vague definition :-)

I see no reason why it cannot be used in production now. Yes, there are the some lacks and most likely hidden bugs (сan be anything without them?), but generally it is ready for trying use in production.

At this moment main subquality are:

• insufficient test coverage of exceptions
• the pages with PhpTags errors are not placing into the category "pages with PhpTags errors"
• inconvenient to edit the source code, I am deciding this problem with Extension:CodeMirror
• it can be used for DDoS attacks, restriction public access to expensive functions can helps
• not all PHP operators are implemented yet
• almost absent PhpTags compatible extensions that really useful for end users

As you can see, it's all just a matter of time and desire to do it. Since it is a open source project, you can help develop it or just wait while others develop it :-) In any case I am open for cooperation.

The first who was going to use this extension is User:JoelKP. I helped him by writing Extension:PhpTags SMW that is used for accessing SMW data. I hope he will come back and write some review...

I do not use this extension yet, because I need a more flexible and fast alternative to semantic mediawiki and I am going to do it with PhpTags. I also have a lot of ideas related to the user interface. Of course, this requires a lot of effort to develop. I still have the desire and ability to develop it and maybe in the end it will be done.

Best of luck.

It sounds great. Wish I could help, but limited time and a lack of trusting my coding skills at the moment is a problem.

I assume, or read somewhere, that the extension can be namespace restricted? But can it execute the code when transincluded? Currently I'm using the following extension for html: Extension:NamespaceHTML. I got the developer to change it so it can be transincluded. This way I treat the template, property (Semantic), namespaces as "developer" namespaces, which I assume I could do with PhpTags (My assumption is that end users really just want to write, upload photos,videos, etc with no html, no wiki-syntax, semantic wiki-syntax or phptags syntax. The closer to FaceBook the happier they are) This would seem to limit the possibility of DDoS attackes, but maybe I'm missing something.

Anyways best of luck to you. I'll be in touch & assuming I end up using the extension I'll throw you whatever little insides I run across.

> I assume, or read somewhere, that the extension can be namespace restricted?
Yes, use variable $wgPhpTagsNamespaces, example: $wgPhpTagsNamespaces = array( NS_DEVELOPER => true ); It will allow to use PhpTags only in NS_DEVELOPER namespace.

> But can it execute the code when transincluded?
Yes of course.

> This would seem to limit the possibility of DDoS attackes...
Yes, you are right, but do not worry, I am sure PhpTags is not the weakest link. There are a lot of ways to create a critical load on the server. PhpTags can only make it a little easier for intruders.

I can help you to resolve any small task, if you would like. I will show you how it can be resolved with PhpTags.

My best wishes to you.

Once again thanks for the info & your work.

One interesting thing I'm looking at phptags for is for calculating ratings. See Extension:Semantic_Rating#Displaying the Result of a Semantic Query as a Five Star Rating. It's one of the things I'm adding to my wiki, but the code suggested in that section seems less then ideal. I think it's one of things that would run far faster with phptags. Any thoughts on this?

All the best to you.

Yes, it does not look very optimized and I'm sure it can work only in theory.

You're right, with phptags it should be much faster.

The easiest way is using Extension:PhpTags SMW make requests to SMW and process the result using Extension:PhpTags Functions and display it using {{#rating: {{#phptag: $result}} }}.

I'll do it quickly if you give me url and access to your wiki. You should install Extension:PhpTags, Extension:PhpTags SMW, Extension:PhpTags Functions and User:Vedmaka/Semantic_Query_Interface.

Of course, ideally, it should work using only PhpTags extensions and I will strive for this, but it takes a lot of time.

I looked today at this more closely and see even more simple solution:

{{#rating: {{#ask:[[Item::<q>[[Author::{{FULLPAGENAME}}]][[Category:Items]]</q>]][[Category:Reviews]]|?Rating|format=average}} }}

I could be wrong, since I can not test it.

it gives incorrect result

Hi

Thanks for even trying. Been swamped or I would have replied sooner. I'm currently redesigning my wiki in the Foreground skin and as soon as I get it under control i"ll be trying out phptags.

All the best to you

> The first who was going to use this extension is User:JoelKP. I helped him by writing Extension:PhpTags SMW that is used for accessing SMW data. I hope he will come back and write some review...

Sorry for the rather late reply.

Only recently have I come to actually take the use of PhpTags further. Earlier, I came no further than testing, and then the wiki project I'm working on was put on hold for some time. Now It's been taken up again, and I'll both be using PhpTags more and doing more development of extensions.

The idea of a "more flexible and fast alternative" to Semantic MediaWiki is interesting, but I'm guessing that it will also take quite a while. Currently I'll be going along a more pragmatic short-term route – getting SMW functionality as flexible as I need it with PhpTags. Best of luck with the alternative approach, and if the work I've begun turns out well, then eventually it may mean that there will be two powerful systems that can be used through PhpTags.

Regarding PhpTags SMW, the approach works well, but Semantic Query Interface (which it uses) needs some work. The basic design ideas for SQI are good, but the implementation is rough. I also want to add a second query interface class (which uses the first as a building block) for recursively following page properties and building a structure (graph representation) of the page relationships. This representation should then be simple to use through PhpTags to e.g. print a hierarchical navigation list for the pages.

SQI also contains some neat things already besides the query interface class. It can be used to set properties on pages. That function will be made accessible in the future PhpTags SMW update.

Having said all that about PhpTags SMW and SQI, here's a brief review of PhpTags itself so far:

• It works.
• It's simple to make an interface available through PhpTags in an extension. The amount of code needed is small.
• While the PHP language support in PhpTags does not include defining functions, it's not too impractical to place things complex enough to need it in an extension. Such extensions could be more general, or could become a wiki-specific code library.

One example of a smaller project I might end up doing (and releasing if of general use) is to write an extension for handling sort keys for pages. PhpTags Wiki can set them, and it's easy to write functions to transform title strings for different kinds of pages.

Finally, thanks for the assistance earlier – you helped get me started.

Hi, Joel! Thanks for feedback :-)

Pay attention to Extension:CodeMirror. I did it for easier writing PhpTags code but I was distracted by highlighting wikitext. The idea is to make the code autocompletion, but I have not reached that goal yet. In any case, it may already be useful and interesting.

And I started experiments with Extension:PhpTags Widgets. You can see Slick.

You are welcome!

I make a set of templates which must have error messages that include text of template call. I understand how this program, but in the absence of user-defined functions I have to make a separate template, where the original argv already unavailable. Is there a built-in function that converts an array (including non-numeric keys) to a string ?

I made all native function of php in phptags functions. If there is no any needed, give me know and I make it :-). That way you may search in google 'what php function convert an array to string' and use example that you find.

You need to use function implode. I'm not sure, can it works with non-numeric keys, but you always can use function array_values and get all values of array with numeric keys only.

If you need to break PhpTags and go out, use 'break' operator:

<phptag>

if ( $foo = null ) {

break; // go out

}

echo '$foo is not null';

</phptag>

'exit' and 'return' still are not ready.

Делаю шаблон, все тело которого — один phptag. Естественное желание — не тащить исключительные ситуации через if/else до конца шаблона, а поставить вслед за echo "ошибка в параметрах" что-то вроде exit или return (меня устроит и вариант прекращения текущего phptag, и вариант завершения шаблона в целом, т. к. для меня это совпадает). Реально?

точно будет работать 'break;' exit и return не реализованы. return и exit можно сделать, но пока их нет

синтаксис не приниципиален, так что break вполне устраивает, спасибо )

это открытый проект? если да, то я могу смотреть время от времени, может что подскажу как лучше делать...

Спасибо огромное! Проект пока еще на локальном сервере, но как только переложу, то непременно Вашу любезность проэксплуатирую ;-)

договорились )

PhpTags until version 5.4.0 had a bag in array constructor.

When array created with variables inside, like $arr = array( $foo, $bar );

only last value was correct, all others was null.

This fixed in version 5.4.0

Павел, добрый день!

Что-то странное у меня получилось: пример.

Да, где-то ошибка в программе. Спасибо, что нашли. Буду искать и исправлять...

Исправлено в версии 5.4.0 (master)

Ошибка была в конструкторе массива, проявлялась только когда массив создавался из переменных.

Указатель не уничтожался и поэтому все время переписывался, таким образом все значения кроме последнего были null.