Symphony.

Came across a nice bug today and it was interesting to trace it back to a potential performance related issue.

There was a section that had existed since the dawn of time and recently a new field was added to it. Because this field had alot of love, the client chose to sort by this field on the publish table.

The initial weirdness here is that because that field didn’t have a complete set of data for all entries (as it’s table has only existed recently), the pagination would break saying something like Page 7 of 900, but on page 7 there was only 3 entries.

Now whether the pagination should be updated so that it’s count is also affected by the sorted field I don’t know, but otherwise, that ‘weirdness’ isn’t really fixable (or do we prefill all existing entries on new tables with NULL values?)

After looking at the database table, we picked a few entry_id out and tried to go directly to their edit pages, but curiously, they failed. It was after further investigation that I discovered a bug/optimisation lie within the EntryManager->fetch function.

The publish/edit pages call this function with just a single parameter, the entry_id. However this still results in the sortable field being used to construct the SQL. Because this field didn’t have any data for the sortable field, the query would return nothing.

To fix that issue, the fetch function should not apply any sorting to the SQL, resulting in no JOIN’s and no ORDER BY statement, which can potentially speed up the backend of large/complex Symphony sites.

The fix:

Add the following to just before this line and amend the existing if to be else if.

if (!is_array($entry_id) && !is_null($entry_id) && is_int($entry_id)) {
    $sort = '';
}

Cool!