@MikeCreutzer,The issue is we are losing time in support tickets unlikely a normal product because the community has unique WP boards with complexities that are taking a lot of time to fenagle. The core product is stable and we have it working just fine on projects where we control the environment.
We may just remove it from the marketplace in general, we are trying to keep it in for your benefit. It saves a lot of time and money, and if you disagree then do not use the product. I know its not fair to you to do this, but its not fair to us that we're really deep in installation or third party configuration tickets. Its the nature of a bridge. It works fine for maybe 85-90% of installs, but that other 10% has tickets with us for long periods of itme.
Im trying to be as fair as possible but what we have now is not sustainable.
One idea is we will hold a webinar for one day where you can get one on one dev time through a live stream. Still working through the idea.
We have to remember the alternative here is just not having these features. You can always have WP without a matching theme, matching widgets, comments just being a thread, etc. The problem is some people use all kinds of different WP addons and they dont always play nice because they expect a WP environment, not a XF.
We have a product, Featured Threads and Content, which uses XenForo all the way and to date we've had maybe 10 tickets? Those products make sense to support and keep licenses as they are and not force installation on our part. This product here is going to be treated in part like a service. Its the nature of doing what this does. You can have WP bridges that do not do the theme or other advanced features and its fine, heck we built the one that just does user integration. But for now this is the happy medium.
They are not similar. They both claim to be WP bridges, but XPress does theme and other very detailed tasks. If you do not use the theme, then you wont have any WP issues. We might even just separate out the products...
No one has spoken about value.Even at the new price the addon is by far one of the best value for money addons you can buy.
No one has spoken about third party add-ons. And unless you have clairvoyant powers, it might be advisable to keep it to yourself, that the problems I am experiencing with the X-poducts would be coming from third party add-ons - which they are clearly not.The price changes are pretty black and white. Issues are coming from third-party wordpress plugins which TH are having to support. Time spent supporting these fixes is eating up TH time. Time = Money.
I am sorry for you that you don´t get it. I HAVE ALREADY (if not clear, repeat reading) bought the products for fixed prices before the price change. If still not clear, ask a friend. Sit down, grade F.If you don't like the new price simply don't purchase the product. I guarantee if you get a quote from another agency for these features you'll be back with your tail between your legs.
"The better way to think about XPress is that its WP inside of XF."
Mike, this gives me somehow a little relief as I was in fact thinking about to quit on TH add-ons. Which would have led to quit using XF and to move on to IPB, since the core functions of my platforms are build around some of your add-ons. What you´ve outlined above seems to me as a far more better approach, even when it´s not to the point what I was hoping for. But I see and acknowledge, that you´ve tried to come to a somehow fair (and viable) conclusion.All that said, I will be OK offering a difference (a refund) for updates for people who bought any XLink product prior to Oct 2019. Our policy on upgrades or installs will continue to essentially be that if its a conflict with anything other than the software, we will charge to not only just fix it but look into it in the first place. Conflicts exist, and we can fix them, but there are too many. The core 85% of users are not having an issue, and the other 15% should not be left hanging, but due to the various situations that that 15% has created conflicts for themselves we cannot spend our own time to fix it. Its your platform after all.
I guess in fact it´s a difficult task, to roll back the way you´ve operated support in the last years and in most - if not any cases - free of charge. Correct me, when I am going wrong here, but I have the feeling you´re trying to avoid that people are getting toxic, when a SLA model would be introduced and sharp borders between those would come into effect, requiring another SLA # with an additional payment as soon as you´ve noticed, the problem evolves from a third party add-on. I absolutly understand, that you can´t dump support and developer time into those compatibility problems - just because there are uncountable #´s of add-ons out there and there will be hundreds of incompatibillities. IIRC, this would be the first SLA model in the XenForo Add-On world.We'll probably define this a bit more clearly as we move forward, but for now the plan is to try this, and if this doesn't work we'll remove it from the shop and have a landing page up to contact us for a custom installation in general, no way to buy it outright. I hate to do that to the 85% or 90% but that other percent is quite vocal. Doing the best I can come up with I hope you know.
I have never heard of an add-on or plugin that disables a core functionality like caching, where the developers are unwilling or unable to fix that issue and on top of that charge you 300 bucks for.
However, we have seen other an add-on like XenWord doing similar (if not more) things in a less restrictive way.
if xenword managed to work with lots of plugins installed, TH why don't you ask the developer for some help, he doesn't want to work on xenword anymore anyway.
This is not working for me. I am getting this error:That means XenForo hasn't been able to establish a connection with WordPress. If you're running the latest version of the XPress plugin on WordPress, the most likely cause is that your servers own requests are getting proxied, for example through cloudflare.
A short term solution is to add the following line to your XenForosconfig.php
:
Code:$config['xpressAPIPassword'] = '<a strong password of your choice>';
and the following to your WordPresswp-config.php
file:
Code:define('XPRESS_API_PASSWORD', "<the same password as above>");
We do recommend to ensure both your installations are run over https, so the password cannot be read out by a man in the middle attack, as well as to regularly change it. Optimally you can whitelist your own server from the proxy so that it makes the request itself, rather than the proxy server making it.
ThemeHouse\XLink\APIException: API call to 'WP' failed: Request blocked by remote installation in src/addons/ThemeHouse/XLink/RemoteHandler/Traits/APICall.php at line 81
ThemeHouse\XPress\RemoteHandler\Entity->callAPI() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 107
ThemeHouse\XPress\RemoteHandler\Entity->loadPosts() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 77
ThemeHouse\XPress\RemoteHandler\Entity->loadRemoteEntities() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 65
ThemeHouse\XPress\RemoteHandler\Entity->getRemoteEntity() in src/addons/ThemeHouse/XLink/Entity/EntityLink.php at line 94
ThemeHouse\XLink\Entity\EntityLink->getRemoteEntity() in src/XF/Mvc/Entity/Entity.php at line 148
XF\Mvc\Entity\Entity->get() in src/XF/Mvc/Entity/Entity.php at line 101
XF\Mvc\Entity\Entity->__get() in src/addons/ThemeHouse/XPress/XF/Pub/Controller/Thread.php at line 28
ThemeHouse\XPress\XF\Pub\Controller\Thread->actionIndex() in src/XF/Mvc/Dispatcher.php at line 321
XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244
XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100
XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178
XF\App->run() in src/XF.php at line 390
XF::runApp() in index.php at line 20
This is not working for me. I am getting this error:
Code:ThemeHouse\XLink\APIException: API call to 'WP' failed: Request blocked by remote installation in src/addons/ThemeHouse/XLink/RemoteHandler/Traits/APICall.php at line 81 ThemeHouse\XPress\RemoteHandler\Entity->callAPI() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 107 ThemeHouse\XPress\RemoteHandler\Entity->loadPosts() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 77 ThemeHouse\XPress\RemoteHandler\Entity->loadRemoteEntities() in src/addons/ThemeHouse/XPress/RemoteHandler/Entity.php at line 65 ThemeHouse\XPress\RemoteHandler\Entity->getRemoteEntity() in src/addons/ThemeHouse/XLink/Entity/EntityLink.php at line 94 ThemeHouse\XLink\Entity\EntityLink->getRemoteEntity() in src/XF/Mvc/Entity/Entity.php at line 148 XF\Mvc\Entity\Entity->get() in src/XF/Mvc/Entity/Entity.php at line 101 XF\Mvc\Entity\Entity->__get() in src/addons/ThemeHouse/XPress/XF/Pub/Controller/Thread.php at line 28 ThemeHouse\XPress\XF\Pub\Controller\Thread->actionIndex() in src/XF/Mvc/Dispatcher.php at line 321 XF\Mvc\Dispatcher->dispatchClass() in src/XF/Mvc/Dispatcher.php at line 244 XF\Mvc\Dispatcher->dispatchFromMatch() in src/XF/Mvc/Dispatcher.php at line 100 XF\Mvc\Dispatcher->dispatchLoop() in src/XF/Mvc/Dispatcher.php at line 50 XF\Mvc\Dispatcher->run() in src/XF/App.php at line 2178 XF\App->run() in src/XF.php at line 390 XF::runApp() in index.php at line 20
I am using CloudFlare to manage my DNS. Am I missing something? I have configured my path and absolute url correctly on XenForo.
I am using CloudFlare to manage my DNS. Am I missing something?
I just have Xpress plugin installed, I deleted Hello dolly and Akismet. In XenForo I just have Xlink and Xpress, nothing else. I uploaded again the Xpress plugin from src/addons/ThemeHouse/XPress/_remote/wp-content/plugins/wp-xpress-plugin to /public_html/wp-content/plugins/wp-xpress-plugin but still getting the same error.Have you tried disabling any WP plugins to see if fixes the problem? Just helps narrow it down and not sure if you have mentioned. Not Lukas obviously but I'm also running the same and use Cloudflare, but any of my issues were fixed by the API password addition to config.php
Yes, I have done that. Is the same instructions that I quoted above, but they are not working for me.If you are running your installation behind Cloudflare, you'll need to set up an API password as outlined in our troubleshooting documentation or WordPress won't be able to authenticate the API calls.
Then you may have a firewall or security plugin blocking API access.Yes, I have done that. Is the same instructions that I quoted above, but they are not working for me.
I have in src/config.php
$config['xpressAPIPassword'] = 'verystrongpassword';
and in wp-config.php
define('XLINK_API_PASSWORD', "verystrongpassword");
The password has to be alphanumeric. Adding backticks will break it.Try like this
'`verystrongpassword`';
The password has to be alphanumeric. Adding backticks will break it.
We use essential cookies to make this site work, and optional cookies to enhance your experience.