Open vinerz opened 7 years ago
I also have this problem.
I found I was able to restore the folders by visiting /app/tmp
, where a public.old
folder was hanging around. I tried to delete that and was told that the folders in it (wp-admin
, wp-content
and wp-includes
) were not empty. That was odd, because there was nothing inside them.
Renaming the folders allowed me to delete them. I then ran composer install
in /app
to rebuild the slug.
Thanks for the workaround @duncanjbrown this will get me through till it's fixed
I'm having this issue as well.
I've disabled the built-in daemon that rebuilds everything when any file inside the project is updated and created a gulp watch task which detects any file from public
and throws it on public.built
.
gulp.task('watch', function () {
return watch('public/**/*', { ignoreInitial: false })
.pipe(gulp.dest('public.built'));
});
This way, I only use ./support/app_slug_compile.sh
when I use a composer update
.
It works, at least. haha
Good call. I did the same thing and I'm using a Grunt task to rsync
changed files from public
to public.built
. I actually think I like it better as a permanent solution. It runs on the host side so it's faster when iterating development changes.
My request for the future, if the built-in daemon is fixed, is that there be an easily configurable option to toggle that functionality with associated documentation. Now that I'm using my own build process to modify the public.built
directory I think it's a better workflow for development.
While using the local development with Vagrant, whenever I save a file inside
public/
orsupport/
, the internal vagrant daemon removes all the contents frompublic.built/wp-includes/
folder.The daemon usually gets completely lost when I make too many changes on the filesystem at once (such as building my production assets with gulp).
What can I do to prevent this issue?