bug: Can't swap Component (self-hosted)

[haruku08]

Steps To Reproduce

1. Go to assets
2. Drag component on to the canvas
3. Try swap the component

Expected behavior

I expect that a "copy" instance is created when dragging a component asset to the canvas so I can swap the component.

Actual behavior

It's not a copy instance created, as shown in the tutorial video, instead it's create another main asset

Screenshots or video

component-swap-compressed.mp4

Desktop (please complete the following information)

No response

Smartphone (please complete the following information)

No response

Environment (please complete the following information)

No response

Frontend Stack Trace

No response

Backend Stack Trace

No response

Additional context

This problem only occurred with the self-hosted version (tested on two instances).

[BossMBGaming]

I can confirm that this issue only exists in the self-hosted version.
Even in the context menu in the asset library. The option for Duplicate Main is not available.

Image from self-hosted without duplicate main option

I created an account on the penpot.app just to test if it was a global issue or just in the docker/self-hosted version, and I can confirm that it is just self-hosted. (I have been trying to use component swapping for the past 3 days or so (since the self-hosted version of 2.0 was released) and finally decided to try the hosted version and also check the repo to see if anyone had reported this bug). After seeing that it worked on the hosted version (penpot.app), I came to the repo and saw this recently opened issue.

Image from hosted version with duplicate main option

Hope this can be resolved soon, would really love to keep playing around with the long awaited penpot 2.0 features.

[superalex]

Hello @haruku08 and @BossMBGaming

If you see that "Graphics" area in your assets section it means you are not using components v2.0 so swap action is not possible.

Are you sure you migrated your instance to 2.0 and the migration script run successfully?

[haruku08]

@superalex we migrated to 2.0, but I'll check up on it if the components where also migrated to v2.0

[BossMBGaming]

I manually ran the migration script on the instance on my laptop, which is shown in the screenshot in my previous comment. I created a fresh project file as a test and the same context menu is shown. The instance I have on my server was tested and the issue is the same. Both have been tested with new files and previous files. I will spin up a fresh instance on my server without using the old data volumes and see if that changes anything, but I highly doubt it will. I will post an update as soon as I have done that.

[haruku08]

docker exec -ti {our-id} ./run.sh app.migrations.v2

exec /opt/jdk/bin/java -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Dlog4j2.configurationFile=log4j2.xml -XX:-OmitStackTraceInFastThrow -Dpolyglot.engine.WarnInterpreterOnly=false --enable-preview -jar penpot.jar -m app.migrations.v2
[2024-04-15 15:58:16.986] I app.metrics - action="initialize metrics"
[2024-04-15 15:58:17.005] I app.db - hint="initialize connection pool", name="main", uri="postgresql://penpot-postgres/penpot", read-only=false, with-credentials=true, min-size=0, max-size=60
[2024-04-15 15:58:17.044] I app.migrations - hint="running migrations", module=:app.migrations/migrations
[2024-04-15 15:58:17.771] I app.svgo - hint="initializing svg optimizer pool"
[2024-04-15 15:58:18.075] I app.svgo - hint="stopping svg optimizer pool"

got some help and we ran the script manually and also restarted the containers, so far we didn't get lucky.

[BossMBGaming]

Okay, I stand corrected, I loaded up a fresh instance, and it miraculously is working now. I guess some work may need to be done on the migration script because I would have run it as the instructions showed at help.penpot.app. Because I would have had some caching issues when I first deployed my instance of the 1.x UI still being shown which was fixed by clearing my browser cache. After which, I read the docs and noticed that there was a migration step that needed to be done. So I ran it to see if it would fix any of the issues I was having, and it hasn't/didn't. I will run the migration script again and see if that changes anything, and send an update if it has.

This is a screen grab of the fresh instance:

[haruku08]

Thanks a bunch, I think we look into it some more and try to update the current instance.

[superalex]

One more question @haruku08 and @BossMBGaming

If you create a new team, and create a file in that new team (in the existing instances), that new file has components v2 enabled?

[BossMBGaming]

Ran the migration again, and I am getting the same issue. I exported one of my files, imported it in the new instance to see if that works. It does, but then all my teams and such will have to be remade and invitations sent out to members, and that's a lot of hassle.

But my logs are similar to @haruku08

~ 
❯ docker exec -ti penpot-penpot-backend-1 ./run.sh app.migrations.v2
+ exec /opt/jdk/bin/java -Djava.util.logging.manager=org.apache.logging.log4j.jul.LogManager -Dlog4j2.configurationFile=log4j2.xml -XX:-OmitStackTraceInFastThrow -Dpolyglot.engine.WarnInterpreterOnly=false --enable-preview -jar penpot.jar -m app.migrations.v2
[2024-04-15 14:17:54.757] I app.metrics - action="initialize metrics"
[2024-04-15 14:17:54.812] I app.db - hint="initialize connection pool", name="main", uri="postgresql://penpot-postgres/penpot", read-only=false, with-credentials=true, min-size=0, max-size=60
[2024-04-15 14:17:54.942] I app.migrations - hint="running migrations", module=:app.migrations/migrations
[2024-04-15 14:17:56.001] W app.setup - hint="using autogenerated secret-key, it will change on each restart and will invalidate all sessions on each restart, it is hightly recommended setting up the PENPOT_SECRET_KEY environment variable"
[2024-04-15 14:17:56.444] I app.svgo - hint="initializing svg optimizer pool"
[2024-04-15 14:17:57.143] I app.svgo - hint="stopping svg optimizer pool"

[BossMBGaming]

One more question @haruku08 and @BossMBGaming

If you create a new team, and create a file in that new team (in the existing instances), that new file has components v2 enabled?

Yes, when a new team was created the component system works properly!

[superalex]

Thank you very much for the information, let us check the migration script, it seems something is not working properly there

[superalex]

I have one more question, can you please verify this?

docker exec -ti penpot-penpot-postgres-1 /bin/bash

psql -U penpot

select * from server_prop where id = 'v2-migrated';

Probably returns true, isn't it?

[BossMBGaming]

I tried exporting and importing a previous file into the new instance, and it worked, but the items that were in the graphics area became components that didn't function 100% correctly in that the SVG fill wasn't being changed correctly. (The 'background fill' was being changed and not the stroke fill)

I decided I would try moving projects files over to a new team to see if the components would work and was greeted with this message:

So the issue is definitely to do with the migrations.

---

@superalex yes the output is

penpot=# select * from server_prop where id = 'v2-migrated';
     id      |    content    | preload 
-------------+---------------+---------
 v2-migrated | {"~#'": true} | f
(1 row)

[superalex]

Yes @BossMBGaming I think two things are happening:

• the script isn't considering properly all the teams to migrate
• when it finish it sets that v2-migrated property to true so the migration isn't executed on every restart

The other issue about the background fill sounds a different thing. Could you please create another issue for that? (it would be great if you could attach info about how that background fill is rendered on before and after the migration).

Thanks!

[BossMBGaming]

I think the background-fill issue has to do with how I would have to do with that specific SVG I would have imported into penpot and how the SVG is formatted... I don't believe it is a penpot specific issue, but if I see a similar issue appear in using SVGs going forward, I will be sure to make an issue to report it. (The file has an 'invisible' background, to ensure the proper aspect ratio and spacing around the logo, which is what I believe was taking the fill option instead of the path of the logo.) I imported it into another program previously and had a similar issue. So I don't think it is any fault of penpot. But I will look more into it when I have some more free time.

[superalex]

Ok, ok, I thought it was related to the migration from v1 to v2. If it's what you say I don't know if it's something penpot can manage properly.

By the way, I've detected the problem with the migration script, I have to speak with the rest of the core team but probably tomorrow we will have a fix (and new docker images). Thank you very much for the help! :)

[superalex]

Hi!,

We released docker images solving this problem. You will need to do something like this:

Prepare penpot to re-excute the migration

docker exec -ti penpot-penpot-postgres-1 /bin/bash

psql  -U penpot

delete from server_prop where id = 'v2-migrated';

Stop penpot and update the images with something like:

docker compose -f docker-compose.yaml pull

Now start penpot normally, it will detect the migration isn't executed and execute it normally, you should see in the logs some info about the migration (it can take a while if you have a lot of files

penpot-penpot-backend-1    | [2024-04-16 04:51:33.825] I app.migrations.v2 - hint="v2 migration started"
penpot-penpot-backend-1    | [2024-04-16 04:51:33.890] I app.migrations.v2 - hint="v2 migration finished", files=XXX, teams=XXX, errors=XXX, elapsed="XXXs"

[superalex]

@BossMBGaming @haruku08 could you check if this fix your issue?

[haruku08]

Works. Thanks a bunch guys.

[BossMBGaming]

@superalex Yes, the issue seems to have been fixed. I was only able to do the update on my laptop and haven't been able to test it on my server just yet. When I do, I will be able to confirm with a higher chance of not needing to reopen this issue. But I can't test it any time soon, @haruku08 can chime in with their findings to give other feedback/confirmation.

But so far, I think it would be safe to say it is fixed (with the caveat of only having one instance working so far of the original three instances that have been known to have the issue). If I have any issues when I am able to access and update my servers instance I will be sure to update you.

[superalex]

Great!, thank you very much!, with the @haruku08 and yours local @BossMBGaming we have 2/3, I'm closing the issue, feel free to reopen it if you have more issues when doing it in your server :)