|
youngjc345
|
February 1, 2017 at 8:11 am
I currently have the Event Espresso – Event App Customization (EE4.9.9+) plugin installed and my custom logo in the settings, but it doesn’t seem to be loading on the app. I log-in successfully and log back out but the logo does not change. Anything in particular causes this?
|
|
Lorenzo Orlando Caum
|
February 1, 2017 at 10:05 am
Hello,
I’ve just tested this with the Event Espresso 4.9.29 and the app Customization add-on and it is working for me: https://cl.ly/232R3U1K1m2a
Are you running any caching services for your site?
Also, could you let us know if you are using the iOS app or the Android app?
The image above is from an iPhone.
—
Lorenzo
|
|
youngjc345
|
February 1, 2017 at 10:48 am
I am using the iOS app,this feature was working previously but I’ve also within the last few weeks migrated to WPEngine as my host who I know caches aggressively. I’ve had to request that they exclude certain cookies from cache to remedy some issues. Is there any cookies that I should request to be excluded to test again?
Thanks!
|
|
Josh
|
February 1, 2017 at 11:59 am
I don’t believe the apps use cookies, have you double-checked the image URL in the app customizer settings to make sure it’s pointing to a valid image URL? It may be that if the image is being hosted on the WPEngine server the file permissions will not allow the app to open it. In which case you can try hosting the image elsewhere.
|
|
youngjc345
|
February 2, 2017 at 3:17 pm
I changed the image link to one from a different host and the issue still persists. I also get this error when trying to sign back in.
|
|
Josh
|
February 2, 2017 at 3:23 pm
You might need to refresh the WP Settings > Permalinks page, and check the other things from the troubleshooting guide:
https://eventespresso.com/wiki/ee4-event-apps/#troubleshooting
|
|
youngjc345
|
February 4, 2017 at 9:48 am
I’ve done the following to attempt to troubleshoot the issue to no avail:
-Updated the permalink settings and updated to newest versions of wordpress and eventespresso.
-Created a new event after the permalink update to ensure it was not an issue of the link.
-Logged into eventespresso app with a different user.
-Changed rewrite rule in .htaccess for Apache and requested WPENGINE to adjust ngnix server
This error still persists
Please advise
Thanks!
|
|
Josh
|
February 6, 2017 at 7:46 am
Do you have any other plugins activated other than Event Espresso 4?
|
|
youngjc345
|
February 6, 2017 at 8:34 am
Yes, I use quite a few.
You can view a list HERE
I also note iThemes Security is on the troubleshooting list and confirm that “System Tweaks” is disabled.
Thanks!
|
|
Josh
|
February 6, 2017 at 9:13 am
Can you try disabling those other plugins one-by-one then check the app? There may be a conflict with at least one of those other plugins.
|
|
youngjc345
|
February 7, 2017 at 4:44 am
I deactivated all plugins with the exception of the Event Espresso plugin and the app customization plugin. This did not resolve the issue.
It was functioning correctly at one point, and I used test events to test the app. I then deleted these test events, and at some point thereafter it no longer worked. Could this have caused the issue?
I ask because it says resource not found. There is however, an active event assigned to the user logged in to the app.
|
|
Josh
|
February 7, 2017 at 9:24 am
Deleting the test events would not cause the issue. Do you have the site copied over to the Staging area on WPEngine? If so that would allow for some troubleshooting without messing with the live website.
|
|
youngjc345
|
February 7, 2017 at 12:15 pm
I just had one made.
What is the best e-mail to send login information to?
Thanks!
|
|
Josh
|
February 7, 2017 at 12:23 pm
Have you tried troubleshooting there first?
|
|
youngjc345
|
February 7, 2017 at 4:23 pm
I believe I have found the issue. The main URL currently redirects users to a different site based on user location using plugin “redirection”. I deactivated the plugin in the staging install and the events loaded fine. As the main domain is used in the “Website URL” field, I assume the redirection on this URL is what is causing the issue. Is it possible to use a different link in the “website url” field such as the event link or is the main/install URL the only link that can be used.
Thanks!
|
|
Josh
|
February 7, 2017 at 5:12 pm
The main website URL is the only URL that can be used in the website URL field.
|
|
youngjc345
|
February 8, 2017 at 6:45 am
When I reset the settings on Event Espresso – App Customization it changes the .htaccess and removes the RewriteRule ^index\.php$ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] line. here’s a video showing it: https://youtu.be/HK4elT1dhEw
|
|
Josh
|
February 8, 2017 at 7:56 am
You’ll need to add the line back then.
|
|
youngjc345
|
February 10, 2017 at 2:49 pm
Hey Josh.
I have the app working fine on the WPEngine Staging site and I’ve copied the staging install over to Live and I am still faced with the same error message. I’ve implemented all recommended changes at https://eventespresso.com/wiki/ee4-event-apps/#troubleshooting and I’ve be in continuous contact with WPEngine support regarding the issue but their lack of knowledge on the nuances of the plugin/app limits their ability to support. I’m currently grasping at straws trying to remedy the issue to no avail and would appreciate any assistance you’re able to provide as I have organizers with events coming up who require the app and I’m not sure what next step to take.
Many Thanks
|
|
Josh
|
February 10, 2017 at 8:12 pm
I’m not sure how I can help with this. So it’s working on the staging server, but not on the production server? If that’s case what you could do in the interim is push the data from live to staging, then you log in onto the staging with your app and use it there. You may need to put Event Espresso into maintenance mode while using the app on staging to allow syncing the ticket check in data back to the live site. Or you can use a plugin+service like Mergebot to merge the data back to the live site.
If I were to take a guess about why it’s working on the WPEngine staging server and not on the live server, my guess would be there’s a security setting that’s only activated on the live server.
|
|
youngjc345
|
February 11, 2017 at 4:26 am
Thank You for that advise, I may just use it in the interim. What would be helpful is if you could advise how the app retrieves the events so that I could allow wpengine to have a better understanding of what could possibly be interfering. From my current understanding the app is able to log-in but is unable to find and display the events on the site. Does this mean that the authorization header is being permitted as a result of the successful log-in? How are the events then retrieved? This may be completely unrelated but, does it matter if the site force ssl on all pages?
Thanks
|
|
youngjc345
|
February 11, 2017 at 5:25 pm
Spoke to WPEngine support again, they are saying that staging proxies pass all requests which is probably why it works on staging and not live. I proposed the recommended nginx and apache changes however they said that they would need to know what http header the app calls so that they can proxy it through on their end which should hopefully resolve issue. There exact words are
We don’t know what it’s doing, we don’t know what the calls look like, so we don’t know how to write the rule, we need more context.
|
|
Josh
|
February 13, 2017 at 9:46 am
The issue seems to be more on the Authentication end of things, not event retrieval. So here’s some information that WPEngine should be able to use:
1) The Event Espresso apps, by default, use the Basic Auth plugin which is bundled into Event Espresso. The standalone version can be downloaded here:
https://wordpress.org/plugins/wp-basic-auth/
2) Some host configurations don’t allow passing the Authorization header, which sounds like that’s what’s happening here. There’s more discussion about the issue in this github issue:
https://github.com/WP-API/WP-API/issues/2512
3) This might be a solution since it relates to the WP REST API + WPEngine:
https://github.com/Tmeister/wp-api-jwt-auth#wpengine
|
|
youngjc345
|
February 15, 2017 at 11:17 am
Thanks for this Josh.
Here is the response received from WPEngine support.
I’ve checked into the issue, and due to how our platform is configured, authorization via the Authorization header will not be possible. That said, if another header is used, for example ee_authorization, that would be passed back to Apache for processing, and your clients would be able to authenticate with the site. For this, you would need to contact the developer of the plugin to see if they will add an option for specifying a custom header for authentication.
Is this proposed solution at all possible?
In the meantime I am working on implementing the changes you recommended as per https://github.com/Tmeister/wp-api-jwt-auth
Just to confirm, to test this I should just implement the use of the plugin and htaccess modification to Enable PHP HTTP Authorization Header is that correct? or should the entire mod be carried out such as Configure the Secret Key/CORS Support etc.
Thanks!
|
|
Josh
|
February 15, 2017 at 12:53 pm
Their proposed solution isn’t feasible. Most of the other hosts allow the Authorization headers in one way or another.
It sounds like what ever you try to get Basic Auth to work isn’t going work on WPEngine’s live platform, unless there is a way, and they’re not telling you.
|
|
youngjc345
|
February 16, 2017 at 3:18 pm
Update: Just received confirmation from the WPEngine “Server Admin” who explicitly reiterated that the request to allow authentication using authorization header “is not possible on our platform”. Seems the unfortunate only way forward is to migrate to a new host.
|
|
Josh
|
February 16, 2017 at 4:50 pm
There might be another way forward, you may want to keep an eye on this github issue for further developments:
https://github.com/WP-API/WP-API/issues/2512#issuecomment-280227505
|
|
Josh
|
February 17, 2017 at 9:42 am
Looks like WPEngine is going to put in the change:
We’re putting in the change for this, so this problem should go away once it gets deployed.
https://github.com/WP-API/WP-API/issues/2512#issuecomment-280539514
|
|
youngjc345
|
February 20, 2017 at 10:27 am
Thanks Josh,
I reopened the ticket on their support regarding this issue, still waiting for confirmation of the change being implemented.
|
|
youngjc345
|
February 24, 2017 at 5:11 am
WPEngine has just confirmed that “The fix has been deployed at this time” Which I assume means that the Authorization header should now be passed. However, I am still receiving the same error message. This is my current .htaccess `#Please Note: Optimized WordPress is a Managed Platform offering, and this file has been configured to work under this managed platform. Changes to this file are not recommended and may impact our ability to provide support for your WordPress site.##
# BEGIN WPSuperCache
# END WPSuperCache
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
SetEnvIf Authorization \”(.*)\” HTTP_AUTHORIZATION=$1
RewriteBase /
RewriteRule ^index\\.php$ – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
<IfModule mod_suphp.c>
suPHP_ConfigPath /home1/waczeu0abwe2
<Files php.ini>
order allow,deny
deny from all
</Files>
</IfModule>
`
Are there any other changes that you can recommend be done or implemented before I report back to them that the issue is unresolved? Everything in the troubleshoot document has been done.
Thanks!
|
|
Josh
|
February 24, 2017 at 7:48 am
Some of the information in this thread may be helpful depending on your server’s version of Apache:
https://github.com/WP-API/WP-API/issues/2512#issuecomment-280550267
|
|
youngjc345
|
February 28, 2017 at 12:09 pm
required re-install of eventespresso app to recognize adjustment made by WPEngine.
|
