Upgrade to Beta8 deletes all icons


(Alan Tan) #22

If you have a site logo, it wouldn’t disappear. This is only for the default logo that Discourse provides out of the box.


(Chris Croome) #23

That is not my experience, on two sites the logos vanished, there is another site I have yet to upgrade that I could demonstrate this for you if you would like?


(Alan Tan) #24

The output that you provided showed that no logo was configured previously though.


(Chris Croome) #25

I agree, however there were logos, I can illustrate this with another site — the Discourse site at members.webarchitects.coop is running v2.2.0.beta7 +13, it has a large logo displaying on the front page and it has a small logo displaying when you scroll, however the admin interface doesn’t currently list logos, but this isn’t flagged on the admin dashboard so it isn’t clear that any action is needed regarding the images prior to the availability of this upgrade — the site currently has logos, look:

And checking via the command line:

./launcher enter app
rails c
[1] pry(main)> SiteSetting.where(name: "logo_url").first
=> #<SiteSetting:0x0000557249a118d0
 id: 27,
 name: "logo_url",
 data_type: 1,
 value: "/uploads/default/original/1X/de093f782ce016027b6a521353e2ec69eee28aef.png",
 created_at: Wed, 11 Jul 2018 19:29:43 UTC +00:00,
 updated_at: Wed, 11 Jul 2018 19:29:43 UTC +00:00>

And this path, /uploads/default/original/1X/de093f782ce016027b6a521353e2ec69eee28aef.png matches the current logo URL, https://members.webarchitects.coop/uploads/default/original/1X/de093f782ce016027b6a521353e2ec69eee28aef.png.


(Chris Croome) #26

Same for the small logo:

[5] pry(main)> SiteSetting.where(name: "logo_small_url").first
=> #<SiteSetting:0x000055724306f710
 id: 28,
 name: "logo_small_url",
 data_type: 1,
 value: "/uploads/default/original/1X/c39d583410358ffd8fba05f7ccab82d6c2f0b716.png",
 created_at: Wed, 11 Jul 2018 19:29:43 UTC +00:00,
 updated_at: Wed, 11 Jul 2018 19:29:43 UTC +00:00>

(Alan Tan) #27
./launcher enter app
rails c
OnceoffLog.exists?(job_name: "MigrateUrlSiteSettings")

Does this return true?


(Chris Croome) #28

Yes:

[6] pry(main)> OnceoffLog.exists?(job_name: "MigrateUrlSiteSettings")
=> true

(Alan Tan) #29

Does SiteSetting.logo returns nil?


(Chris Croome) #30
[7] pry(main)> SiteSetting.where(name: "logo").first
=> #<SiteSetting:0x000055724362ec28
 id: 51,
 name: "logo",
 data_type: 18,
 value: "",
 created_at: Wed, 16 Jan 2019 09:08:50 UTC +00:00,
 updated_at: Wed, 16 Jan 2019 09:24:06 UTC +00:00>

(Alan Tan) #31

It looks like someone deleted the logos 16 minutes after it was first created? Can you check the staff action logs to confirm if that was the case?


(Chris Croome) #32

Nobody has intentionally deleted the logos! How do I check the log?


(Alan Tan) #33

You can check it at https://members.webarchitects.coop/admin/logs/staff_action_logs


(Chris Croome) #34

Oh, I see, I started manually adding the logos earlier today when you said this this behaviour was a feature not a bug, then when it appears that perhaps it was a bug after all I removed them in order that the bug could be illustrated, sorry.


(Chris Croome) #35

Here is a screenshot of what happened today, I’m afraid I don’t have another Discourse server to demonstrate this issue on other than a clients production server and I don’t really want to mess with it for this purpose.


(Chris Croome) #36

As I said:

If the above isn’t of use in demonstrating this issue I’ll manually add the logos to this server and then upgrade it.


(Chris Croome) #37

I have the permission of a client to illustrate the issue using their site:

https://sands.community/

As you can see this site has a logo:

And these are the settings:

[1] pry(main)> SiteSetting.where(name: "logo_url").first
=> #<SiteSetting:0x0000563235107e68
 id: 46,
 name: "logo_url",
 data_type: 1,
 value: "/public-images/sands-logo-text.png",
 created_at: Mon, 16 Oct 2017 18:22:28 UTC +00:00,
 updated_at: Mon, 30 Oct 2017 17:26:15 UTC +00:00>
[3] pry(main)> SiteSetting.where(name: "logo_small_url").first
=> #<SiteSetting:0x000056322e98d170
 id: 47,
 name: "logo_small_url",
 data_type: 1,
 value: "/public-images/sands-logo.png",
 created_at: Mon, 16 Oct 2017 18:22:56 UTC +00:00,
 updated_at: Mon, 30 Oct 2017 17:26:13 UTC +00:00>
[4] pry(main)> SiteSetting.where(name: "logo").first
=> nil
[6] pry(main)> OnceoffLog.exists?(job_name: "MigrateUrlSiteSettings")
=> true

In the admin interface we have a prompt to upgrade:

And in the settings there are no logos listed:

I hope this illustrates that there is an issue here? Please let me know if further details are needed.


(Chris Croome) #38

Very sorry to be using another account to post to this thread but I hit the max three posts in a row rule.


(Chris Croome) #39

On the test version of the same clients server:

https://test.sands.community/

Discourse has been upgraded to v2.2.0.beta8 +27 and I also did a git pull and ./launcher rebuild app, git status reports Your branch is up-to-date with 'origin/master' and I also re-uploaded all the missing images using the admin interface:

However with mobile browsers, (or Chromium with a narrow width) there is a missing icon:

The URL for this image that Discourse uses is https://test.sands.community/uploads/default/original/2X/b/b7fa961032f8ae8c446574dbf9e4c53edc71f903.png and it is a 404.

These are the settings I could find in the rails console:

[1] pry(main)> SiteSetting.where(name: "logo_url").first
=> nil
[2] pry(main)> SiteSetting.where(name: "logo_small_url").first
=> nil
[3] pry(main)> SiteSetting.where(name: "logo").first
=> #<SiteSetting:0x000055a60fcf4710
 id: 177,
 name: "logo",
 data_type: 18,
 value: "3034",
 created_at: Tue, 15 Jan 2019 13:39:32 UTC +00:00,
 updated_at: Wed, 16 Jan 2019 12:04:33 UTC +00:00>
[4] pry(main)> SiteSetting.where(name: "logo_small").first
=> #<SiteSetting:0x000055a61007f998
 id: 176,
 name: "logo_small",
 data_type: 18,
 value: "3035",
 created_at: Tue, 15 Jan 2019 13:39:31 UTC +00:00,
 updated_at: Wed, 16 Jan 2019 12:04:32 UTC +00:00>
[8] pry(main)> SiteSetting.where(name: "digest_logo").first
=> #<SiteSetting:0x000055a61028c9c0
 id: 175,
 name: "digest_logo",
 data_type: 18,
 value: "2792",
 created_at: Tue, 15 Jan 2019 13:39:30 UTC +00:00,
 updated_at: Tue, 15 Jan 2019 13:39:30 UTC +00:00>
[9] pry(main)> SiteSetting.where(name: "mobile_logo").first
=> #<SiteSetting:0x000055a610717940
 id: 180,
 name: "mobile_logo",
 data_type: 18,
 value: "3034",
 created_at: Wed, 16 Jan 2019 10:51:22 UTC +00:00,
 updated_at: Wed, 16 Jan 2019 12:04:32 UTC +00:00>
[10] pry(main)> SiteSetting.where(name: "large_icon").first
=> #<SiteSetting:0x000055a615d77970
 id: 170,
 name: "large_icon",
 data_type: 18,
 value: "3036",
 created_at: Tue, 15 Jan 2019 13:34:50 UTC +00:00,
 updated_at: Wed, 16 Jan 2019 12:26:59 UTC +00:00>
[11] pry(main)> SiteSetting.where(name: "favicon").first
=> #<SiteSetting:0x000055a616068e40
 id: 174,
 name: "favicon",
 data_type: 18,
 value: "3031",
 created_at: Tue, 15 Jan 2019 13:39:16 UTC +00:00,
 updated_at: Tue, 15 Jan 2019 13:39:16 UTC +00:00>
[12] pry(main)> SiteSetting.where(name: "apple_touch_icon").first
=> #<SiteSetting:0x000055a61652af50
 id: 173,
 name: "apple_touch_icon",
 data_type: 18,
 value: "3032",
 created_at: Tue, 15 Jan 2019 13:39:16 UTC +00:00,
 updated_at: Tue, 15 Jan 2019 13:39:16 UTC +00:00>
[13] pry(main)> SiteSetting.where(name: "opengraph_image").first
=> #<SiteSetting:0x000055a616696650
 id: 172,
 name: "opengraph_image",
 data_type: 18,
 value: "3033",
 created_at: Tue, 15 Jan 2019 13:39:15 UTC +00:00,
 updated_at: Tue, 15 Jan 2019 13:39:15 UTC +00:00>
[14] pry(main)> SiteSetting.where(name: "twitter_summary_large_image").first
=> #<SiteSetting:0x000055a6167dd540
 id: 171,
 name: "twitter_summary_large_image",
 data_type: 18,
 value: "3033",
 created_at: Tue, 15 Jan 2019 13:39:15 UTC +00:00,
 updated_at: Tue, 15 Jan 2019 13:39:15 UTC +00:00>

Any suggestion for settings I could look at or things I could do to solve the mobile image 404? I’m not going to touch their production server until I’m confident that all the icon issues have been resolved on their test server.


(Jay Pfaffman) #40

The solution to too many posts on a row is to edit the other posts, but perhaps you ran up against link limits.


(Chris Croome) #41

Thanks @pfaffman, I didn’t want to mix up posts relating to different servers, so I keep the post about the un-upgraded live server seperate from the post about the upgraded development server as I thought it might get too confusing if I put everything into one post. I did try deleting previous posts but that only partially helped so I have now un-deleted all of them. The issue was one of too many posts in a row, I didn’t get any link limit warnings.