Skip to content

"Stuck" on old commit / changes made through Decap or manually not shown in the CMS #7457

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
charludo opened this issue Apr 16, 2025 · 1 comment
Labels
type: bug code to address defects in shipped code

Comments

@charludo
Copy link

charludo commented Apr 16, 2025

Describe the bug

I have set Decap up with my own Forgejo instance, and initially, everything seemed to work. I can auth through Forgejo, and am then presented with a list of my blogposts. I can edit them or create new ones, and when clicking "publish", the changes/new posts will be committed to the repo, on the correct (and only) branch. (A workflow then publishes these changes, so 1-2 minutes after making any change through Decap, the newly built site is public and accurately reflects these changes.)

The problem: inside decap itself, I am stuck with the "initial" repo state. New posts/commits - whether created through Decap or manually - do not appear. Changes to existing content do not appear. Even manually deleting a post and committing that change, then logging into Decap from a completely fresh device on a previously unused internet connection with any and all caching I can think of disabled.... The post is still there in Decap.

Actually, typing this out, I wonder if Decap might indeed be stuck at the very first commit of my repo. I do not have many commits, so it is a bit hard to verify.

To Reproduce

No idea, sorry.

Expected behavior

Changes made - whether through Decap or manually - are reflected in Decap

Screenshots

Applicable Versions:

  • Decap CMS version: 3.6.2
  • Git provider: Forgejo
  • OS: Linux
  • Browser version Firefox 136
  • Node.JS version: n/a

CMS configuration

backend:
  name: gitea
  repo: me/personal-site
  app_id: [...]
  api_root: https://git.[...]/api/v1
  base_url: https://git.[...]
  auth_endpoint: https://git.[...]/login/oauth/authorize
  branch: main
site_url: https://blog.[...].com
display_url: https://blog.[...].com
media_folder: ""
public_folder: ""
collections:
  - name: "entries" # Used in routes, e.g., /admin/collections/blog
    label: "Entries" # Used in the UI
    folder: "entries" # The path to the folder where the documents are stored
    extension: "md"
    path: "{{slug}}/item"
    format: "yaml-frontmatter"
    media_folder: '.'
    public_folder: '.'
    create: true
    slug: "{{slug}}"
    fields: # The fields for each document, usually in front matter
      - { label: "Title", name: "title", widget: "string" }
      - { label: "Subtitle", name: "subtitle", widget: "string", required: false }
      - { label: "Sort", name: "sort", widget: "number", required: false }
      - { label: "From", name: "from", widget: "string", required: false }
      - { label: "Until", name: "until", widget: "string", required: false }
      - { label: "Collections", name: "collections", widget: "list", required: false }
      - { label: "Body", name: "body", widget: "markdown", required: false }

Additional context

@charludo charludo added the type: bug code to address defects in shipped code label Apr 16, 2025
@charludo
Copy link
Author

Solved. Kinda. It works now, but the underlying cause is not fixed.

Image

This is from the docs. Problem is, it's a lie. After branching off my main branch into a new branch master and removing branch: main from my config, now everything works as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug code to address defects in shipped code
Projects
None yet
Development

No branches or pull requests

1 participant