Skip to content
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

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

Open
towerofnix opened this issue Dec 30, 2018 · 5 comments
Open

Comments

@towerofnix
Copy link
Contributor

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?)

@thisandagain
Copy link
Contributor

Thanks for raising this @towerofnix. I'd like to discuss this with the team and we'll post a response here.

@Alzter
Copy link

Alzter commented Jan 2, 2019

Please, please do this. Some great projects have been made with hacked blocks and they flat out don't work in 3.0. If they are able to be viewed and edited, they could be saved by the creator and that would permanently break the project even if a patch is later released.

My proposal for how we should go about fixing hacked blocks is to just make most of them work without hacking. Straight up removing hacked blocks limits the creative potential of projects and lowers the roof of how much can be achieved with the program.

@apple502j
Copy link
Contributor

apple502j commented Jan 2, 2019

Plz implement this within 2 hours, if possible.
Or, at least give us an option to download 2.0 project without opening 3.0 editor.

@towerofnix
Copy link
Contributor Author

@apple502j Unfortunately they're likely very prioritized with the release of 3.0 and so don't have time to work on any non-criticial issues - and while you could say this is critical in that it will be the reason some projects break, it's safe to say it won't affect the majority of Scratch users, and so it doesn't block the release of 3.0.

That said, you can use this long-standing community-made tool to create a backup of projects without opening them in 3.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants