|
Dan Gall
|
October 10, 2016 at 4:20 pm
I noticed a problem when checking people into an Event.
1. Click on Registrations
2. Click Event Check-In tab
3. Filter by an Event
4. If an event has 3 Datetime, all 3 Datetimes appear with people who registered which is good.
5. Find a person who has registered for 2 Datetimes for the same event.
6. Check them In for 1 of the datetimes.
7. They will be marked as checked in which is good.
8. now if you filter by Event and this time select a Datetime Filter, that person is not checked in. Which is bad 🙁
This also works Vice Versa…
1. Click on Registrations
2. Click Event Check-In tab
3. Filter by an Event then by Datetime
4. Check a person in.
7. They will be marked as checked in which is good.
8. now if you Reset filter and Filter just by Event that person is not checked in. Which is bad 🙁
Am I missing anything as to why this is happening?
|
|
Josh
|
October 12, 2016 at 11:44 am
Yes in both cases, you need to view the filtered view when checking in or viewing checkins for a specific date time.
|
|
Dan Gall
|
October 12, 2016 at 11:54 am
That doesn’t make sense. So a person who is checked in for an event datetime from the event filter, would also need to be checked in from a datetime from the datetime filter that appears after you select an event? If I check a person in from the Event filter for a datetime, it checks them in for both the Event screen and the Datetime Screen, but not vice versa.
The problem is coordinators will be checking people in and they could do it in both places, causing some people not to be checked on on certain lists.
Dan
|
|
Josh
|
October 12, 2016 at 12:36 pm
Hi Dan,
So a person who is checked in for an event datetime from the event filter
We’ll remove that option so they can’t be checked in via the unfiltered view. That will eliminate the confusion.
|
|
Dan Gall
|
October 12, 2016 at 12:42 pm
Thanks Josh… but …
|
|
Dan Gall
|
October 12, 2016 at 12:46 pm
I’m trying to submit a reply with screenshots and code, but it always says its duplicate content and doesn’t post to the forum. Can I send it directly?
|
|
Dan Gall
|
October 12, 2016 at 12:47 pm
Now I lost the verty log reply with code and screenshots. Can you see it?
Dan
|
|
Josh
|
October 12, 2016 at 12:59 pm
Since these forums get hammered with quite a bit of spam, a reply with more than 6 links will get flagged as spam.
Thanks, but that won’t solve the problem. By checking them in through the Datetime filter, they are not showing in the event as checked in, nor are they showing checked in we view their status using the code below.
We’d love to hear your suggestions on how to better handle that scenario.
|
|
Dan Gall
|
October 12, 2016 at 1:12 pm
As long as Coordinators use the Datetime Filter and we remove the option so they can’t be checked in via the unfiltered view as you said. That would work great.
As long as …
$checkin_status = registration->check_in_status_for_datetime();
… produces the correct response.
|
|
Josh
|
October 12, 2016 at 3:31 pm
Thanks for the suggestions.
|
|
Dan Gall
|
October 19, 2016 at 8:03 am
Hey Josh,
Where do we stand with this?
|
|
Josh
|
October 19, 2016 at 11:12 am
You can see the work done so far and even test it out if you’d like by checking out this branch from our Github repository:
https://github.com/eventespresso/event-espresso-core/tree/BUG-10154-improve-checkin-ui-ux
|
|
Dan Gall
|
October 20, 2016 at 3:31 pm
404 Error on your link.
|
|
Josh
|
October 20, 2016 at 3:57 pm
You were too late on that link because that branch has been merged into Master and deleted since the time I posted the link to it. So if you want to get a copy of the release candidate, which has that branch merged into it, you can clone or download a copy of the Master branch.
https://github.com/eventespresso/event-espresso-core/
|
|
Dan Gall
|
October 20, 2016 at 4:29 pm
Worked like a charm 🙂 thanks so much Josh!
Dan
|
|
Dan Gall
|
October 20, 2016 at 4:37 pm
Eeep. I spoke too soon. The front end is working perfectly now and as expected 🙂
However, the admin Event Check-In Tab (under Registrations in the Admin) is coming up as a blank white page. I assume that’s why its a pre-release 😛
Dan
|
|
Josh
|
October 21, 2016 at 8:35 am
That’s not a correct assumption, the changes were tested and no errors were found while testing. Can you check the error logs to see what the error was? It’s possible that you’re hitting a memory limit, which you can confirm by looking at your PHP error log.
|
|
Dan Gall
|
October 21, 2016 at 9:06 am
Thanks Josh!!! Yup Memory limit needed to be increased. Your the best!
Dan
|
|
Dan Gall
|
October 21, 2016 at 3:39 pm
Actually it seems that the memory increase did not correct the Registration Check In page in the admin. I’m getting a 500 Internal Server error on that page and nothing in the error or access logs.
Anything else you can think of?
Dan
|
|
Josh
|
October 21, 2016 at 3:44 pm
Why the conflicting information Dan? Did it work at one point after bumping up the memory, then stop working? Or did you bump the memory, but not check to see if the memory bump worked?
One thing you could try is clearing your browser’s cookies, like if there’s a bad cookie in the browser and there’s some borked data in your current session, that could lead to a 500 server error, with nothing logged. Or try a different browser.
|
|
Dan Gall
|
October 21, 2016 at 3:46 pm
Its a problem of too many windows open and having a live version open and a development version open.
I’ll try your suggestion.
|
|
Dan Gall
|
October 21, 2016 at 4:06 pm
No. Clearing the Cache and trying a new browser did not work. Even disabling all plugins and EE4 plugins still produce the same problem.
|
|
Josh
|
October 24, 2016 at 7:57 am
You should try turning on WP_DEBUG to see if you can catch that error.
https://codex.wordpress.org/Debugging_in_WordPress#Example_wp-config.php_for_Debugging
|
|
Dan Gall
|
October 24, 2016 at 8:19 am
No debug.log file was created in wp-content after going to the page that is all white.
|
|
Josh
|
October 24, 2016 at 8:38 am
You can create one then. Sometimes the file/folder permissions on the server won’t allow creating a debug.log file when you turn on WP_DEBUG logging.
Along with that, for the sake of clarity since we’ve gotten a fair amount of conflicting info in this thread, when you see the blank page, does the URL match the following:
/wp-admin/admin.php?page=espresso_registrations&action=event_registrations&event_registrations_nonce={random nonce here}
or is it a different URL? If it’s a different URL, can you let us know that that URL is?
|
|
Dan Gall
|
October 24, 2016 at 8:43 am
I had created the file just to be sure and set it to 777, and it remained empty.
The link I have is the same as you have above…
/wp-admin/admin.php?page=espresso_registrations&action=event_registrations&event_registrations_nonce=cb1ca08471
|
|
Josh
|
October 24, 2016 at 9:36 am
When you put the release on your site was that something where you cloned the remote repository from Github and replaced the event espresso plugin folder, or were the files manually FTP’d up to the server? In any case, was the existing copy of Event Espresso deleted before uploading the release candidate files? They should have been deleted, if they were overwritten instead, that could cause the 500 errors you’re seeing.
Also, one of the developers added a bit of extra error proofing to the Master branch to avoid any errors in case there is no datetime record attached to the related ticket on the registration. That should not happen unless direct database manipulation was done to remove tickets from the database, but in case that was done, the current code in the release candidate will avoid the fatal error. So you could try the latest release candidate from Github as well.
|
|
Dan Gall
|
October 24, 2016 at 9:59 am
In the past, I had just overwritten the files from Github on the site via FTP. This time I deleted the EE4 Core plugin folder and re-uploaded all the files from the current Github release candidate.
Cleared Cache and restarted browser.
No direct database manipulation has been made.
I am still getting the white page with no text in the source when I click on the Check in.
|
|
Josh
|
October 24, 2016 at 11:25 am
Yeah you definitely should not overwrite plugin files using FTP. That will cause all kinds of problems. Since you’re not able to log any errors, would it be possible to get temporary admin and FTP access so we can investigate further? If so, you can send those via the secure form on this page:
https://eventespresso.com/send-login-details/
|
|
Josh
|
October 24, 2016 at 4:40 pm
So the reason for the WSOD was your server runs PHP 5.4. The developer that looked into this put a patch on your copy of Event Espresso 4, and we’ll include that patch in the next update.
It’s highly recommended to update to at least PHP 5.6, since PHP 5.4 and PHP 5.5 are end-of-life and no longer get security fixes.
http://php.net/supported-versions.php
|
|
Dan Gall
|
November 5, 2016 at 1:41 pm
All seems to be working now. Is it safe to upgrade to PHP7 for all EE 4 Add-ons and Plugins?
|
|
Tony
|
November 7, 2016 at 8:44 am
Hi Dan,
We run multiple test sites using PHP7 without any problems.
As some hosts do some weird and wonderful things we can’t say 100% but under any ‘normal’ setup it should be fine.
Some hosts allow you to specific the version of PHP to use within your .htaccess file, if your unsure you could try that using the examples shown here:
http://stackoverflow.com/questions/12561203/how-to-change-php-version-in-htaccess-in-server
|
|
Dan Gall
|
November 8, 2016 at 10:00 am
Thanks Tony.
|
