Skip to content

Refuse to open projects with hacked arguments until a fix is implemented #1882

Open
@towerofnix

Description

@towerofnix

It's already a known issue that projects with hacked arguments successfully open, but do so in a very bad way -- each field that contained a block in 2.0 instead contains the stringified array representing the block.

In 2.0, the blocks "when green flag clicked: say ((join 'vol' 'ume') of 'stage')

In 3.0, the blocks "when green flag clicked: say ('concatenate:with:,vol,ume' of 'stage')

While the long-term fix to this is to implement support for these hacked arguments, the code for that might not be implemented in the neartime future.

With the release of Scratch 3.0, a problem arises: if somebody opens a project they made which used hacked blocks, they will (sooner or later) see that the project doesn't work properly. So they'll likely make changes to the project blocks in order to debug the problem. In doing so, the project will autosave, overwriting the existing 2.0 project, causing the user to lose the ability to recover their project's hacked blocks (by opening it in 2.0).

I think there's a tool that the Scratch Team can use for recovering old versions of projects, but this isn't public, so there might be considerable manual work for Scratch Team moderators who get requests to restore old versions of projects.

As a temporary fix, I'm suggesting that these projects should fail to open in Scratch 3.0 until there is an implementation for hacked arguments.

(Not sure if this issue should go in scratch-parser?)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions