App for Cloudflare® Pro 1.8.9

[basenotes]

Hiya

I'm using this for both Wordpress and Xenforo, and have no issues with it in the main.

However, I've a bit of code I'm using in Wordpress to get the current user from Xenforo, so that I can show various items depending on usergroups

Basically along this lines

$fileDir = $_SERVER['DOCUMENT_ROOT'].'/community';  # relative path from this script to the Xenforo root
require($fileDir . '/src/XF.php');
XF::start($fileDir);
$app = XF::setupApp('XF\Pub\App');
$app->start();
$xfuser=XF::visitor();

This all works fine in my test site, but when I try it on my live site, which has the Cloudflare plug-in installed, I get an error. When I temporarily disable the Cloudflare plug-in it works fine.

It's probably my shoddy code attempting to hack WP and XF together, but here's the error I get:

An exception occurred: [ArgumentCountError] Too few arguments to function XF\Mvc\Entity\Repository::__construct(), 0 passed in /home/redacted/public/wp-content/plugins/app-for-cf/src/DigitalPoint/Cloudflare/Base/Pub.php on line 176 and exactly 2 expected in src/XF/Mvc/Entity/Repository.php on line 14

1. **XF\Mvc\Entity\Repository->__construct()** in **/home/redacted/public/wp-content/plugins/app-for-cf/src/DigitalPoint/Cloudflare/Base/Pub.php** at line **176**
2. **DigitalPoint\Cloudflare\Base\Pub::handleHeaders()** in **/home/redacted/public/wp-includes/class-wp-hook.php** at line **326**
3. **WP_Hook->apply_filters()** in **/home/redacted/public/wp-includes/plugin.php** at line **205**
4. **apply_filters()** in **/home/redacted/public/wp-includes/class-wp.php** at line **558**
5. **WP->send_headers()** in **/home/redacted/public/wp-includes/class-wp.php** at line **821**
6. **WP->main()** in **/home/redacted/public/wp-includes/functions.php** at line **1336**
7. **wp()** in **/home/redacted/public/wp-blog-header.php** at line **16**
8. **require()** in **/home/redacted/public/index.php** at line **17**

Any pointers would be helpful. Even if it's "your code is rubbish, start again!"

 

[digitalpoint]

Has to do with you trying to use a XenForo Repository from WordPress (can't do that).

Probably caused by an autoloader mechanism you added to WordPress to autoload XenForo classes? Basically the \DigitalPoint\Cloudflare\Repository\Cloudflare class is valid on both platforms, but they work a little differently depending on which platform it's run on. If it's finding both XenForo *and* WordPress as the platform it's running on, it's going to be a problem.

The end of the Repository class has it applying a trait based on the platform it's on to slightly alter it's behavior:

if (trait_exists('DigitalPoint\Cloudflare\Traits\XF'))
{
    class Cloudflare extends \DigitalPoint\Cloudflare\Repository\Advanced\Cloudflare
    {
        use \DigitalPoint\Cloudflare\Traits\XF;
        use \DigitalPoint\Cloudflare\Traits\Repository\XF;
    }
}
elseif(trait_exists('DigitalPoint\Cloudflare\Traits\WP'))
{
    class Cloudflare extends \DigitalPoint\Cloudflare\Repository\Advanced\Cloudflare
    {
        use \DigitalPoint\Cloudflare\Traits\WP;
        use \DigitalPoint\Cloudflare\Traits\Repository\WP;
    }
}

So ultimately the issue is if it finds the XenForo trait (which will only be available on XenForo normally... or if you are autoloading XenForo classes from WordPress). So the class will think it's in XenForo when it's not.

A bit hacky, but you could work around it by hacking your autoloader mechanism you have in WordPress to never load the DigitalPoint\Cloudflare\Traits\XF class since that should only be available in a XenForo install... and it's a problem if WordPress finds it.

 

[basenotes]

A bit hacky

I like hacky! Gives me somewhere to start - thanks!

 

[basenotes]

Okay, In case there's a rare occurrence of someone else stumbling on this, I changed my way of accessing the XF user information by using the XF API and session info. All good now

 

[digitalpoint]

Okay, In case there's a rare occurrence of someone else stumbling on this, I changed my way of accessing the XF user information by using the XF API and session info. All good now

Not going to be as efficient, but definitely more bulletproof since you aren’t trying to mash multiple frameworks into a single PHP stack.

Could see other weird things happening as well… for example you could end up with WordPress errors being logged in your XenForo server log since XenForo works on the premise of capturing PHP Exceptions (might not be a bad thing since WordPress error logging is terrible… hah). But ya, definitely would have potential for unexpected things like that trying to join two unique frameworks/platforms in a single PHP request.