Skip to content

Search Engine Libraries in Titania #401

Description

@Skouat

Hi Team,

I’m opening this issue to discuss the message posted by @iMattPro in this GitHub comment:

This makes me think we should also remove "Zend" as a search engine, then that would allow us to delete the zend and ezcomponents junk in includes/library.

Currently, Titania supports three extra search engines:

  • Sphinx
  • Solr
  • Zend

However, all of these are either outdated or abandoned. Below is a summary of their current status:

Sphinx

  • Currently used via the phpBB Sphinx API.
  • The API itself is outdated and may require an update or replacement.

Solr

  • The current library relies on EzComponents, which is outdated.
  • A potential workaround is available using the Zeta Components Composer package: Zeta Components Search.

Zend

  • The current library uses the Zend Framework, which has been abandoned and replaced by the Laminas Project.
  • Unfortunately, I couldn’t find a replacement library within the Laminas Project for this functionality.

Let’s discuss how we want to proceed with these search engines. Should we explore replacing them, updating their dependencies, or consider removing some altogether?

Looking forward to your thoughts!

Activity

  1. changed the title [-]Titania and search engine?[/-] [+]Search Engine Libraries in Titania[/+] on Jun 2, 2025
  2. iMattPro commented on Apr 4, 2026

    @iMattPro
    Member

    Well, the search facilities appear to be completely broken now - just try searching a contrib's discussion/support forum and you'll see.

    The current options are all painful and should be removed IMO:

    Sphinx — requires a separate daemon, manual config generation, manual index rebuilds via CLI, doesn't store text fields (requiring the DB re-fetch), and has a 20000000/10000000 id offset hack.

    Zend— abandoned for years, stores indexes as files on disk, has a compound id bug, and has poor relevance.

    Solr — requires a separate Java server. Even higher burden than Sphinx.

    The alternative: a MySQL fulltext driver

    Titania already has a clean driver_interface. Writing a new driver backed by MySQL FULLTEXT indexes would:

    • Require zero additional infrastructure — MySQL is already there
    • Be trivially maintainable — no daemons, no CLI rebuilds, no separate config
    • Store and return all fields directly (no DB re-fetch needed)
    • Work correctly immediately after any DB change, since it IS the DB

    The implementation would be straightforward — FULLTEXT indexes on the titania posts/contribs/faqs tables, MATCH(...) AGAINST(... IN BOOLEAN MODE) queries, results returned with all fields intact. The index() and delete() methods become obsolete since MySQL maintains the fulltext index automatically. The reindex tool's truncate/index steps also become obsolete.

  3. ECYaz commented on Jul 30, 2026

    @ECYaz
    Contributor

    Is the MySQL fulltext driver still the way you want to go with this? I will give it a try if so.

  4. iMattPro commented on Jul 30, 2026

    @iMattPro
    Member

    I actually think this issue is no longer an issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions