Topic on Extension talk:Maps

Problem with maps after upgrade to 1.26

41
EFFemeer (talkcontribs)

I'm getting this

Fatal error: Class 'DataValues\Geo\Parsers\GeoCoordinateParser' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/Geocoders.php on line 131

on maps that used to work properly.

Any idea? Thanks in advance.


Product Version

MediaWiki 1.26.0

PHP 5.3.29 (apache2handler)

MySQL 5.0.95

Semantic Bundle 1.9.2

Semantic Forms 2.8

Semantic Forms Inputs 0.9.0 alpha

Semantic Maps 3.2 

Semantic MediaWiki 2.3


Kghbln (talkcontribs)

Perhaps this has something to do with missing dependencies. You seem to use SemanticBundle. Perhaps this is no longer compatible with MW 1.26. However it is always better to post the versions used not just for MW but also for Maps, PHP etc.

EFFemeer (talkcontribs)

Thanks for the reaction. I've added the version numbers. A pity that my Maps are running in trouble. It worked so well before.

Kghbln (talkcontribs)

I have the impression that you used Semantic Bundle before and now you are trying to use a recent tarball release of SMW together with recent versions of related semantic extensions on top what is still there provided by the Semantic Bundle. This to my regret must fail. If these extensions are composer only like SM you are looking at a lost cause since the tarball release of SMW only works on itself and with non composer software like SF.

FrancisFranck (talkcontribs)

Thank you again. I've now removed the Semantic bundle and was able to get Maps 2.0.1 working again.

Version 3.4 throws Fatal error: Class 'MapsMappingServices' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/services/GoogleMaps3/GoogleMaps3.php on line 100

Kghbln (talkcontribs)

You are not using the file release of SMW (without using Composer) in conjunction with Maps 3.4? Just to make sure.

FrancisFranck (talkcontribs)

Unfortunately, I have no command line access to my server. Hence no means to use Composer (nor Parsoid, nor ...) Due to all the trial and error I had to apply to get things working again, my versions have changed.


Present Version

-----

MediaWiki 1.26.0

PHP 5.3.29 (apache2handler)

MySQL 5.0.95


Semantic Bundle removed

Semantic Forms 3.4

Semantic Forms Inputs 0.9.0 alpha

Semantic Maps removed

Semantic MediaWiki 1.8.0.5

Maps 2.0.1

------

MWJames (talkcontribs)
Kghbln (talkcontribs)

So yes, you were trying to use the file release with other semantic extensions. This was destined to fail. Have you tried using individual file release?

EFFemeer (talkcontribs)
Kghbln (talkcontribs)

Great, some laptop running Linux + composer and an internet connection should work out allrighty for this. Then just move over the files to the webspace.

EFFemeer (talkcontribs)

I'm now trying to run composer under Windows 10. Will that work?

EFFemeer (talkcontribs)

Applied

{

    "require": {

        "mediawiki/semantic-media-wiki": "~2.2"

    }

}

on composer in Windows 10.

Now Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 45

Gosh !!!

MWJames (talkcontribs)
EFFemeer (talkcontribs)

I'd love to believe you MWJames, but the error comes up even before I mw-config starts.

EFFemeer (talkcontribs)

Could it be that this composerstuff doesn't work because I ran it under PHP7 and then copied to a 5.3.29 server?

Otherwise I'll give up my upgrade attempts. It's a waste of time.

MWJames (talkcontribs)

> I'd love to believe you MWJames, but the error comes up even before I mw-config starts.

If you install MW 1.26 and run `Composer update` you should get the `'Psr\Log` package which is required by MW and not by Maps or SMW.

After you run `Composer update` you should be able to add `composer require ...` or since MW screwed with that native Composer setup since MW 1.25 something like composer.local.json [0] can contain non-MW related packages (never used it).

> Could it be that this composerstuff doesn't work because I ran it under PHP7 and then copied to a 5.3.29 server?

No.

Just to clarify this "composerstuff" doesn't have an influence on how SMW or for that matter Maps works. Composer is just a tool that helps us package dependencies you would otherwise have to collect and install yourself in order for classes that depend on each other can work with together as in case of "DataValues" (which is maintained and used by Wikidata and provides functionality to Maps as well).

[0] Composer/For extensions#Specify the extensions to be installed

EFFemeer (talkcontribs)

Question: ready to run Composer update, but which composer.json should I use?

(I have to run Composer on my Windows PC)

Is

{

   

"require": {

       

"mediawiki/maps":"*"

   

}

}

enough?

Or should I use the composer.json file in the root of my wiki?

EFFemeer (talkcontribs)

I've now tried everything: installed Mediawiki 1.26, succeeded mw-config, Composer install, Composer update, but still:

Maps 3.4 issues in

Fatal error: Class 'MapsMappingServices' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/services/GoogleMaps3/GoogleMaps3.php on line 100

---

Maps 2.0.1 says (perhaps understandably because not compatible with SMW > 1.9 - see below)

Fatal error: Class 'ItemParameterManipulation' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/manipulations/Maps_ParamGeoService.php on line 16

---

My present version list:

Installed software

Entry point URLs

Installed skins

Installed extensions

Installed libraries

MWJames (talkcontribs)

>atal error: Class 'MapsMappingServices' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/services/GoogleMaps3/GoogleMaps3.php on line 100

Maps 2.0.1 says

Fatal error: Class 'ItemParameterManipulation' not found in /www/htdocs/drebbel/wiki/extensions/Maps/includes/manipulations/Maps_ParamGeoService.php on line 16

Could it be that your LocalSetting.php file still has a "require_once" reference to the old Maps installation? The message above is an indication that the autloader (the part that registers the classes) can not find the expected file which does exist in [0].

[0] https://github.com/JeroenDeDauw/Maps/blob/6842093fc2d3cd26a41c0ba6ecb62a00f2101696/includes/Maps_MappingServices.php

EFFemeer (talkcontribs)

Thanks for quick reaction! Adapted LocalSettings.php

Now

Fatal error: Uncaught exception 'Exception' with message '/www/htdocs/drebbel/wiki/extensions/Maps/extension.json does not exist!' in /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php:106 Stack trace: #0 /www/htdocs/drebbel/wiki/includes/GlobalFunctions.php(181): ExtensionRegistry->queue('/www/htdocs/dre...') #1 /www/htdocs/drebbel/wiki/LocalSettings.php(170): wfLoadExtension('Maps') #2 /www/htdocs/drebbel/wiki/includes/WebStart.php(123): require_once('/www/htdocs/dre...') #3 /www/htdocs/drebbel/wiki/index.php(38): require('/www/htdocs/dre...') #4 {main} thrown in /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php on line 106

MWJames (talkcontribs)

> wfLoadExtension('Maps')

Maps as well as SMW doesn't use stuff like "wfLoadExtension". Doing something like wfLoadExtension('Maps') will fail because we use the standard composer.json and not some homebrew MW only `extension.json` which cause all sort of issues (including getting extensions to update properly).

EFFemeer (talkcontribs)

If not wfLoadExtension('Maps'), what should I enter in  LocalSettings.php ???

MWJames (talkcontribs)

> f not wfLoadExtension('Maps'), what should I enter in  LocalSettings.php ???

If you added Maps via Composer then Composer has registered all necessary classes and it should work out of the box without having to touch LocalSettings.php or make it explicit (as with those "require_once" or wfLoadExtension stuff).

EFFemeer (talkcontribs)

And this brings me back to Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /www/htdocs/drebbel/wiki/includes/profiler/TransactionProfiler.php on line 36

Could my problem be the same as the one described in https://phabricator.wikimedia.org/T104037? And if so, what next?

BDavis (WMF) (talkcontribs)

@EFFemeer wrote:

Could my problem be the same as the one described in https://phabricator.wikimedia.org/T104037? And if so, what next?

MediaWiki 1.26.0 requires composer-merge-plugin 1.3.0 which includes the bug fix for https://github.com/wikimedia/composer-merge-plugin/issues/41 and T104037. One way to test if there is some sort of regression in generation of the Composer managed classmap autoloader would be to run composer dump-autoload --optimize and see if your class loading problems go away. You could attempt to manually verify that Psr classes are present in the classmap autoloader via grep Psr vendor/composer/autoload_classmap.php.

EFFemeer (talkcontribs)
               

    Thank you for your reaction, Bryan

   

autoload_classmap.php contains...      ... 'Psr\\Log\\LoggerAwareInterface' => $vendorDir . '/psr/log/Psr/Log/LoggerAwareInterface.php',

    'Psr\\Log\\LoggerInterface' => $vendorDir . '/psr/log/Psr/Log/LoggerInterface.php',

    'Psr\\Log\\NullLogger' => $vendorDir . '/psr/log/Psr/Log/NullLogger.php',

    'Psr\\Log\\Test\\DummyTest' => $vendorDir . '/psr/log/Psr/Log/Test/LoggerInterfaceTest.php',

    'Psr\\Log\\ ...   

    and the plugin is definitely loaded.   

    I tried composer dump-autoload --optimize and the outcome is:

   

Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 45

BDavis (WMF) (talkcontribs)

@EFFemeer It sounds like we can rule out composer-merge-plugin generating a corrupt classmap autoloader based on the grep results given above. The problem does sound like it is somehow autoloader related however.

It would be very useful to get a full stack trace that leads to the crash you are seeing. Doing so will probably require hacking your local files a bit since most PHP runtimes won't reliably give stacktraces for fatal errors. You might try sticking a line like throw new Exception('First call to BagOStuff'); at the top of your includes/libs/objectcache/BagOStuff.php file.

EFFemeer (talkcontribs)

I did stick throw new Exception('First call to BagOStuff'); at the top of yourincludes/libs/objectcache/BagOStuff.php file and got Fatal error: Uncaught exception 'Exception' with message 'First call to BagOStuff' in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php:28 Stack trace:

#0 /www/htdocs/drebbel/wiki/includes/AutoLoader.php(90): require()

#1 [internal function]: AutoLoader::autoload('BagOStuff')

#2 /www/htdocs/drebbel/wiki/includes/libs/objectcache/EmptyBagOStuff.php(29): spl_autoload_call('BagOStuff')

#3 /www/htdocs/drebbel/wiki/includes/AutoLoader.php(90): require('/www/htdocs/dre...')

#4 [internal function]: AutoLoader::autoload('EmptyBagOStuff')

#5 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(91): spl_autoload_call('EmptyBagOStuff')

#6 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(78): ExtensionRegistry->__construct()

#7 /www/htdocs/drebbel/wiki/includes/GlobalFunctions.php(218): ExtensionRegistry::getInstance()

#8 /www/htdocs/drebbel/wiki/skins/CologneBlue/CologneBlue.php(4): wfLoadSkin('CologneBlue')

#9 /www/htdocs/drebbel/wiki/LocalSettings.php(121): require_once('/www/htdo in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 28

BDavis (WMF) (talkcontribs)

@EFFemeer your stack trace cuts off just when it was getting interesting. I'd like to see the stack frame just below LocalSettings.php. I would expect it to be something like #10 /www/htdocs/drebbel/wiki/includes/WebStart.php(123): include() but it would be good for you to confirm that.

Having seen this much of the trace, my next question is a sanity check of where your Composer generated autoloader is located. Is it at /www/htdocs/drebbel/wiki/vendor/autoload.php? WebStart.php should be loading $IP/vendor/autoload.php just before $IP/LocalSettings.php which should be how Psr\Log\LoggerAwareInterface is loaded based on our earlier investigations.

EFFemeer (talkcontribs)

Yes, Bryan. Here is another trace, made after some reshuffling in LocalSetting.php:

Fatal error: Uncaught exception 'Exception' with message 'First call to BagOStuff' in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php:28 Stack trace:

#0 /www/htdocs/drebbel/wiki/includes/AutoLoader.php(90): require() 

#1 [internal function]: AutoLoader::autoload('BagOStuff') 

#2 /www/htdocs/drebbel/wiki/includes/libs/objectcache/EmptyBagOStuff.php(29): spl_autoload_call('BagOStuff') 

#3 /www/htdocs/drebbel/wiki/includes/AutoLoader.php(90): require('/www/htdocs/dre...') 

#4 [internal function]: AutoLoader::autoload('EmptyBagOStuff') 

#5 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(91): spl_autoload_call('EmptyBagOStuff') 

#6 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(78): ExtensionRegistry->__construct() 

#7 /www/htdocs/drebbel/wiki/includes/GlobalFunctions.php(181): ExtensionRegistry::getInstance() 

#8 /www/htdocs/drebbel/wiki/LocalSettings.php(375): wfLoadExtension('ConfirmEdit') 

#9 /www/htdocs/drebbel/wiki/includes/WebStart.php(123): require_once('/www/htdocs/dr in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 28

autoload.php is indeed located at /www/htdocs/drebbel/wiki/vendor/autoload.php

One other remark: My first Exception was on wfLoadSkin('CologneBlue'). I then remarked this item out in LocalSettings. Next Exception was another skin, etc.

The final list of Exception-generating items is

---

require_once "$IP/extensions/ConfirmEdit/ConfirmEdit.php";

require_once "$IP/extensions/ConfirmEdit/QuestyCaptcha.php";

$wgCaptchaClass = 'QuestyCaptcha';

wfLoadExtension( 'BetaFeatures' );

#FF wfLoadSkin('CologneBlue');

#FF wfLoadSkin('Modern');

#FF wfLoadSkin('MonoBook');

#FF wfLoadSkin('Vector');

require_once( "$IP/skins/bootstrap/bootstrapskin.php" );

require_once( "$IP/skins/CologneBlue/CologneBlue.php" );

require_once( "$IP/skins/Modern/Modern.php" );

require_once( "$IP/skins/MonoBook/MonoBook.php" );

require_once( "$IP/skins/Vector/Vector.php" );

wfLoadExtension( 'CollapsibleVector' );

## Default skin: you can change the default skin. Use the internal symbolic

## names, ie 'standard', 'nostalgia', 'cologneblue', 'monobook', 'vector':

$wgDefaultSkin = "vector";

wfLoadExtension( 'Gadgets' );

---

BDavis (WMF) (talkcontribs)

Troubleshooting so far:

If these 3 statements are indeed accurate with respect to your server and not just the local development area I'm out of ideas about why the PHP runtime would be unable to find the PSR-3 logging library classes when you load any skins or extensions.

EFFemeer (talkcontribs)
Let me resummarize, cause I've been a little bit confused with the different setups.

My problem shows up at the level of the vendor/autoload.php file and and the vendor/composer directory.

____________

With the files from the Mediawiki 1.26 tarball and

- throw new Exception('First call to BagOStuff'); not included,

wiki starts up well (with well functioning Cologneblue, etc !!!.)

____________

With the files generated by Composer and

- throw new Exception('First call to BagOStuff'); not included,

Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 45

____________

With the files from the Mediawiki 1.26 tarball or the files generated by Composer and

- throw new Exception('First call to BagOStuff'); included,

I always get

Fatal error: Uncaught exception 'Exception' with message 'First call to BagOStuff' in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php:28 Stack trace:

#0 /www/htdocs/drebbel/wiki/includes/AutoLoader.php(90): require()

...

#8 /www/htdocs/drebbel/wiki/skins/CologneBlue/CologneBlue.php(4): wfLoadSkin('CologneBlue')

#9 /www/htdocs/drebbel/wiki/LocalSettings.php(121): require_once('/www/htdo in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 28

____________

When taking out the Exception-generating items from LocalSeettings.php

I'm seeing

#4 [internal function]: AutoLoader::autoload('EmptyBagOStuff')

#5 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(91): spl_autoload_call('EmptyBagOStuff') 

#6 /www/htdocs/drebbel/wiki/includes/registration/ExtensionRegistry.php(78): ExtensionRegistry->__construct() 

#7 /www/htdocs/drebbel/wiki/includes/Setup.php(39): ExtensionRegistry::getInstance() 

#8 /www/htdocs/drebbel/wiki/includes/WebStart.php(137):

So I've got the impression that there is something wrong with the ExtensionProcessor.

Does this shed any light?

PS I've created a log file. Too large to post here. Has several lines like:

[GlobalTitleFail] RequestContext::getTitle called by ContextSource::msg/call_user_func_array/RequestContext::msg/Message::setContext/RequestContext::getTitle with no title set.

BDavis (WMF) (talkcontribs)

With the files generated by Composer: Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found in /www/htdocs/drebbel/wiki/includes/libs/objectcache/BagOStuff.php on line 45

So just to make sure I'm clear, you are only seeing an unexpected error when you replace the $IP/vendor files that come with the 1.26 tarball with a new collection of files that you have generated yourself using Composer? When you do that, are you using the suggested $IP/composer.local.json to augment the default $IP/composer.json or are you modifying $IP/composer.json directly? You checked previously that the generated autoloader scripts had the needed classes but I'm still stuck on the autoloader being the most likely cause of your failure scenario.

EFFemeer (talkcontribs)

Thank you for keeping up with me, Bryan.

Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found

does no longer occur if I do a Composer install with the following composer.json file

__________________

{

"name": "mediawiki/core",

"description": "Free software wiki application developed by the Wikimedia Foundation and others",

"keywords": ["mediawiki", "wiki"],

"homepage": "https://www.mediawiki.org/",

"authors": [

{

"name": "MediaWiki Community",

"homepage": "https://www.mediawiki.org/wiki/Special:Version/Credits"

}

],

"license": "GPL-2.0+",

"support": {

"issues": "https://bugs.mediawiki.org/",

"irc": "irc://irc.freenode.net/mediawiki",

"wiki": "https://www.mediawiki.org/"

},

"require": {

"composer/semver": "1.0.0",

"cssjanus/cssjanus": "1.1.1",

"ext-iconv": "*",

"liuggio/statsd-php-client": "1.0.16",

"oyejorge/less.php": "1.7.0.9",

"mediawiki/at-ease": "1.1.0",

"oojs/oojs-ui": "0.12.12",

"php": ">=5.3.3",

"psr/log": "1.0.0",

"wikimedia/assert": "0.2.2",

"wikimedia/cdb": "1.3.0",

"wikimedia/composer-merge-plugin": "1.3.0",

"wikimedia/ip-set": "1.0.1",

"wikimedia/utfnormal": "1.0.3",

"wikimedia/wrappedstring": "2.0.0",

"zordius/lightncandy": "0.21"

},

"require-dev": {

"jakub-onderka/php-parallel-lint": "0.9",

"justinrainbow/json-schema": "~1.3",

"phpunit/phpunit": "3.7.37",

"mediawiki/mediawiki-codesniffer": "0.3.0",

"wikimedia/avro": "1.7.7",

"nmred/kafka-php": "0.1.4",

"monolog/monolog": "1.14.0"

},

"suggest": {

"ext-fileinfo": "Improved mime magic detection",

"ext-intl": "ICU integration",

"ext-mbstring": "Multibyte string support",

"ext-wikidiff2": "Diff accelerator",

"ext-apc": "Local data and opcode cache",

"monolog/monolog": "Flexible debug logging system",

"nmred/kafka-php": "Send debug log events to kafka",

"pear/mail": "Mail sending support",

"pear/mail_mime": "Mail sending support",

"pear/mail_mime-decode": "Mail sending support",

"wikimedia/avro": "Binary serialization format used with kafka"

},

"autoload": {

"psr-0": {

"ComposerHookHandler": "includes/composer"

}

},

"scripts": {

"lint": "parallel-lint --exclude vendor",

"phpcs": "phpcs -p $PHPCS_ARGS",

"test": [

"composer lint",

"composer phpcs"

],

"pre-update-cmd": "ComposerHookHandler::onPreUpdate",

"pre-install-cmd": "ComposerHookHandler::onPreInstall"

},

"config": {

"prepend-autoloader": false,

"optimize-autoloader": true

},

"extra": {

"merge-plugin": {

"include": [

"composer.local.json"

],

            "merge-dev": false

}

}

}

________________

But as soon as I try to run Composer for the Maps extension,

the Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found reappears.

The autoload.php then reads:

<?php

// autoload.php @generated by Composer

require_once __DIR__ . '/composer' . '/autoload_real.php';

return ComposerAutoloaderInit7ff06b2bb7eddeb261f2acf9f06a570c::getLoader();

BDavis (WMF) (talkcontribs)

Excellent. That's looks to be the default composer.json and would be expected to work.

When you are adding additional Composer packages, there are two possible ways to do it.

  • The recommended way is to create a composer.local.json file with a "require" section describing your additional packages. After you have created the appropriate composer.local.json file, run composer update to download and install your new packages. This method is recommended because it does not involve modifying the composer.json file shipped with MediaWiki which may be overwritten by a future software update.
  • The other possible method is to modify composer.json manually or using composer require package_name_here. The drawback of this method is mentioned above, namely that applying a future MediaWiki update will be very likely to overwrite this file and clobber your changes.
EFFemeer (talkcontribs)

I did exactly what you recommend, and there we go again: Fatal error: Interface 'Psr\Log\LoggerAwareInterface' not found. I then tried a skin Chameleon and Fatal error again.

Hence I think we must conclude that something is wrong with my own system. Which means that I'll never be able to install extensions requiring Composer. Grrr...

The only thing I still can say, is that I have seen that wiki seems to look after Maps.php under the root i.e. /wiki/Maps.php and not under /wiki/extensions/Maps.php.

And now ...? Trying to restart from scratch? Or leaving things as they are and be happy with what we have?

MWJames (talkcontribs)

> And now ...? Trying to restart from scratch? Or leaving things as they are and be happy with what we have?

I'm surely sorry for the trouble you are having and given the possibility that some tool has created an unsustainable installation environment with the new 1.26 release, I made an attempt myself to install MW 1.26 from scratch using Composer exclusively.

The following "new" video [0] shows the whole process (~13 min including the installation of MW, Vector, Maps, and creating an example page to display a Map using annotated properties). Composer is to install:

- Vector skin (~4 min)

- Semantic MediaWiki ~2.3 (~6 min)

- Maps ~3.2 (separate could have been installed by SM) (~9 min)

- Semantic Maps ~2.3 (~10 min)

- Create some sample pages with annotations and display a map (~11 min)

From the video, I was unable to encounter your particular issue. Whether the video is helpful or not, I cannot say.

[0] https://www.youtube.com/watch?v=zY5ugnyq7ig

EFFemeer (talkcontribs)

Very kind of you, MWJames. Unfortunately it doesn't solve my problem. One of the many extensions I have installed somehow seems to undermine the composer install process. My hope is that one of the experts might be able to tell me at which level this happens, so that we can try and repair.

EFFemeer (talkcontribs)

Version 1.26 hasn't changed anything! What next? Try with a skinny LocalSettings file?

EFFemeer (talkcontribs)

Finally arrived at a working configuration. But it was hard to get there! Thanks to all those who helped me out.

Installed software

Entry point URLs

Installed skins

Installed extensions

Installed libraries

Parser extension tags