That's a pretty major deal breaker for OP to leave out of his post touting it as something to build everything in your site on (especially for a tech blog)! Does it at least have a polyfill story? I see no mention of how to make it work on, uh, the other 15% of browsers worldwide, CanIUse is telling me.
"WPEngine's" being key here. Some of the banned people are wordpress contributors, unrelated to WPE. The other banned people are not contributors at all and seemingly the only reason they were banned is that matt is angry at their tweets.
The only potential cause of this were some posts discussing the arguments behind the original lawsuit - they’re written in my personal capacity, and I’m not a partner of WP Engine. Matt is simply banning anyone who speaks out at all, even when they agree with points he’s made - it’s nothing to do with their partnership status.
(I’m not a WP Engine partner, and my day job is running a competitor to them. Aside from that, I’ve been contributing for 20 years to the project, am a committer, and built several large parts of WordPress including the REST API.)
I find this astounding given your contributions.
Feel free not to answer but how is this affecting businesses such as the one you work for? How is the rest of the Wordpress agency/consultancy community reacting to all this? It’s not a space I play in, despite having heavily built on Wordpress in the past (and since abandoned it after this debacle), but I am curious. Are agencies just pretending it isn’t happening? Making contingency plans?
Parters involved in WPEngine so yes, you can cut it off. If they aren’t working on that specifically it’s irrelevant if they’re partners on a separate project, even if it’s similar
None of the banned people mentioned a fork, some don't even have anything to do with wordpress other than commenting about the drama on twitter. The whole post is matt gaslighting to justify the purge.
It feels very resistant to doing anything other than summarizing. Even when you ask questions for details, the answer is always in the form of a simple summary.
Tried this today and came across an issue that I could not get around: if the dialog contains a form, then submitting the form with enter (focused on any input) or space (focused on the submit button) will close the dialog. I couldn't find any nice way of preventing it.
Normally a form will reload the page anyways so I guess this isn't a normal problem but I was using htmx.
Your last sentence is likely right, by default the form issues a network request.
I've been using a dialog form to update an iframe (it's an editor) so it does work as normal the target iframe gets reloaded. It does not close the dialog though.
I can't produce the case where hitting enter closes the dialog. It should be the same as `<button type='submit'>submit</button>` which also does not close the dialog.
FWIW I learned yesterday that a button _can_ close the dialog:
> Tried this today and came across an issue that I could not get around: if the dialog contains a form, then submitting the form with enter (focused on any input) or space (focused on the submit button) will close the dialog. I couldn't find any nice way of preventing it.
There's no event for the dialog about to close, only an event for after the dialog closes. You can prevent default on the enter key and space key, but that obviously breaks the form ux.
There is an event for the dialog about to close from pressing the escape key. No idea why it's only for closing via escape key.
What might they be? API calls, read all files, write to files, side bar, UI interactions in editor. These are things I would imagine an extension can do. Continue.dev is an example.
reply