Forum Replies Created
-
Posts
-
After reviewing a working version against this update, we noticed that on the call to ajax-admin.php, one of the passed parameters is not turning into a object as it should, and contains url encoded brackets []…
On the non-working version, we pass this parameter:
tribe_eventcategory%5B%5D: 1662And on a working version we pass this:
tribe_eventcategory[]: 1662And if multiple categories are select, the non-working version still looks like (only shows the last ID checked):
tribe_eventcategory%5B%5D: 1665Where the working version looks like this (an object with all checked IDs):
tribe_eventcategory[]: { 0: 1662 1: 1665 }Let’s be clear that users logging in with a Subscriber role can see the dashboard. This is default WP behavior. I’m demonstrating this with a screenshot from stock, local WP installation with no active plugins.
Since this behavior is the foundation of the issue, it’s important that you folks acknowledge this fact as true.
Hi Jamie,
Actually, out of the box, subscribers DO have access to the WP Admin area. They are limited to the “Dashboard” and their own “Profile”. This allows subscribers to be able to modify their profile (update name, contact info, and reset password) without having to bother the site admin. In our case, we would simply like to keep this default, out of the box experience.
I have, for clarification purposes, spun up a default instance of WordPress and have only installed The Events Calendar, The Events Calendar Pro, and Community Events plugins. No other plugin exists on the site (except for WP Engine default and required MU ones). I am also using the default Twenty Seventeen theme. I can guarantee there are no conflicts happening.
If you would like to replicate the issue, simply create a user with subscriber permissions. If you log in as that user, you will have access to the dashboard and your profile only. Now, as the administrator, change the settings under Events->Settings->Community. Check the boxes “Users cannot create new Venues”, “Users cannot create new Organizers”, “Edit their Submission”, and “Remove their submisions”. With those settings set, log back in as the subscriber and you will see the Events menu with “Events”, “Add New”, “Venues”, and “Organizers”.
Using this new menu, the subscriber can still only edit/delete their own submissions, and create new events… which is perfect! They do, however, see ALL submissions in the “events” table. Though they cannot modify those submissions in any way, they can still see them which might cause confusion. That is still not a big deal, however. The real problem is: in the steps above we have asked that no user be able to create new venues or organizers by checking those two boxes. However, these options now show in the admin menu… and a user CAN INDEED create a new venue and/or organizer from this back end (albeit they can only “submit for review”). The same action cannot be completed using the external page /events/community/add. But this still sort of defeats the purpose of those two checkboxes.
I guess I’m curious as to why the “Events” menu would show in the admin area to begin with for a level as low as a subscriber. I understand that it follows the same roles and permissions as any other post. I also understand that is has it’s own set of rules specific to the plugin, and we can manipulate those rules via a role manager type of plugin. And I suppose that if we are granting the user the ability to edit and delete their own posts, this is probably what is triggering the behavior in the admin area. But at the very least, I still feel if we have not allowed them to create venues and organizers, those menu items should still not appear at all?
Hi Victor,
I can confirm that the wp-config.php code I posted does indeed fix this issue. We are now reporting back the proper domain name to The Events Calendar and licenses are working as intended! Let me know if you need any further details.
Hi Victor,
I found this post:
https://theeventscalendar.com/support/forums/topic/license-key-tied-to-site-url-issue/
Which indicated I should put this in wp-config.php:
if ( isset( $_ENV[‘PANTHEON_ENVIRONMENT’] ) ) { $_SERVER[‘SERVER_NAME’] = $_SERVER[‘HTTP_HOST’]; }We are trying it now to see if it’ll work. According to this document:
https://pantheon.io/docs/server_name-and-server_port/
it’s something we shouldn’t have to do, but we must as The Events Calendar checks for
$_SERVER['SERVER_NAME']instead of$_SERVER['HTTP_HOST']. I’ll post back if it works as we need to wait for our next deployment window to test.
