PHP Fatal error: Call to undefined function esq_sql() — Typo?

[Anonymous]

Version: 1.6.3 on WP 4.4.1_de_DE

I have this in my error.log:
PHP Fatal error: Call to undefined function esq_sql() in /…/wp-content/plugins/events-made-easy/eme_locations.php on line 599

it appears when I push the “>>” link in calendar view – it simply starts the little spinner and nothing else happens.

when I call the page with ?calmonth=02&calyear=2016 GET-Parameters it’s the same, nothing is shown and creation of the page is interrupted.

I can’t find this function in eme-source code, it’s not in WordPress Codex – but there is esc_sql() – did you mean that and it’s just a typo???

[Anonymous]

I replaced esq_sql with esc_sql and it works now. (Line 599 and 603) I found no other occurrences of this typo in eme sources.

(Well, at first it didn’t work, but error-message changed to “PHP Fatal error: Allowed memory size of nnnnnnnn bytes exhausted (tried to allocate 89 bytes)” and I had to raise the memory limit) Calendar view takes a lot of memory and is slow.

[Franky]

Confirmed as a bug and your fix is correct (very weird nobody else reported this yet)
Concerning the memory issue: how many events do you have in your calendar view? Normally I try to only get the events from the DB that are requested, and that shouldn’t take a lot of memory. So I’m interested if by any chance you can figure out where the memory is allocated, so I can improve the code.

[Anonymous]

maybe the error happens only in coincidence with the filter shortcodes.

About performance: There are about 75 Events in my february-view. My eme_events-Table contains 4092 entries atm.

The page does 16041 Database queries in 22,434 seconds. Other pages do about 60 in less than a second.

You might want to have a look yourself: http://www.latin-lausitz.de/salsatermine/kalender/

[Franky]

I’ll analyze the requests made, maybe there’s some optimization that can be done.
But this seem like a lot of queries … can you also mail me the template you use?

[Franky]

Ok, this change should greatly reduce the number of SQL statements made:
http://plugins.trac.wordpress.org/changeset/1341352

Please test 🙂

[Anonymous]

I Tested it. It works.
before: 16038 queries
after: 8018 queries

This is going in the right direction =)

What templates do you need? My line for a calendar-entry looks like that:

<li title=”#H:#i #_EVENTNAME #_LOCATIONNAME #_ADDRESS #_TOWN”>#H:#i #_EVENTNAME, #_TOWN

and the calendar is insert on a page with the following shortcodes:

[eme_filterform submit="einschränken" fields="towns,categories" multiple="1"]
[eme_calendar full=1]

Immer auf dem neuesten Stand: [eme_ical_link text="Termine abonnieren"]

Thanks a lot and have a nice day!

[Anonymous]

I tested it on other months (with calmonth/calyear-GET-Parameters) – February causes by far the most queries:
December’15: 218
January: 268
February: 8018 – Maybe because it’s the current month?
March: 136
April: 84
May: 42
(Calender has much less entries in the future, so numbers are going down.)

I wondered, if there is something wrong with my Feb-events, but I can’t see anything strange or different.

[Franky]

Can you check in your mysql logs which queries are used more than 2 times for Feb? Of course on a dev server … maybe it is not all EME related?
I only have 2 queries if location info is not included. If location info is included (using location placeholders), an extra query is done per event. That too can be optimized, but requires more profound code changes while maybe reducing the code readability (if that even is there now …)
And indeed, I didn’t evaluate the queries done for the search form yet, but those should be minimal.

[Anonymous]

Good Morning,
this is what most part of my mysql.log looks like, when I ONCE call the full calendar:

14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’11’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’41’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’11’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’41’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’113′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’102′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’102′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’110′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’99’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’115′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’99’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’115′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’110′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’99’
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’6′
14 Query SELECT * FROM salsa_eme_locations WHERE location_id =’115′

and so on about 8000 times. Two location request per event you say? it looks like it’s doing 2 for each event in the DB (about 4000 in my case), not only those visible in the current month.

On my calendar page isn’t much else but the calendar, no widget sidebar, no plug-ins.
removing the filter_form and ical-link- shortcodes didn’t change much.

Thanks for tackling this problem =)

[Franky]

Weird, I only see as many location sql’s as there are events currently shown.
Using this change: http://plugins.trac.wordpress.org/changeset/1342180 I now completely removed the separate location-sql’s. So my cal now shows only 1 sql in total (maybe 2) for the eme tables.
Try this 🙂 And of course make sure to apply all changes in both changesets … (or just download the EME from trunk: https://downloads.wordpress.org/plugin/events-made-easy.zip

[Anonymous]

Thanks. With this last fix I’am down to 23 Queries for Feb ’16 =). Most of them are probably WordPress’ own queries. That couldn’t be better.

still it’s running quite slow for current month (~20secs) even though there are only 23 queries. But I have to figure out where the Webserver spends the time – but at the moment I have no clue how to go about that best 🙂 Ideas are welcome.

I’ll let you know, if it is somewhere in your scripts.

Thanks a lot!

[Franky]

The way I can test your site, it does seem to have something to do with the EME tables. But I think the slow response might be related to EME table indexes not being there. Maybe indexing some columns will speed things up. Can you activate the mysql slow queries thingie and see what that gives?

[Anonymous]

1. This installation is quite old and if indexes weren’t created during updates, they aren’t there. (Maybe you have a list of tables/fields that should be indexed?)

2. Slow-log was running, but not showing anything at a 5sec Limit. so I set the time limit to 1 sec … still nothing. I turned on log-queries-not-using-indexes and got one eme result.

# Time: 160203 15:21:14
# User@Host: ***********************
# Query_time: 0.138100  Lock_time: 0.000046 Rows_sent: 4010  Rows_examined: 12098
SET timestamp=1454509274;
SELECT * FROM salsa_eme_events e LEFT JOIN salsa_eme_locations l ON e.location_id=l.location_id
          WHERE event_status IN (1,2) AND  ((event_start_date BETWEEN '2016-01-32' AND '2016-03-07') OR (event_end_
date BETWEEN '2016-01-32' AND '2016-03-07') OR (event_start_date <= '2016-01-32' AND event_end_date >= '2016-03-07'
))
         ORDER BY event_start_date ASC, event_start_time ASC, event_name ASC;

what’s worrying: event_start_date BETWEEN ‘2016-01-32‘
aaand – 4010 Rows sent: maybe this gives the script a lot of work to do?

[Anonymous]

weird date-arithmetic confirmed: all months are quickly displayed besides those that start with Monday 1st – like February and August 2016 or June 2015.

It looks like mysql ignores the between-clause with the illegal dates and just returns everything. This is a quite old mysql-version here: 5.1.73, maybe they fixed that already. But for some technical foo- reason I can’t simply update 🙁 – I’m already searching for a new hosting company)

[Franky]

This is both interesting and weird 🙂
I have this:

SELECT * FROM wp_eme_events e LEFT JOIN wp_eme_locations l ON e.location_id=l.location_id
          WHERE event_status=1 AND  ((event_start_date BETWEEN '2016-01-31' AND '2016-03-07') OR (event_end_date BETWEEN '2016-01-31' AND '2016-03-07') OR (event_start_date <= '2016-01-31' AND event_end_date >= '2016-03-07'))
         ORDER BY event_start_date ASC, event_start_time ASC, event_name ASC

So … where is indeed the 2016-01-32 coming from? If you change that to 31, is the number of rows better? I’ll check the code here in the meantime

[Franky]

Ok, the 32 comes from some calculation to know the first day of the previous month to show in the current cal, in combination with the wp setting “first day of the week”. Try if this fixes it:
http://plugins.trac.wordpress.org/changeset/1342307

It seems like this wrong range in the sql causes all rows to be returned …

[Anonymous]

The 32-Query gives 4010 Rows in phpMyAdmin,
if I correct it I get 91 Rows.

This is PHP 5.3.2 – Maybe you are using date arithmetics that weren’t present in 5.3 or worked differently?

[Franky]

Try the last changeset I’ve given above, should fix it

[Anonymous]

You made it!

now it works like a charm in less than a second and memory consumption has gone down from near MemoryLimit to ~70MB.

Thanks a lot and keep up the good work!

[Author]

Posts