Project

General

Profile

Actions

Bug #87759

open

Record preview fails when the record is disabled or before starttime because of routing

Added by Daniel Dorndorf almost 6 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Must have
Assignee:
-
Category:
Site Handling, Site Sets & Routing
Start date:
2019-02-21
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
9
PHP Version:
7.2
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

If I configure a preview button for a record leading to a routed detailpage the preview fails when the record is disabled or hidden by starttime.

It seems routing is unable to fetch the records slug because of a query restriction, this leads the preview running into a 404 error.

Greetings
Daniel


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #88307: Detail pages showing hidden data records are not accessible (PersistedAliasMapper route enhancer)Closed2019-05-08

Actions
Actions #1

Updated by Benni Mack over 5 years ago

  • Target version changed from next-patchlevel to Candidate for patchlevel
Actions #2

Updated by Wolfgang Wagner over 5 years ago

Can confirm this error in TYPO3 9.5.7 and EXT:news

Actions #3

Updated by Markus Bischof over 5 years ago

The same error here with a custom extension that should be able to show hidden records under some special cirucmstances.

Actions #4

Updated by Markus Bischof over 5 years ago

As a workaround I created a custom AliasMapper

<?php
declare(strict_types = 1);

namespace Hirnschmalz\Custom\Routing\Aspect;

/*
 * This file is part of the TYPO3 CMS project.
 *
 * It is free software; you can redistribute it and/or modify it under
 * the terms of the GNU General Public License, either version 2
 * of the License, or any later version.
 *
 * For the full copyright and license information, please read the
 * LICENSE.txt file that was distributed with this source code.
 *
 * The TYPO3 project - inspiring people to share!
 */

use TYPO3\CMS\Core\Database\ConnectionPool;
use TYPO3\CMS\Core\Database\Query\QueryBuilder;
use TYPO3\CMS\Core\Database\Query\Restriction\DeletedRestriction;
use TYPO3\CMS\Core\Routing\Aspect\PersistedAliasMapper;
use TYPO3\CMS\Core\Routing\Aspect\PersistenceDelegate;
use TYPO3\CMS\Core\Site\SiteLanguageAwareTrait;
use TYPO3\CMS\Core\Utility\GeneralUtility;

class DesPersistedAliasMapper extends PersistedAliasMapper
{
    use SiteLanguageAwareTrait;

    /**
     * @var bool
     */
    protected $ignoreEnablefields;

    /**
     * @param array $settings
     * @throws \InvalidArgumentException
     */
    public function __construct(array $settings)
    {
        parent::__construct($settings);
        $ignoreEnablefields = $settings['ignoreEnablefields'] ?? false;
        $this->ignoreEnablefields = $ignoreEnablefields;
    }

    /**
     * @return PersistenceDelegate
     */
    protected function getPersistenceDelegate(): PersistenceDelegate
    {
        if ($this->persistenceDelegate !== null) {
            return $this->persistenceDelegate;
        }
        $queryBuilder = GeneralUtility::makeInstance(ConnectionPool::class)
            ->getQueryBuilderForTable($this->tableName)
            ->from($this->tableName);

        if ($this->ignoreEnablefields) {
            $queryBuilder
                ->getRestrictions()
                ->removeAll()
                ->add(GeneralUtility::makeInstance(DeletedRestriction::class));
        }

        $resolveModifier = function (QueryBuilder $queryBuilder, array $values) {
            return $queryBuilder->select(...$this->persistenceFieldNames)->where(
                ...$this->createFieldConstraints($queryBuilder, $values)
            );
        };
        $generateModifier = function (QueryBuilder $queryBuilder, array $values) {
            return $queryBuilder->select(...$this->persistenceFieldNames)->where(
                ...$this->createFieldConstraints($queryBuilder, $values)
            );
        };

        return $this->persistenceDelegate = new PersistenceDelegate(
            $queryBuilder,
            $resolveModifier,
            $generateModifier
        );
    }
}

Now it's possible to do something like

    aspects:
      custom_title:
        type: HirnschmalzPersistedAliasMapper
        tableName: tx_custom_domain_model_test
        routeFieldName: path_segment
        routeValuePrefix: ''
        ignoreEnablefields: true

Actions #5

Updated by Georg Ringer almost 5 years ago

  • Related to Bug #88307: Detail pages showing hidden data records are not accessible (PersistedAliasMapper route enhancer) added
Actions #6

Updated by Georg Ringer almost 5 years ago

1st attempt to solve with #88307

Actions #7

Updated by Benni Mack over 4 years ago

  • Status changed from New to Needs Feedback

Is this now solved with 9.5.18?

Actions #8

Updated by Steffen Hastädt over 4 years ago

This is still a problem in 9.5.20

Actions #9

Updated by Riccardo De Contardi over 4 years ago

  • Status changed from Needs Feedback to New
Actions #10

Updated by Dennis Prinse almost 4 years ago

I can confirm this is still an issue in TYPO3 v10.4.12 for records as well as pages.

Hidden records and pages aren't the issue if they are hidden by using the `hidden` field. However, if the record is hidden because of a future start date, the editor is being send to the rootpage with the `ADMCMD_simTime=` parameter from within the pages and list modules if using the buttons in the docheader (both the view button from within the properties view as well as the view button in the page view), in the languages view for each translation or a list item. If the editor uses the context menu from within the pagetree, they are being send to the correct url and with the `ADMCMD_simTime=` parameter, however they end up at an error page (404 or 403 for example).

As a nasty workaround, the editors can remove the starttime and set the page to be hidden to be able to preview its content while still editing. If they are ready and satisfied with the result, they can set back the starttime and set the page to be visible so the page is enabled at the right time. However this is not a working solution, because if they have to make some more adjustments later on they have to repeat those steps again.

Additional information:
Where the view page module in TYPO3 v9 was working as a workaround too, the view page module in v10 has the same issues as using the docheader buttons and list module where te user is being send to the homepage.

Actions

Also available in: Atom PDF