Fix Magefan Blog 2.15 / PHP 8.4 compatibility in fulltext collection

[nige-one]

Problem

Magefan Blog 2.15.x declares getStoreId(): int on Magefan\Blog\Model\ResourceModel\Post\Collection. The override in Comwrap\ElasticsuiteBlog\Model\ResourceModel\Post\Fulltext\Collection has no return type, so the class fails to load with a fatal signature-compatibility error (related: #27).

Additionally, PHP 8.4 deprecates implicitly nullable parameters, which affects the $connection/$resource constructor parameters.

Why not just cast (as in #26)?

Simply declaring getStoreId(): int is not enough: on catalogsearch_result_index the collection is built without setStoreId() being called, so $this->storeId is null.

• Returning null under the : int signature → TypeError, search page returns HTTP 500.
• Casting to (int) (i.e. store 0, as proposed in Fix incompatibile methods declaration #26) → the Elasticsuite request builder resolves the blog_post/second_blog_post index alias for store 0, which does not exist. The resulting LogicException ("blog_post index does not exist yet. Make sure everything is reindexed.") is swallowed by the block, so blog results silently disappear from search and each search request writes ~285 lines of exception traces to the log. (Measured on Magento 2.4.8-p5 / PHP 8.4 / Magefan Blog 2.15.1.)

Fix

Fall back to the current store from the store manager when no store filter was set. This queries the correct per-store index and produces the same results as an explicit setStoreId() call:

public function getStoreId(): int
{
    if ($this->storeId === null) {
        $this->storeId = (int) $this->_storeManager->getStore()->getId();
    }

    return (int) $this->storeId;
}

Both changes are running in production on Magento 2.4.8-p5 with PHP 8.4, Magefan Blog 2.15.1 and Smile Elasticsuite: search returns 200 on all store views with blog results present and no new log entries.