"Invalid Requests" from Quill/IA Writer to Kirby about kirby3-micropublisher HOT 5 CLOSED

Hi! Thank you for the verbose documentation of the problems; this allows to go straight to their root 🙂 We are looking at a few separate issues here.

Missing slug

I believe that the slug problem should go away once you replace

'sgkirby.micropublisher.default.slug' => 'default-slug',

with

'sgkirby.micropublisher.default.slug' => 'slug',

This setting is admittedly rather abstract, but the idea is that 'slug' tells the endpoint to use a submitted mp-slug property as the post's slug. 'default-slug' is not a valid value for this config field.

Missing tags

Your config is correct on this part. But do you have the field tags set up in your note blueprint? If not, I believe that Kirby would not be able to store any data in it. I.e. you'd have to set up the tags field in the blueprint first, then this should work.

The Quill error

Quill is brilliant for testing micropub endpoints thanks to its output of the returned error. The error you quoted, "The status for this page cannot be changed" indicates that something goes wrong as the newly created post is updated to listed as you configured in your config.

Please try the following:

1. Does this error go away once the slug issue (above) is fixed? This invalid config setting might throw off the process further down the line. This would be great news.
2. Please make sure that the note blueprint does not have an option of changeStatus: false set. A wild shot, I know, but good to rule it out anyways.
3. If it still doesn't work: could you try and see if this problem persists if you change 'sgkirby.micropublisher.default.status' => 'listed', to 'draft'? If not, then I at least know where it goes awry and can investigate from there.

...I have a hunch that the issues with iA Writer are tied to the Quill problems, so we'll get back to those (if needed) once the Quill workflow is up and running. Quill is so much easier to debug with 😉

from kirby3-micropublisher.

Sebastian, thanks so much.

Slug

I realize now that I misinterpreted what 'sgkirby.micropublisher.default.slug' => 'slug', was doing; I thought it was a string (hence, my experiment with "default-slug") rather than an array with ranked rules. It works now, and I've learned my lesson: read the entire documentation. ;P Thanks for being patient there!

Listed / Draft Status

Fixing the slug didn't fix the Quill problems, but the status did! Once I changed 'sgkirby.micropublisher.default.status' => 'listed', to 'sgkirby.micropublisher.default.status' => 'draft', everything went smoothly for both Quill and IA Writer.

Now, when I press publish, they take me straight to the draft page in Kirby. But when I have 'sgkirby.micropublisher.default.status' => 'listed',, or when I have no value at all, I get the "Something went wrong" from Quill and the "Invalid Error" from IA Writer. Quill responded with what I think is the same message as above:

HTTP/1.1 500 Internal Server Error
Date: Sun, 20 Sep 2020 02:42:32 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade, close
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8

{"status":"error","exception":"Kirby\\Exception\\PermissionException","code":"error.page.changeStatus.permission","message":"The status for this page cannot be changed","details":[],"file":"kirby\/src\/Cms\/PageRules.php","line":129}

So I'll leave it in drafts for now–I have a few extra fields I have in my blueprint anyway. But if you have any idea what's happening here, LMK. I'm happy to try other things for the sake of improving the plugin, since this seems to be an issue keeping it from working out-of-the-box.

Tags

Finally, tags. They are still not going through from Quill. You suggested I check the blueprint, and I did. Tags are specified.

  sidebar:
    width: 1/3
    sections:
      meta:
        type: fields
        fields:
          ...
          tags:
            label: "Ideas"
            type: tags

So it should work. My config.php file still has the setting 'category' => [ 'tags', null ], in place. Again, LMK if you'd like me to try something different or have any ideas here.

from kirby3-micropublisher.

Thank you, Bryan, for reporting back and assisting in hunting down the potential roots of these issues!

Great to hear the slug is now working - no worries, I know very well how complex this plugin's setup is (due to the desire to make it as universal as possible, rather than plug-and-play). I will make it more explicit that this is an array, not a string, in the documentation for others' benefit.

Tags

Regarding the missing tags it seems you indeed found a yet undiscovered bug. While it works with my personal site, I was able to reproduce the error on a vanilla Starterkit install. With the help of a few Indiewebbers on IRC (including Aaron, the author of Quill), the culprit has been identified and removed.

I created a test branch that contains a temporary version of the plugin - if you have a minute to test it, that would be highly appreciated! It can be found at https://github.com/sebastiangreger/kirby3-micropublisher/tree/test and the only relevant file that has changed is classes/Micropublisher.php.

You will have to log out of Quill and back in again in order for the changes to take effect (this was about the "capabilities" the plugin reports to Quill, and these are only checked on login). Once you log out and back in again the tags should start working - at least they did in my test environment.

"Listed" status

This one is very tricky for me to track down, as I cannot reproduce the error. When testing this myself, setting the default status to "listed" works just fine on two separate websites. Yet, the error message gives me a clear indication where the processing goes wrong and above test branch includes a small attempt to maybe address a potential issue. If this doesn't help, I'll yet have to dig deeper.

from kirby3-micropublisher.

Sebastian, excellent. That did the trick for the tags. They work like a charm. Many thanks to you and your fellow Indiewebbers.

The "listed" error persists, though. I still get this:

HTTP/1.1 500 Internal Server Error
Date: Sun, 20 Sep 2020 16:53:21 GMT
Server: Apache
Upgrade: h2,h2c
Connection: Upgrade, close
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8

{"status":"error","exception":"Kirby\\Exception\\PermissionException","code":"error.page.changeStatus.permission","message":"The status for this page cannot be changed","details":[],"file":"kirby\/src\/Cms\/PageRules.php","line":129}

Again, what's strange is that it actually does make a listed page within the 1_notes folder, albeit without the date part of the slug (probably because I haven't specified the proper slug prefix). See below, where "test," "test-three," and "three-cheese-enchilada" were all made through Quill with the draft set by default to publish/listed. (If I changed the setting to drafts, it works fine.)

So it makes the file, but without the date prefix and throws me an error.

LMK what you think. Happy to try something else. I'm also happy to see if I do a fresh Kirby install on my server, if I can reproduce it; I can get back to you about that in a couple of days.

from kirby3-micropublisher.

Brilliant -- two down, one to go 🥳

Your screenshot of the 1_notes folder gives me one more idea. It looks like the post is created as unlisted to start with and then the status change to listed is where it fails (the missing "date part" is how Kirby differentiates between "listed" posts -- those with a date or number prefix -- and "unlisted" posts -- those with no prefix).

I tried one more tiny change in an additional commit in the test branch -- again just the classes/Micropublisher.php file. I'd be somewhat surprised if this really fixes it, but go for it if you want to give it a try! (I'm removing one optional attribute as the content file is created ...I frankly never quite understood what is its function anyways -- so maybe that is our troublemaker)

Otherwise we indeed would have to rule out that this "The status for this page cannot be changed" error is caused by collisions with anything else in your setup (which seems increasingly likely, as the plugin indeed works fine with "listed" visibility on my systems). I'm positive it's not about file rights on the server level, as Kirby obviously is happily writing to your disk. But there might be an interference from some plugin or config setting, and a fresh install would help eliminate that.

Myself, on the other hand, would then have to dive deeper into the processes involved in the CMS, maybe by reaching out to the Kirby community.

from kirby3-micropublisher.