Posts by Tobbe

    I assume you created your own custom url and used a not-supported feature. For example, using the id in your own slug has a bug:

    Workaround until this is fixed: Change the url of your blog posts to not contain the id or manually edit the file to try out my (untested) solution if you feel confident enough. But remember to backup the file, first.

    Best regards,


    Hi Ben ,

    sorry. I cannot say anything about a release date. There is a lot of things I need to do for my normal work so that I cannot give any outlook :( I can just tell that I did not stop my work on the extension and I am also not happy that there is no Alpha or beta version available, yet.

    Best regards,


    The installed version of the extension is also stored in one of the system tables (I have no db to check which one now). This is used to check whether the upgrade script shall be executed. So, you can modify this value or simply do what you did (install the old version). However, installing the old version will fail as soon as the migration was done, as the database will not be adjusted. Then, you need to uninstall and install again.

    WARNING: Use this extension only if your website also works without the index.php in urls!

    Seems that this wasn't clear enough :/

    The extension only enforces the usage of short urls if you can use them, but pagekit does not recognize that MOD_REWRITE is enabled.

    Since Pagekit 1.0.12 the usage of my extension should not be necessary in most of the cases as one of the main reason this issue occurred was fixed (

    For your situation there seems to be another issue: MOD_REWRITE is not enabled at all or has incorrect settings as rewriting is not working. You should check this first.

    I created one theme some time ago where I was annoyed by the necessity to always include the files. So I created some settings to enable specific uikit components. This setting can be done either for the whole page or for only specific parts of the page. You can find the source attached to this post (however, I removed most of the view templates as well as the style sheets, so you cannot just upload it and use it).

    Maybe it's helpful :)


    What should be possible is to copy all files on file system level and additionally copy the database.

    If you install the exact same Pagekit version and version of the addons / themes, it should also be possible to just copy the database content,

    I will dive into this and whether it can be fixed in Pagekit once I have some more time. So might be that this is no issue anymore in a future version of Pagekit. But I cannot promis anything :)

    It is a bug :/

    I did some more debugging. During the update process the update scripts are never called. This is due to the name change of the function.

    Clicking on update (or install) calls admin/system/package/install , this is mapped to the installAction of the PackageController located in app/installer/src/Controller. This step then calls the install function of the PackageManager. There it is checked whether a module with the same name is already loaded. As your module changed it's name, only the old module is loaded and to the system it seems that your module is completely new. Thus, the update functions are not called.

    The question now is whether it is possible to solve this, as for the system there is no relation between your old package and the new one. If it is only about the config, this is not that bad, but as soon as you have also other update scripts, they are also not called. The only thing which will be called are the install scripts, so as long as there is no solution in pagekit itself it is at least possible to hack into them. But I don't know about side effects if you create tables etc. So might be that you will face further issues if you change the name and create your own tables.

    Code responsible for this:

    1.         foreach ($install as $name => $version) {
    2. if (isset($packages[$name]) && App::module($packages[$name]->get('module'))) {
    3. $this->enable($packages[$name]);
    4. } elseif (isset($packages[$name])) {
    5. $this->doInstall($packages[$name]);
    6. }
    7. }

    I cannot debug at the moment, but I think the issue is different. From what I see in the coding, pagekit tries to load the extension module which is not available anymore. This then throws the error.

    The config itself is kind of stupid and only handles values in a database. The config does not care about the renaming.

    What I assume happens:

    1. During startup, pagekit registers all extensions for which a config exists:…38/app/system/app.php#L12
    2. This then adds the extensions to an internal array in the ModuleManager:…le/ModuleManager.php#L137
    3. Then the system module is loaded:…op/app/system/app.php#L22
    4. During loading of the system module, also all other extensions are loaded based on the config:…/src/SystemModule.php#L55
    5. During loading of the extension module it is recognized that this module does not exist anymore and the error is thrown:…le/ModuleManager.php#L105
    6. This then is logged:…/src/SystemModule.php#L58

    So, this should not have an influence on the behavior of the update. The issue seems to be somewhere else. I assume it is during the upgrade process of the extension that something is not working properly.

    Is this the same for all extensions or only for some?

    You can try to debug it if possible to see in which line it exactly fails and what is the content of the config at this moment. Maybe there is a trivial reason for this (spelling etc.).