Checkbox displays wrong value directly after saving, db = ok

[ankedsgn]

Hi, some odd behaviour with the checkbox in 2.2.19. This occurred after the fix in #4869

Steps to reproduce:

• In entry, checkbox is 0.
• Set it to 1.
• Save the entry
• checkbox resets to 0 on screen. (but is correctly set to 1 in DB)
• reloading the page displays correct setting, 1.

(other way around is no problem:

• set from 1 to 0
• save
• still 0.
  )

---

• Relevant Bolt Version: 2.2.19
• browsers: chrome, FF

[bobdenotter]

Ping @rarila: My guess is that this is a quirk where the fields are 'reset' after saving. Could you look into this?

[rarila]

@bobdenotter will check that later. Just as a reminder changing that on that line from (item == "on") to item === '1' should fix that on 2.x.

v3 is another story…

[ankedsgn]

Thanks! Fixed in 2.2.19-pl1, already put on clients website, and works like a charm. :)

[GwendolenLynch]

👍

[ToBe998]

Still broken in 2.2.19-pl1.

Reloading a page is now working, but just pressing "save" still does reset the checkbox.

[bobdenotter]

@ToBe998: Have you done a hard-refresh and/or cleared your browser's cache?

[ToBe998]

Tested in Chrome 49 even uncached.

1. Load page in editor
2. Check checkox
3. Press Save -> Unchecked again - Error
4. Reload page (or freshly open a page with a checked box -> Checked - Ok

[bobdenotter]

"Unchecked again - Error"

Error? What error does it give?

[ToBe998]

No sorry. The error i meant is "The checkbox state is unchecked but should be checked" .

[bobdenotter]

@ToBe998 I can't reproduce this..

My CT:

dummies:
    name: Dummies
    singular_name: Dummy
    fields:
        title:
            type: text
            class: large
            group: content
        slug:
            type: slug
            uses: title
        check1:
            type: checkbox
        check2:
            type: checkbox
        check3:
            type: checkbox
        check4:
            type: checkbox

Setting them is reflected in the frontend.. for example:

Then, changing them: (and saving, and reloading too)

So, i don't see an issue with this.. Are you sure you're up to date with your Bolt version?

[ToBe998]

The error happens when you click "Save" without reloading the page. The checkbox state is changed to "unchecked" but stored correctly. So a real page refresh shows the correct state, but just changing to "checked" and clicking "Save" changes it back to "unchecked".

[bobdenotter]

@ToBe998: Sorry mate, still can't reproduce. (or am not understanding you correctly..) See this short video:

http://recordit.co/jTznOJZARX

[ToBe998]

Very strange. That video shows exactly my case but works. I'll try to get more info for reproduction. But yes at this time, i cant see enough evidence to reopen this ticket. Damn! ;)

[ToBe998]

Short summary of my current state:

• I updated to 2.2.20
• added the contenttype exactly as shown above
• All extensions removed
• I completely replicate what is shown in the video

Still same error. A click on save (not reloading the page) sets all checkboxes to "unchecked" no matter what state they had on last reload.

Bolt 2.2.19-pl1 and 2.2.20
MySQL 5.6.26-74.0
Apache/2.4.6 (CentOS)
Chrome 49

[bobdenotter]

@ToBe998 I did some more testing, on MySQL and PHP 5.3 and 5.6, and in all cases it works as expected. So, i still cannot reproduce the issue you're having.

[ToBe998]

@bobdenotter can you give me some hints on the javascript function that executes the ajax request on save and the part that set's checkbox states. Maybe i can debug that issue myself then and hopefully provide some more insights.

[benedikt-roth]

The logic that is being applied in editcontent.js:298 is perfectly fine.

The problem is that if the bolt.min.js is being updated, you will need to copy that file to you ./public/bolt-public/view/js folder.

Solution:

$ cp vendor/bolt/bolt/app/src/view public/bolt-public/view

@bobdenotter What is the intended workflow to keep those two folders in sync?

Best,
Benedikt

[SvanteRichter]

@rossgardt: IIRC those files should be auto-copied/updated when updating bolt... But as @bobdenotter is on vacation ( 😄 ) the real explanation might take a little while unless someone else has a good explanation?

[GwendolenLynch]

That is correct, @SahAssar. When Bolt detects a version change it will sync the view/ directory if it doesn't match Bolt's git path.

If you install via-archive or composer install-project they should be present.

[ToBe998]

The project was originally installed via composer require but did not update anything after a much later composer update. Maybe some script hook inside the composer.json is missing?

[GwendolenLynch]

Ah, cool. OK, well this is the "magic" required in the root composer.json file:

    "scripts": {
        "post-install-cmd": [
            "Bolt\\Composer\\ScriptHandler::installAssets"
        ],
        "post-update-cmd": [
            "Bolt\\Composer\\ScriptHandler::installAssets"
        ],
        "post-create-project-cmd": [
            "Bolt\\Composer\\ScriptHandler::configureProject",
            "Bolt\\Composer\\ScriptHandler::installThemesAndFiles",
            "nut extensions:setup"
        ]
    },

[ToBe998]

This seems to be the problem for our Bolt 3 instances, but it looks like the bolt2 composer.json does not provide such a hook, right?

This is same file in the bolt 2.2 repo:

    "scripts": {
        "post-create-project-cmd": [
            "Bolt\\Composer\\ScriptHandler::bootstrap"
        ]
    },

The Bolt 2.2 ScriptHandler has a ScriptHandler::installAssets command though. Maybe just add that as in Bolt 3?

[GwendolenLynch]

That is correct. It was added in 3.0-dev to try and get the behaviour consistent and predictable across all install types.

[GwendolenLynch]

PRed an update to docs bolt/docs#430