• Resolved mbsharp

    (@mbsharp)


    I have three sites on separate hosting packages with the same provider. They are all on PHP 8.3, WP 7.0.2, MariaDB 10.11.18, Weaver-Xtreme theme, Imagely(Nextgen) 4.2.3, meaning everything is up to date. The sites have no more than 5 albums, each with under 10 galleries, so not large.

    Just one of those sites is throwing an SQL syntax error several times per day (see below). The timing is not related to any backend activity, or to any legitimate visitor according to my stats package. However, the stats package does not record bot/crawler access. The error message example is:

    [19-Jul-2026 19:58:35 UTC] WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ‘)’ at line 1 for query
    SELECT DISTINCT wp_ngg_album.* , GROUP_CONCAT(CONCAT_WS(‘@@’, meta_key, meta_value)) AS ‘extras’ FROM wp_ngg_album LEFT OUTER JOIN wp_postmeta ON wp_postmeta.post_id = extras_post_id WHERE (id IN (0)) GROUP BY wp_ngg_album.id ORDER BY FIELD(id, )
    made by require(‘wp-blog-header.php’), require_once(‘wp-includes/template-loader.php’), include(‘/themes/weaver-xtreme/page.php’), get_template_part, locate_template, load_template, require(‘/themes/weaver-xtreme/templates/content-page.php’), weaverx_the_page_content, weaverx_the_contnt, the_content, apply_filters(‘the_content’), WP_Hook->apply_filters, Imagely\NGG\Display\Shortcodes->parse_content, Imagely\NGG\Display\Shortcodes->execute_found_shortcode, Imagely\NGG\Display\Shortcodes->render_shortcode, Imagely\NGG\Display\DisplayManager->display_imagely_shortcode, Imagely\NGG\Display\DisplayManager->display_album_by_id, Imagely\NGG\DisplayedGallery\Renderer->display_images, Imagely\NGG\DisplayedGallery\Renderer->render, Imagely\NGG\DisplayTypes\Albums\SharedController->index_action, Imagely\NGG\DisplayTypes\Albums\SharedController->get_entities, Imagely\NGG\DataTypes\DisplayedGallery->get_included_entities, Imagely\NGG\DataTypes\DisplayedGallery->get_entities, Imagely\NGG\DataTypes\DisplayedGallery->_get_album_and_gallery_entities, Imagely\NGG\DataMapper\TableDriver->run_query

    It appears to be a select to do with albums. 4 of 5 albums were originally made in Nextgen v3. I took the trouble to delete each album in turn and recreate it in Imagely v4, followed by viewing each album. The messages were being created before, did not occur during the process, and continued later.

    Any ideas? Is the problem at ‘(id in (0))’ ? Is ‘0’ an invalid value?

Viewing 2 replies - 1 through 2 (of 2 total)
  • Plugin Support Mihai

    (@mceban)

    Hi @mbsharp ,

    Thank you for the detailed report and for rebuilding the album. This has helped pinpoint the issue.

    You had a good instinct with the (id IN (0)) part; that’s actually a harmless “match nothing” placeholder, and the SQL is valid. The real issue is with the end of the query: ORDER BY FIELD(id, ). That FIELD() has an empty list after the comma, and it’s the unclosed parentheses causing the error message from MariaDB (“near ‘)'”).

    Here’s why it’s happening:

    Your album display reads a value from the page URL to allow navigation into sub-albums (like ?album=some-name or /album–some-name/). When something requests an album page with a value that doesn’t match any real album, NextGEN Gallery can’t resolve it and ends up running a query for “no albums” – which triggers the malformed query and logs the error. The page itself still displays correctly; it’s just noise in the log.

    As for why this happens only on one site and multiple times a day without any visitors in your stats: it’s likely the work of search-engine crawlers and bots, who aren’t recorded by your stats package. The key factor is that when you deleted and recreated those albums, their URLs (slugs) changed. Any old links that crawlers had saved now direct to non-existent names, prompting bots to retry them, which logs these lines.

    To confirm, you can check your raw server access log via your host’s control panel at the same timestamps as the SQL errors. You should see a bot requesting an album page with a value that isn’t currently valid.

    It’s worth mentioning that nothing’s broken, and no data is at risk. These are cosmetics due to outdated bot requests, and they will fade as crawlers re-index your new album URLs. I’ve reported this behavior to our development team for a future update that will handle these unresolved album requests quietly.

    If you’d like, I can suggest a snippet or redirect to address the old URLs sooner – just let me know.

    Best,
    Mihai

    Thread Starter mbsharp

    (@mbsharp)

    Thanks for the detailed explanation.

    On all my sites I have year pages, each with one album, and I keep a rolling set of 5 year pages. It could happen that I delete the oldest album but forget to delete the oldest page, so the page exists with an invalid album reference, even if the page is not in the menu. But that isn’t currently the case with any site.

    All the sites work fine for normal users. Hopefully the crawler errors will gradually cease.

Viewing 2 replies - 1 through 2 (of 2 total)

You must be logged in to reply to this topic.