Page Path History Manager

[bfncs]

If you are using the great PagePathHistory module in core, this one might be helpful:

Page Path History Manager

https://github.com/boundaryfunctions/PagePathHistoryManager

General

This modules allows you to easily manage past page URLs tracked with the PagePathHistory module.

It extends the settings tab on the page edit form in the backend and allows you to:

• view past URLs of the current page and parent pages,
• delete past URLs, and
• create new fallback URLs.

How to use

Use the form in the settings tab on the page edit form of every page in admin to view and manipulate past URLs. See Screenshots to get a better idea of what you can do.

Installation

1. Install the module PagePathHistory from within the Processwire admin. PagePathHistory is included in core but not installed by default.
2. Grab the module from its Github repository.
3. Install this module from within the Processwire admin or copy the file content to/site/modules/PagePathHistoryManager.
4. In Admin, click Modules → Check for new modules to refresh module directory. Afterwards install the newly registered module PagePathHistoryManager.
5. You can now manage past URLs from within the settings tab when editing any page.

Screenshots

Notes

This module doesn't install or require PagePathHistory because I'm currently working with a fork of it that is language sensitive. I'll try to publish this one here as well, but I'm not done with final testing.

Links

You can grab this Module from Github:

• Source
• Releases
• Download latest release

I would be glad if some of you could give this module a quick test drive and comment with some feedback here.

[Soma]

Thanks for making this, great idea that comes in handy.

Just for code:

At a first glance at the code, why does it have to be a Process module that is autoload? 

Not sure but I think implement Module isn't necessary as Process class already has that?

Instead of this:

public function install()
    {
        parent::___install();

        /* Create manager page */
        if (!count($this->pages->find('name=' . __CLASS__))) {
            $p = new Page();
            $p->template = $this->templates->get('admin');
            $p->title = 'Page Path History Manager';
            $p->name = __CLASS__;
            $p->parent = $this->pages->get(3); // Create as children of /admin/pages
            $p->status = Page::statusHidden | Page::statusSystem; // Hide in menu and prevent deletion
            $p->process = $this;
            $p->save();
        }
    }

You can also do now

public static function getModuleInfo() {
    return array(
        'title' => '',
        'page' => array(            // optionally install/uninstall a page for this process automatically
            'name' => 'page-name',  // name of page to create
            'parent' => 'setup',    // parent name (under admin) or omit or blank to assume admin root
            'title' => 'Title',     // title of page, or omit to use the title already specified above
            )
        ),
...

[Soma]

Seems to work great here. Awesome tool! Thanks.

[bfncs]

Hey Soma,

that was quick, thanks a lot for giving it a try!

At a first glance at the code, why does it have to be a Process module that is autoload? 

That's actually a very good question, the answer is probably that I got somewhat stuck in a rut while working on the module. It would probably be better to split this into two modules: PagePathHistoryManager to hook into the settings form and ProcessPagePathHistoryManager to provide the URLs for the process.

Not sure but I think implement Module isn't necessary as Process class already has that?

Absolutely right, didn't know that until now, thanks for pointing it out!

Instead of this: [...]

You can also do now: [...]

The next thing that I missed because I didn't follow closely. Processwire development is as always rapid and brings really great improvements.

Edit: I've been looking for this, but didn't find the place where this new behavior is documented. Could you please point me to the correct ressource? If I get it right, it is not possible to set the status of the newly created page this way, is this correct?

It's too late for today, but I'm going to add all this in the module tomorrow. Thanks a lot for the review!

Edited March 20, 2015 by boundaryfunctions

[bfncs]

Thanks again for your review, Soma. I just uploaded a new release that should solve the problems you mentioned.

The module has now been split into two distinct modules, one autoloaded and the other for the process. That also means that if you already had the first version of the module installed, you will have to either uninstall it before the update and reinstall it afterwards or have to manually install the newly added submodule ProcessPagePathHistoryManager.

Edited March 20, 2015 by boundaryfunctions

[Soma]

My example is right from Process.php comments. Not sure about status.

[ceberlin]

Nice module, thank you. Interesting to see the old links.

If you have a lot of links to remove, it can be a lot of click-click to get rid of them one by one individually. What about checkboxes and only one button?

[bfncs]

Thanks a lot for your comments.

My example is right from Process.php comments. Not sure about status.

Looking at the code of Process::___installPage() showed that there currently is no possibility to set the page status using the descriptive way to set up a page. Thanks anyway, knowing about this will come in handy soon enough, really saves some repetitious copy-paste work.

If you have a lot of links to remove, it can be a lot of click-click to get rid of them one by one individually. What about checkboxes and only one button?

I already though about this myself but shirked from the duty of implementing it for the first release. But you're absolutely right, sooner or later this will be needed, so thanks for pointing it out. I've already added an issue for this feature and will implement it during the next days.

There's one other thing that has been corrected in the current development version of the module and this is proper handling of URLs with non name-format characters (all characters but -_.a-zA-Z0-9/~), i.e. to redirect content from a legacy website. Due to the way Processwire currently handles these URLs, you will have to edit youR .htaccess file to enable this functionality. I added a short description of what has to be done to the module's README and issued a pull request on core to make the need for manual modifications obsolete in the future – let's see how this turns out.

[dotnetic]

This module does not work with ProcessWire 3.0.x. If you try to edit a page "The process returned no content" appears (translated from german).

Must have to do with the hooks not returning correctly. Sadly the README on github says, that this module is no longer maintained.

[Jan Romero]

On 4/4/2018 at 2:16 PM, Jens Martsch - dotnetic said:

This module does not work with ProcessWire 3.0.x. If you try to edit a page "The process returned no content" appears (translated from german).

Must have to do with the hooks not returning correctly. Sadly the README on github says, that this module is no longer maintained.

Indeed. I just upgraded an old site from 2.7.2, *cough*, and MySQL complained about some query on the edit page. Turns out this module failed to get the name of the path history table, and then it just goes “from  where pages_id”. The problem appears to be that it uses constant() to get PagePathHistory::dbTableName, but that has long since moved into the namespace ProcessWire.

It seems to work fine once you remove line 74 here and replace it with:

$this->dbTableName = $this->wire('modules')->getModule($moduleName)::dbTableName;

At least, that’s the quickest fix.

Sorry for unearthing this old thread…