Having problems restoring site to get work done after new system install!!!
-
March 9, 2020 at 10:39 am #2013
[anonymous]
I was just a few steps away from buying the Cortado theme from the marketplace but I am having a problem!
My site is already published to a live URL, but I went into the Publii /sites folder and backed up the project manually, I generate the backup.
Then I proceeded to install Devuan, can only get Publii to run inside Whonix, and… I can’t restore the site I made???
I really need to work on the SnipCart or Stripe Elemenents features at this point, but I can’t!
What do I do?
I’ve already consulted documentation, tried copying pasting original /sites & /backups project files into a same named folder…
All I can get is the blank new site I created called test.
<h2>Restoring Backups on a New Publii Installation</h2>
If you’ve switched to a new computer and want to restore your site backup to a new Publii installation, you’ll have to take a couple of additional steps:- Install and open Publii, and create a site; the name isn’t important, but you will need access to a site before you can access the Backup and Restore tool.
- make sure that you have specified a Backup Location in the Global Settings of Publii.
- In the backup directory, create a new folder and give it the same name as the site, but use lower-case only. If your site has spaces, replace them with hyphens e.g. if your site name is My Site, then the folder’s name should be my-site.
- Copy your backup file into the new folder.
- Now, in Publii, click on Tools in the left-sidebar and open the Backups tool; you will see your backup appear in the list.
- Click on the Restore button next to your backup; a dialogue box asking for confirmation will appear. Click the Restore backup button to begin the restore process.
- Your site is now ready to use!
March 11, 2020 at 5:48 pm #2047[anonymous]
Hi,
Could you exactly describe steps which you did to move Publii sites to another OS? I suppose that something goes wrong during this process, but I need a better description to find a reason of your issues 🙂
March 11, 2020 at 9:01 pm #2058[anonymous]
Thanks for getting back to me!
I just copied the entire site folder out of : /Documents/Sites/
Tried using exact name, tried moving to Backup folder as well.
The OS change was from one Debian to another!
March 11, 2020 at 9:27 pm #2059[anonymous]
Ok, please try to do following as it seems that the article misses one step:
- Store your backup in a safe place to avoid losing it
- Create a new website using the same name as your website to move
- Then under your new backup location please put your backup file in the directory with the same name as your website (if it does not exist – please create it)
- Now you can try to restore backup under your newly created website.
Alternatively: just unpack your backup, rename the output folder to be the same as old folder name on your previous OS and move it to your publii sites directory (you can check this location under Global Settings in Publii) – then restart Publii and it should appear.
March 11, 2020 at 10:07 pm #2060[anonymous]
I do not have any backup or archive only the folder found within /Sites!
March 11, 2020 at 11:10 pm #2061[anonymous]
So it should be enough to move it to the Publii sites folder – Publii will detect it automatically after the restart.
March 12, 2020 at 12:59 pm #2063[anonymous]
Thats what I’m confused by, it’s just not working! I’ve rebooted more than once, but the first site ‘test’ shows.
March 12, 2020 at 5:30 pm #2073[anonymous]
Sorry, but the content of this folder does not look like a Publii website :/ Publii sites have only three catalogs inside:
- input
- output
- preview
Please compare it with your “test” site.
March 29, 2020 at 5:54 pm #2242[anonymous]
Thanks for the reply, and sorry for the delay.
Ok, you were right, I was copying the wrong folder (from a HUGO test folder). I copied the right folder, showing
- input
- output
- preview
The name of the folder matches exactly from the original project, is there something else I need to do?
April 9, 2020 at 2:51 pm #2372[anonymous]
Hi,
It is working after moving the right folder or not? Because your post is not clear for me in this case 🙂
May 1, 2020 at 9:32 am #2603[anonymous]
On a Mac with an iCloud-synced Documents folder this is overly complicated. You should be able to run Publii on multiple Macs all reading the same ~/Document/Publii folder without any issue. Why does that not work?
Based on this, it seems I need to create backups for all my websites. Then move the ~/Documents/Publii folder somewhere else. Then install Publii on the other Mac and restore the websites from backups. I’ve modified the themes too. Will those changes be kept?
I somehow assumed it’d be easier…
May 4, 2020 at 8:49 am #2623[anonymous]
In case any other Mac users have this issue: Publii will fail without any error message if the username is different and you simply copy the directory from Documents or sync it with iCloud . Turns out the user directory path is hard-coded in the config and site data. That makes no sense since storing the Publii folder in iCloud Documents makes it portable. Or should be. By storing the full user directory path in Publii’s config, that only works as long as the username is the same.
To fix it, run a search and replace and replace ‘Users/oldusername’ with ‘Users/newusername’. The easiest way to do it is to download TextMate (free) and use its Find-Replace feature.
May 4, 2020 at 10:11 pm #2637[anonymous]
Hi,
jakobpersson – you’re right. It can be a bigger problem as Publii stores absolute paths. I will check if it is possible to store user-relative paths in the site config and then resolve them on a specific machine automatically.
May 5, 2020 at 7:41 am #2642[anonymous]
May 7, 2020 at 9:16 pm #2671[anonymous]
@jakobpersson – now I understand where is the issue – you are storing the whole “Publii” catalog on iCloud, but you should store only sites catalog.
Storing the whole Publii catalog is a bad idea as it can lead to some unexpected issues. If you will store only sites on iCloud – it should work fine.
May 7, 2020 at 9:58 pm #2672[anonymous]
That’s the default location and where Publii puts it. The user documents folder on a modern Mac is stored in iCloud. You need to make Publii store the conf stuff in application support. I consider this a Publii bug.
May 17, 2020 at 2:26 pm #2720[anonymous]
@jakobpersson – yes, it is also a potential issue. I suppose it affects a limited amount of people, but you are right – it can be problematic. I will see what we can do with that. We have some legacy issues in this case and also I have to be very careful to do not introduce problems for existing Publii users.
May 18, 2020 at 7:39 am #2725[anonymous]
If you by “limited amount of people” mean everyone using Publii on a Mac, then yes. 🙂
Publii is in beta så breaking changes are to be expected I think. That’s why this issue is frustrating but also expected. Things will and can break at this point. We’re at a pre-1.0 version after all.
Avoiding issues for existing users should be possible. You just need to check their config for whether the string contains “/Users/”.
Perhaps this should be added as an issue to Github to be properly tracked.
I’ll see if I can help with producing a patch. I hate to be a bike-shedder when there’s real work to be done 🙂
May 18, 2020 at 8:10 am #2726[anonymous]
@jakobpersson
If you by “limited amount of people” mean everyone using Publii on a Mac, then yes.
I see that you are very good in extrapolating cases 😉
1. Desktop files on iCloud is an option
2. It is not working for many peoples (e.g. for me due amount of files or for people who do not want to pay for additional iCloud storage)
3. To occur – the person must use different usernames on their macs
4. At first – Publii user must have more than one mac or migrate to a new one and change the old username
In my opinion it decreases amount of the affected people by 75-90% 🙂
To be honest – I agree that we should solve it and I will try to solve it before v.1.0, but please don’t say that it is a super critical problem which affects all macOS users, because it is not true 🙂
May 18, 2020 at 8:37 am #2729[anonymous]
Those four points are some pretty major caveats that could be easily avoided with 2-3 lines of code. More and more people use iCloud and those who own multiple Macs find it to be incredibly useful when switching computers. I think you’re dismissing the severity.
At least warn people of the problem and provide instructions in the install/readme file and online docs on how to fix it.
May 18, 2020 at 9:18 am #2730[anonymous]
I’m closing the topic because, as I wrote:
To be honest – I agree that we should solve it and I will try to solve it before v.1.0, but please don’t say that it is a super critical problem which affects all macOS users, because it is not true ????
For your information – the tone of your entries is starting to be very claiming. If you think that with such entries you will force us to solve ASAP of your own problems, I am very sorry, but you are in big mistake. This is not why we devote our private time to developing the Publii so that somebody can dictate to us what to do and at what point in time, because this is his wish or need.
For each case, we analyze the impact on users and this is the main criterion for queuing tasks and improvements in the Publii in case of found errors. You are the first person to report this problem, which in itself indicates that your hypothesis of a huge impact on all macOS users is being heavily overstretched and I have additionally listed groups of users who are not affected.
And so that we don’t misunderstand each other – we will solve this problem, because we absolutely agree that it can and must be improved, but we will do it when we find time for it in our publishing cycle (the fact that the problem looks like 2-3 lines of code does not mean that it will end there, because such a change can affect many other elements of the application and we must check and verify it).