Update 6.x->7.1.0, Typo3 v11.5: dysfunctional blog backend module - type error in logic inside extension

[UmbrellaDish]

When entering the backend module "Blog" and selecting the Posts SysFolder in the page-tree, following error shows up.

Type Error (1/1)

Return value of FelixNagel\T3extblog\Domain\Model\PostSubscriber::getPost() must be an instance of FelixNagel\T3extblog\Domain\Model\Post, null returned

[Stack trace following, innermost i.e. top frame in /web/propylaeum/htdocs/public/typo3conf/ext/t3extblog/Classes/Domain/Model/PostSubscriber.php line 108. Tree of pages and and list of modules shown left alright.]

I (believe at least I) fixed pagination so the extension renders blog pages all fine in the frontend. We followed the, if you don't mind my saying, a bit short and summarizing Upgrade guideline in the documentation (Upgrade to 7.0.0). For sure chances are I have just forgotten something but I fail to deduce from the error what is missing. I tried to check that all blog configuration included in our site package extension is up-to-date, but let's include the relevant YAML code here for the sake of completeness, even if it seems to relate to frontend logic, too:

    routes:
      - routePath: '/'
        _controller: 'Subscriber::list'
      - routePath: '/logout'
        _controller: 'Subscriber::logout'
      - routePath: '/error'
        _controller: 'Subscriber::error'
      - routePath: '/post/confirm/{subscription_code}'
        _controller: 'PostSubscriber::confirm'
        _arguments:
          'subscription_code': 'code'
      - routePath: '/post/list/{subscription_code}'
        _controller: 'PostSubscriber::list'
        _arguments:
          'subscription_code': 'code'
      - routePath: '/post/delete/{subscription_uid}'
        _controller: 'PostSubscriber::delete'
        _arguments:
          'subscription_uid': 'subscriber'

We use Typo3 in composer mode, if that is relevant in a way.

[UmbrellaDish]

Follow up: In another Typo3 instance of our sites that has a comparable structure and code base the Blog component could be upgraded successfully to v7.1.0, and is working. As that site had been set up later with lessons already learned, for sure we did not need to make and fix certain errors so the database is probably in a cleaner state. We have yet to endeavor further inspection in the differences that may be relevant for this error to occur.

We then retried an upgrade again for the site where the backend blog module fails. Unfortunately this was to no avail.

[fnagel]

Hi there and sorry for the late response!

Would you please add the related PHP, TYPO3 and extension versions? Thank you!

I (believe at least I) fixed pagination so the extension renders blog pages all fine in the frontend.

Is this about issue #219?

We followed the, if you don't mind my saying, a bit short and summarizing Upgrade guideline in the documentation (Upgrade to 7.0.0).

Any help in improving the docs would be highly appreciated! Feel free to send an PR!

For sure chances are I have just forgotten something but I fail to deduce from the error what is missing. I tried to check that all blog configuration included in our site package extension is up-to-date, but let's include the relevant YAML code here for the sake of completeness, even if it seems to relate to frontend logic, too:

An error in the BE module should not have any relation to the FE routing configuration. To me, this looks more like an issue with the database or to be more exactly: with the property relations between subscriber and post records. Can you check if there is a post subscriber record without a post relation?

Follow up: In another Typo3 instance of our sites that has a comparable structure and code base the Blog component could be upgraded successfully to v7.1.0, and is working. As that site had been set up later with lessons already learned, for sure we did not need to make and fix certain errors so the database is probably in a cleaner state. We have yet to endeavor further inspection in the differences that may be relevant for this error to occur.
We then retried an upgrade again for the site where the backend blog module fails. Unfortunately this was to no avail.

Interesting! Sounds like this is not an issue with the code base but configuration or database content. I assume it might be about missing relations as I explained above. If so, we need to figure out how this happened as we never should have post subscriber records without post relations.

[UmbrellaDish]

Inferred from the general PostSubscriber code and the according TCA, in which a foreign_table_where includes a delete=0 condition (which you might want to re-consider), I have made up bare-to-metal SQL queries like this:

mysql> select nl.post_uid from tx_t3blog_com_nl AS nl join tx_t3blog_post AS p on nl.post_uid = p.uid where p.deleted=1;
+----------+
| post_uid |
+----------+
|        3 |
|        3 |
|        9 |
+----------+
3 rows in set (0,00 sec)

mysql> delete from tx_t3blog_com_nl where post_uid in (3,9);
Query OK, 3 rows affected (0,02 sec)

mysql> select nl.post_uid from tx_t3blog_com_nl AS nl join tx_t3blog_post AS p on nl.post_uid = p.uid where p.deleted=1;
Empty set (0,00 sec)

Still, after flushing all caches in the Typo3 backend, the error persists. The DB abstraction layers are also included in the flush actions, aren't they?

Running PHP 7.4.3, Typo3 11.5.26 and T3ExtBlog 7.1.0

Disclaimer: "Kids do not try that at home!", i.e. do not fiddle with data in the mysql console if there are appropriate means in the Typo3 administrative backend. Unfortunately, comment subscriber records associated to posts with deleted=1 are not displayed in the list module so there was no other way to try that.

[UmbrellaDish]

After deleting all comment subscriber records in the List module, the Blog module finally works. Yet, I doubt it can be regarded as the solution, of course. As said, I'd rather advise considering to remove the first AND part in 'foreign_table_where' => ' AND tx_t3blog_post.deleted = 0 [...] in Configuration/TCA/tx_t3blog_com_nl.php, columns/post_uid/config. At least, the logic behind that is not clear to me. What is the ratio of disassociating comment subscribers from deleted posts? If a post gets deleted, it vanishes from frontend, cannot be commented any more and no comment subscribers would ever be notified.

Sorry, I am not sure I can post a PR in near future.