Implemented XF2: Please add method XF\Service\Post\Editor::setPerformValidations

[Steffen]

The class XF/Service/Thread/Editor has a method setPerformValidations. I think XF\Service\Post\Editor should have such a method, too. It should be used to skip the PostPreparer validation called by XF\Service\Post\Editor::setMessage, just like the ThreadEditor does.

Reasoning: I'm using the XenForo API to programmatically create and update threads (and their first post). When I initialize XenForo using \XF::setupApp('XF\App'); and call XF\Service\Post\Editor::setMessage I get an error: "[LogicException] The router key must be overridden." I think that's because the PostEditor service currently does not allow skipping the PostPreparer validation.

Workaround: I could initialize my CLI app using \XF::setupApp('XF\Pub\App');. But I guess the Pub app is only meant to be used when handling a web request, or is this a misunderstanding and I should even use the Pub app in CLI mode?

Code to reproduce the issue (assumes that a post with ID 1 exists):

<?php
$dir = __DIR__;
require $dir . '/src/XF.php';

\XF::start($dir);
$app = \XF::setupApp('XF\App');
$app->setup();

$finder = $app->em()->getFinder('XF:Post');
$finder->where('post_id', 1);
$post = $finder->fetchOne();

$postEditor = $app->service('XF:Post\Editor', $post);
$postEditor->setMessage('A message ...');
$postEditor->save();

 

[Mike]

This was a small thing, but just needed a chance to get around to it, so I've added this to Post\Editor now.

The error you're getting is probably not related though. If you're still getting it (I'm aware it was a month ago), then the full stack trace for it would be helpful to determine if it's something we're anticipating.

 

[Steffen]

Thank you for adding the suggested method to Post\Editor!

Using XenForo 2.0 Beta 6 and the script posted above, I'm still getting the mentioned error. Here is the stack trace:

An exception occurred: [LogicException] The router key must be overridden. in src/XF/App.php on line 269
#0 src/XF/Container.php(28): XF\App->XF\{closure}(Object(XF\Container))
#1 src/XF/App.php(1974): XF\Container->offsetGet('router')
#2 src/XF/Template/Templater.php(220): XF\App->router()
#3 src/XF/App.php(1376): XF\Template\Templater->__construct(Object(XF\App), Object(XF\Language), '/data/www/pics....')
#4 src/XF/App.php(1049): XF\App->setupTemplaterObject(Object(XF\Container), 'XF\\Template\\Tem...')
#5 src/XF/Container.php(28): XF\App->XF\{closure}(Object(XF\Container))
#6 src/XF/App.php(2592): XF\Container->offsetGet('templater')
#7 src/XF/BbCode/Renderer/Html.php(1006): XF\App->templater()
#8 src/XF/SubContainer/BbCode.php(49): XF\BbCode\Renderer\Html::factory(Object(XF\App))
#9 src/XF/Container.php(228): XF\SubContainer\BbCode->XF\SubContainer\{closure}('XF:SimpleHtml', Array, Object(XF\Container))
#10 src/XF/SubContainer/BbCode.php(136): XF\Container->create('renderer', 'simpleHtml')
#11 src/XF/Service/Message/Preparer.php(238): XF\SubContainer\BbCode->renderer('simpleHtml')
#12 src/XF/Service/Message/Preparer.php(104): XF\Service\Message\Preparer->checkValidity('A message ...')
#13 src/XF/Service/Post/Preparer.php(98): XF\Service\Message\Preparer->prepare('A message ...', true)
#14 src/XF/Service/Post/Editor.php(96): XF\Service\Post\Preparer->setMessage('A message ...', true)
#15 test.php(14): XF\Service\Post\Editor->setMessage('A message ...')
#16 {main}

 

[Chris D]

It seems you're originating this code from a file called test.php so presumably a separate file with which you're instantiating the XF framework yourself.

That's fine and perfectly valid, but XF has a few different contexts, or app types. There's obviously public, admin then there's install and even cli. These all have their own App object which extends the default XF\App class. It's also possible to instantiate just the XF\App class on its own, which is sort of valid, but as we have many functions which are type specific, you may see errors like this.

Solution is likely simple.

Whereas you may just be starting the framework like this right now:

$dir = __DIR__;
require ($dir . '/src/XF.php');

XF::start($dir);

$app = \XF::app();

You'd instead just do this:

$dir = __DIR__;
require ($dir . '/src/XF.php');

XF::start($dir);

$app = XF::setupApp('XF\Pub\App');

 

[Steffen]

Thank you for the reply.

Using 'XF\Pub\App' instead of 'XF\App' is what I described as a "workaround" in the first post. If it is not a workaround but totally fine to use 'XF\Pub\App' in CLI mode then everything is fine. (I thought that using 'XF\Pub\App' was only appropriate when serving actual user requests.)

 

[Mike]

Nope, not a workaround -- totally fine. Note that there's an XF\Cli\App class as well.