Uploaded robots.txt cripples Source theme

We are Ghost (Pro) members.

I uploaded a custom robots.txt file to Ghost’s vanilla Source theme and our whole site broke. This is the robots.txt file I uploaded:

User-agent: *
Sitemap: https://www.jeffcobeacon.com/sitemap.xml
Disallow: /ghost/
Disallow: /p/
Disallow: /member/

User-agent: facebookexternalhit
Allow: /

(N.B. the whole reason I am doing this is to force Facebook’s scraper to work properly, which it sometimes doesn’t; thus why I insierted facebookexternalhit into the robots.txt file.)

Following the directions listed here in this forum, I added the robots.txt file to our theme by:

  1. adding the robots.text code directly in the Ghost interface, and then later by
  2. downloading the theme locally, moving over our robots.txt file, zipping the theme folder back up, and re-uploading it.

In both iterations, it broke the site and I had to revert to Ghost’s vanilla Source theme.

BEFORE
Site as it should look, before the new robots.txt was uploaded:

AFTER
Site after robots.txt was uploaded—all of the posts disappeared from the home page.

So, here’s my guess. You uploaded the theme with a slightly different file name. (Or maybe a (1) on the end.) When you do that, all the theme settings revert to default.

So, what you need to do: In /ghost > settings > theme > installed, find and activate the previous version of your theme. Copy down/screenshot all the settings. Then re-activate your edited version, and enter in the settings.

That should fix you up.

I recommend deploying from Github if you’re going to do a lot of edits, since it preserves the existing settings and version control is nice. Or, for the occasional edit, make sure you upload the file with exactly the same name each time, so that it overwrites instead of making a new version of the theme. (But keep backups locally, since you won’t have one on the server if you mess something up!)

Yep, that was the issue when editing directly in the Ghost interface. Source (and Casper) can’t be overridden so the editor creates a copy of the theme with a new name which means it has a new set of default settings.

That unexpected behaviour has just been fixed, so current theme settings get copied to the new theme if one is created through editing. The fix will be included in the next release.

There’s no change to manually uploading a new theme, you’ll still need to be aware of how settings work if you’re changing the theme name.

:tada:

That’s great. Is there a reason this behavior couldn’t also be offered for activating a manually-uploaded theme? I’ve seen lots of folks upload my-theme (1).zip and be very confused when their settings all reset…

There’s a new API param on the upload endpoint POST .../themes/upload/?copy_settings_from=old-theme to opt in to the behaviour. We’re not doing any automatic heuristics on theme names to try and guess which previous theme’s settings should be copied.

Right - I was suggesting that maybe there should be the option any time a theme is uploaded through the dashboard (rather than just when edited)… or is that already in and I just haven’t seen it?