Remove customize does not work as expected (remove cutomizer link wont work in intervention 2) about intervention HOT 3 CLOSED

No problem!

Ah, that's painful, I see I had to re-allow Packagist access to this organisation on GH. Not sure why that had changed, but updates should be syncing again now.

There's still two changes I want to make before tagging a stable 2.0.0, namely renaming application.site to application.general to match the WordPress UI, and address #55

I should be able to wrap those changes possibly as soon as next week, no later than early to mid March I imagine.

from intervention.

Hi @emanueljacob ,

Thanks for reporting. You're correct in your thinking that appearance.customize should remove the submenu item. WordPress throws in a ?return= for the customizer page so I have created a fix to account for that, which is now on dev-master, 4189186.

Please let me know if that works now.

from intervention.

@darrenjacoby
Thank you for your awesomely fast reply! Yes, your changes seems to fix it.

btw: I was confused, seeing composer not updating the master, even after composer clear-cache until I realized that the master is not yet published to packagist in its latest state... when are you usually push the master to packagist (didn't see any automatic action for that)? is there an eta for a stable version 2.0.0, yet?

Edit: ok strange - now packagist/composer takes the latest commit into account, and packagist shows that the master has been changed... mhm maybe just a caching issue on my end.
however, maybe you can nevertheless answer the eta question.

from intervention.