BUG: Parsing error for textarea that contains markdown source code

[stochastical]

Given the following template:

name: New Blog Post
description: Create a new blog post for your Hugo site.
title: "[New Blog Post] <title>"
labels:
  - new-blog-post
body:
  - type: input
    id: title
    attributes:
      label: Blog Post Title
      description: The title of the blog post.
    validations:
      required: true
  - type: input
    id: date
    attributes:
      label: Post Date
      description: Date of the blog post in YYYY-MM-DD format.
      placeholder: "2025-01-01"
    validations:
      required: true
  - type: textarea
    id: description
    attributes:
      label: Description
      description: A short description of the blog post.
    validations:
      required: true
  - type: input
    id: link
    attributes:
      label: Link
      description: The external link.
      placeholder: "https://www.youtube.com/embed/example"
    validations:
      required: false
  - type: textarea
    id: content
    attributes:
      label: Additional Content
      description: Add the content for the blog post.
    validations:
      required: false

and the following example Issue:

### Blog Post Title

Test blog post via `Actions`!

### Post Date

2025-01-01

### Description

This is a test to see if I can create new blog posts via a GitHub Issue Template!

### Link

None

### Additional Content

Testing that I can include ==Markdown== **here**!

And I get a nice editor on [GitHub.com](github.com)!! With a GFM Preview!

# Header 1

Header 1 content that should be in the `content` field

## Header 2

Header 2 content that should be in the `content` field

- [ ] Example todo

### Header 3

Header 3 content that should be in the `content` field

the parsed JSON looks like

{
    "title": "Test blog post via `Actions`!",
    "date": "2025-01-01",
    "description": "This is a test to see if I can create new blog posts via a GitHub Issue Template!",
    "content": "Testing that I can include ==Markdown== **here**!\n\nAnd I get a nice editor on [GitHub.com](github.com)!! With a GFM Preview!\n\n# Header 1\n\nHeader 1 content that should be in the `content` field\n\n## Header 2\n\nHeader 2 content that should be in the `content` field\n- [ ] Example todo",
    "header_3": "Header 3 content that should be in the `content` field"
}

we can see it's

1. Missing the link field
2. Created a new header_3 field instead of preserving it inside of content

That is, the expected output should be:

{
    "title": "Test blog post via `Actions`!",
    "date": "2025-01-01",
    "description": "This is a test to see if I can create new blog posts via a GitHub Issue Template!",
    "link":'',
    "content": "Testing that I can include ==Markdown== **here**!\n\nAnd I get a nice editor on [GitHub.com](github.com)!! With a GFM Preview!\n\n# Header 1\n\nHeader 1 content that should be in the `content` field\n\n## Header 2\n\nHeader 2 content that should be in the `content` field\n- [ ] Example todo\n\n### Header 3\n\nHeader 3 content that should be in the `content` field",
}

[ncalteen]

I didn't think to account for markdown being included in a response, so I can can definitely see where this is going wrong there. I will make some tweaks to handle that :)

The only issue I see coming up is the header_3 field example. In that case, I will need to ignore any "fields" that are not in the issue form template, and join them with the preceding, valid field.

[ncalteen]

BTW I love the idea of using issue forms to generate blog posts. If you ever decide to open source that project, I'd love to share it! I'm working on some documentation around IssueOps, and it would make a cool use case :)

[stochastical]

I didn't think to account for markdown being included in a response, so I can can definitely see where this is going wrong there. I will make some tweaks to handle that :)

The only issue I see coming up is the header_3 field example. In that case, I will need to ignore any "fields" that are not in the issue form template, and join them with the preceding, valid field.

Awesome, thank you!

I was imagining you could have behaviour that varies depending on whether a template file was provided or not.
If it is, I'd consider the Issue Form Template file to be the "schema", in which case it makes sense to parse strictly based on the headings in the template.

If no Issue Form Template file is passed as an argument, you could parse with the current behaviour..

[stochastical]

BTW I love the idea of using issue forms to generate blog posts. If you ever decide to open source that project, I'd love to share it! I'm working on some documentation around IssueOps, and it would make a cool use case :)

I've implemented it so far in a very primitive way! I'm effectively just parsing the issue template, and then populating a .md file which is built with Hugo automatically via Cloudflare Pages.

Here's the source code for my site and I've attached an "architecture diagram" below. I'm starting a "linkblog" and wanted to be able to add posts easily from my phone.

This way, I get a nice Markdown GUI on my mobile and I can even copy images in and use GitHub as a CDN (of sorts) 😉

I intend to flesh this out more, but as a quick-and-dirty approach it does the trick! I'd be keen to hear any suggestions though!

See an example Issue here: stochastical/abstractnonsense#6

---
config:
  look: classic
  theme: default
---
flowchart TD
  subgraph github["Github"]
    source["Static assets and code"]
    cfPages["Cloudflare Pages"]
    actions["Action worflow"]
    issue["Issue Form"]

    issue -- triggers on creation --> actions
    actions -. commits new Hugo post .-> source
    cfPages -- watches --> source
  end
  subgraph cloudflare["Cloudflare abstractnonsense.xyz"]
    domain(["Domain registrar"])
    builder["Runner"]
    cdn["CDN"]

    domain -- DNS records --> cdn
    builder -- deploys --> cdn
  end

  cfPages -- builds with Hugo --> builder
  source@{ shape: db}
  cfPages@{ shape: card}
  actions@{ shape: card}
  issue@{ shape: tag-proc}
  cdn@{ shape: disk}
  builder@{ shape: braces}
   source:::Sky
   cfPages:::Sky
   actions:::Sky
   issue:::Sky
   cdn:::Peach
   domain:::Peach

  classDef Peach stroke-width:1px, stroke-dasharray:none, stroke:#FBB35A, fill:#FFEFDB, color:#8F632D
  classDef Sky stroke-width:1px, stroke-dasharray:none, stroke:#374D7C, fill:#E2EBFF, color:#374D7C
  style cdn stroke:#FF6D00
  style domain stroke:#FF6D00
  style builder stroke:#FF6D00
  style github fill:#BBDEFB,stroke:#424242
  style cloudflare fill:#FFE0B2,stroke:#FF6D00

Loading

[ncalteen]

I was imagining you could have behaviour that varies depending on whether a template file was provided or not. If it is, I'd consider the Issue Form Template file to be the "schema", in which case it makes sense to parse strictly based on the headings in the template.

If no Issue Form Template file is passed as an argument, you could parse with the current behaviour..

Yeah I think this is the best way to go. Unfortunately without the form template there's no way to know what headers should or shouldn't be included as separate fields. I will go ahead and work on this!