Reloader daemon destroys wp-includes contents

[vinerz]

While using the local development with Vagrant, whenever I save a file inside public/ or support/, the internal vagrant daemon removes all the contents from public.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?

[duncanjbrown]

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.

[toddheslin]

Thanks for the workaround @duncanjbrown this will get me through till it's fixed

[ryanburnette]

I'm having this issue as well.

[vinerz]

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

[ryanburnette]

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.