XPress - A theme and bridge for bringing WordPress into XenForo [Deleted]
- Thread starter ThemeHouse
- Start date
@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:
When this line is copied from the website and pasted into your config files, the bug gets inserted:
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?
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:
When this line is copied from the website and pasted into your config files, the bug gets inserted:
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?
@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
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.
No one has spoken about value.
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.
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:
@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.
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 regarding your review: https://www.themehouse.com/blog/uix-xpress-xwiki-and-xlink-performance
The better way to think about XPress is that its WP inside of XF. So your WP caching tools simply dont know what to do since they cache views. Instead, you cache at the XenForo level. You wouldn't use Jetpack on XenForo, so you wouldnt here just because you can install it.
The better way to think about XPress is that its WP inside of XF. So your WP caching tools simply dont know what to do since they cache views. Instead, you cache at the XenForo level. You wouldn't use Jetpack on XenForo, so you wouldnt here just because you can install it.
mrmad
Active 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.
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
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.
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.
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
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)
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.
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
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
Active 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 20I am using CloudFlare to manage my DNS. Am I missing something? I have configured my path and absolute url correctly on XenForo.
Upgrayedd
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
Lukas W.
Well-known 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.
Elmer
Active member
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
Active member
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");
Upgrayedd
Member
Lukas W.
Well-known member
Then you may have a firewall or security plugin blocking API access.
The password has to be alphanumeric. Adding backticks will break it.
Upgrayedd
Member
Ahhh. Mine is, I just saw the difference and thought I'd tell him to try that. Thanks for the correction.
Similar threads
