XPress - A theme and bridge for bringing WordPress into XenForo

XPress - A theme and bridge for bringing WordPress into XenForo 1.1.3 Patch Level 2

No permission to buy ($299.95)

Kirby

Well-known member
We don't need nor want installation support. The question is just if it is still possible to do the installation completely on our own as we did in the past.
 

Sperber

Well-known member
@diretur , @adwolf1 , @SoulReplicant ,

I guess I´ve found what used to be "bug" which is giving us so much headaches the last weeks and months. At least it has solved all my problems with my first WP instance (not with the 2nd one in a subdir) - and when you´ll check your instances I assume you´ll be feeling the same way, as I did.

Please check your config files ([XF_root]/src/config.php and [WP_root]/wp-config.php) and look for the line where you´ve included the API line. I assume, you did a copy & paste of the code line for the config files from the documentation at themehouse, like I did:

screenshot-www.themehouse.com-2019.10.20-08_21_22.png

When this line is copied from the website and pasted into your config files, the bug gets inserted:

xf_config_php.jpg

Keep an eye on the 2nd line and especialy the backticks, since this is how the pasted line translates in the editor. With using correct backticks like in the first line, the api errors are gone.

@Lukas W. , please check the Themehouse documentations, if there are more references to this line of code. This already solved the error in my 1st instance, before you´d provided the new wp_xpress_plugin.zip in the ticket. I haven´t applied this version, yet - but does it address the 2nd instance issue and shall I still install the file?
 

Sperber

Well-known member
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...
@MikeCreutzer,
I originally intended to discuss such a subject with you in a private message. The post I was referring to just made me upset that day that I let it trigger me. Apologize for that and I want to make clear, that i was and am not interested in a quality discussion about TH products, but only in the changed price model.

The fact that a price model has to be readjusted is not so rare. One has miscalculated, forgotten something in the calculation, circumstances change, and the calculation no longer works. Ultimately, I was and am not concerned about the $40 more, but the new price model you are disregarding a principle of contract management, to adhere to once made agreements. I had been expecting a change in your pricing structure since XWiki, when I heard months ago that sales weren´t evolving and the # of problems with XPress - or better: XLink - grew on. I had expected you to split your support between several Service Level Agreements and that you´ld add them to your shop as additional products, like:
  • SLA #1: free support for problems arising from the basic components XenForos and the X-series products
  • SLA #2: chargeable SLA, for problems arising from third-party add-ons - i.e. not from the basic components XenForos and the X series products.
  • SLA #3: Paid Initial Setup Support
With such SLAs at hand everybody can buy what he needs additionally - and you can couple the purchase of an X product with e.g. the SLA #3 as a precondition for all new customers, what your main purpose for the price change seemed to be.

But if I sell something to a customer that includes free product support for product-specific problems, I can't tell the customer a few weeks later "What do I care about my gossip and yesterday's contract? Tee-hee, you're paying now." This only provokes the fact that the customer was my customer for the last time and feels - not completely unjustified - as if he would have been dragged over the table. And that´s a what noone wants.

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 value.

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.
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.

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.
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.

(And before someone gives me hell: 20 yrs as customer has been a simple typo I noticed in my post prior. Make it a ten.)
 
Last edited:

Mike Creuzer

Well-known member
@Sperber I ultimately agree (or I did) that logically that follows. Unfortunately what I was seeing is people buying it, installing it, having a conflict with add-on XYZ and then doing a chargeback or asking for a refund. At this stage, it is not worth anyone's time to deal with this (though we could do this and fight for the people who deserve us to fight for them - believe me I dont want this to hurt the people who actually would have typical installs and appreciate the intricicacies of a bridge)

Instead, the situation I am most comfortable with (and what we voted on as a company) is to focus on the future. This model will allow us to work at a pace we are more comfortable with and service clients with the attention they need when they need it.

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.

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.
 

mrmad

Member
"The better way to think about XPress is that its WP inside of XF."
I don't think this has been marketed as a product that works only coming from XF-side of things. At least when I reported you the problem this had been clearly marked as an issue and something you were trying to solve.
We can go on back and forth about this endlessly with everyone claiming they are right.
The point is: this is not a debate club. I have never come across a single piece of software in WordPress or XenForo that is so selective under which circumstances it is going to operate "properly".
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.
If your customers are happy with that and can live with it - fine, you've found your golden dog.
However, we have seen other an add-on like XenWord doing similar (if not more) things in a less restrictive way.
 
Last edited:

diretur

Active member
"The better way to think about XPress is that its WP inside of XF."
that is also the reason why this addon doesn't work properly if you don't use the xpress style in wp. Duplicated comments (now solved), no quoting in xf if you use nested comments in wp, styling problems, etc.

The thing with the conflicting plugins is not really an excuse: who is using wp with no plugins at all? Furthermore, 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.
 

Sperber

Well-known member
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.
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.

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 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.

What I want so say is, you can´t comfort everybody. New models - especially those which are limiting something, that was giving for free in the past - most customers consider as a bat coming directly out of the depths of hell, with all the aftermaths. I was experiencing the same in the german XF community regarding add-on translations and regarding your support situation at Themehouse, I only can encourage you to go that path of the polluter-pays-principle nonetheless. Over time people will understand, that Themhouse is responsible for product specific problems and on the other hand they as customer are the only ones responsible for the add-ons they use in their platforms and which may be are conflicting. Of course many customers will still don´t like that, but it´s what I call fair business on all sides: pay as you go.
 

Jake B.

Well-known member
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.
Ultimately on this one the only thing preventing WordPress caching plugins from working is the theme bridge, it just isn't possible for us to get these to work together due to the nature of how PHP output buffers work - so we have made sure it works with XenForo 2.1's native guest page caching, as well as any server level caching (varnish, lightspeed, etc)

However, we have seen other an add-on like XenWord doing similar (if not more) things in a less restrictive way.
Pretty much any plugin incompatibility with XPress is going to be from the theme bridge, unfortunately there really isn't a whole lot we can do about that other than fix any issues in each specific plugin that are reported to us, but sometimes even that isn't possible.

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.
As I mentioned above, the reason for plugin incompatibilities are typically the theme bridge, which simply does not exist in any other add-on that I'm aware of - so it's not as simple as using another product as an example for preventing incompatibilities, sadly
 

mrmad

Member
Thanks a lot for all your replies and explanations. This is highly appreciated. However, this is not going to change anything from an admin and end-user perspective.
 

jb-net

Active member
As an XPress customer, I can say that the add-on would be worth the new price if there were not be as many bugs and limitations as there currently are. I can image it is really difficult to connect two different platforms but I hope with the new price the pace and quality of the development, especially the focus on bug fixing will improve. Only in this case the new price would be worth it.
 

ThemeHouse

Well-known member
We have decided that the best way to support clients looking to purchase XPress, XWiki, and Topics, is to conduct the installation more like we would a project. We can then help install XPress and XWiki on existing platforms, help with basic configuration, and assist in resolving server errors that may occur. This approach for XPress, XWiki, and Topics will enable us to provide a better experience to new customers based on their particular configuration and goals. We will continue to provide support to existing customers and have lowered the renewal price of XWiki and XPress from the recent increase.
 
Last edited:

Elmer

Member
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 XenForos config.php:
Code:
$config['xpressAPIPassword'] = '<a strong password of your choice>';
and the following to your WordPress wp-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.
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.
 

Upgrayedd

Member
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.
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
 

Elmer

Member
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
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.
 

Elmer

Member
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.
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");
 

Lukas W.

Formerly katsulynx
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");
Then you may have a firewall or security plugin blocking API access.

Try like this
'`verystrongpassword`';
The password has to be alphanumeric. Adding backticks will break it.
 
Top