WimLeers

When/where can we buy this for use at home?

Yes.

See https://ircv3.net/.

An example: https://blog.irccloud.com/slack-integration/

Self-updating means that WordPress needs to be allowed to write to more places than just the "uploads" directory. Which is frightening, and a security risk.

There are countries where health care is guaranteed.

Very few remotes in Belgium indeed. I know of less than a dozen others.

QReadWriteLock predates C++11 by many years.

Well, the video indisputably shows the opposite. It's quite ridiculous to claim an improved UX and then show the UX that is apparently an edge case.

To then downvote, that's just sad.

Why am I being downvoted?

Then why doesn't the interface reflect the building blocks of the structured content?

Where the video says "The Django CMS interface", the interface is clearly page-centric, not structured content-centric. It has building blocks like "feature-visual", "bg-home.jpg", "feature-content", "container", "row", "column col-md-24" etc.

How is that structured content?

Perhaps it can do structured content, but then why doesn't the video put that front and center? Is this perhaps an "also" feature, for building landing pages? Then why does the marketing talk about "content editors"?

So perhaps it's just the marketing that oversimplifies things? :)

Very glad to hear that :)

What a great description! It perfectly describes my impression.

Awful authoring experience for non-technical users. Which doesn't mean it's not excellent for certain use cases :)

Indeed, Drupal 8 is first and foremost a data modeling tool. It's for structured content, not pages.

It allows you to reuse that structured content in many ways, everywhere.

(Django CMS as demonstrated in the video is purely about building pages, which makes it — if I'm being a bit harsh — just a glorified MS FrontPage.)

Yes, you could consider Drupal 8 basically a rewrite.

Massive modernization. Most high-level concepts remain the same. The implementation became much better. And it's a joy instead of a pain to extend/customize.

I recommend you to take a look :) See https://www.drupal.org/drupal-8.0 — RC1 was tagged _yesterday_.

It sounds like you will particularly like the Configuration System. See https://www.chapterthree.com/blog/principles-configuration-m...

Interesting; I'd love to read _what_ exactly they send in those long HTTP requests.

I'd think something along the lines of Surrogate Keys/Cache Tags would make sense:

- https://www.drupal.org/developing/api/8/cache/tags

- http://info.varnish-software.com/blog/advanced-cache-invalid... (ugh, they broke their site, cached at https://pinboard.in/cached/a31c4630dd2d/)

- https://www.fastly.com/blog/surrogate-keys-part-1

- https://blog.cloudflare.com/introducing-a-powerful-way-to-pu...

Could you add screenshots for that too?

Sounds interesting! :)

This does not explain how the client-side cache is kept up-to-date. Cache invalidation matters. You want instantaneous updates on the client if the data has been updated on the server. E.g. What if the like count has been updated?

Curious what solutions GraphQL offers for this. If it doesn't solve this itself, then what do GraphQL apps do today to solve this?

True, there's not always a clear distinction.

But giving lots of WYSIWYG-esque options to the content creator is a sure way to end up with unstructured content that cannot be reused, because it's got so much garbage HTML in it, and so few semantics.

Indeed.

Drupal 8 does exactly this. Use Drupal 8 for data modeling and storing the data. Use its forms if you want to. Retrieve the data using GraphQL and do all the rendering yourself. It even is capable of a hybrid model, where it serves pages BigPipe-style, and you do client-side rendering for the most dynamic/interactive parts.

See http://buytaert.net/the-future-of-decoupled-drupal.

https://raw.githubusercontent.com/relax/relax/gh-pages/asset... shows the key features are WYSIWYG-style building of entire HTML pages.

This is not a Content Management System, but a Page Management System. A CMS works with structured content and the relations between those pieces of structured content. It allows you to model the data it needs to store, receive (forms) and render. So you can then reuse, combine and display that data in any way you need.

(Many projects/people conflate "page builder" with "CMS".)

That being said, this looks very nice :) There totally are use cases for an easy-to-use page builder :)

+1, knowing the languages of the open sourced implementations would be very helpful.

If they're serious about open source, they should just Unlicense it.

http://unlicense.org/

I don't understand why Wordpress is considered a platform next to npm, bower, pypi etc.

> The first example looks nothing like parsing a specific cookie. It merely sanitizes the cookie headers a little, but it doesn't extract out a specific cookie to use as cache key.

You say you don't parse a specific cookie, but doesn't extract a specific cookie as a cache key? The blog post says the opposite:

> We modified Passenger to parse cookies, and to vary turbocache responses based on the value of this user_id cookie. We invoke Passenger like this: passenger start --vary-turbocache-by-cookie user_id

In other words: parse the user_id cookie.

The mentioned commit even adds a ~250 LoC file (ext/common/ServerKit/CookieUtils.h) to do cookie parsing: https://github.com/phusion/passenger/commit/a760649cd79fde43...

---

Anyway, what you're getting at is that Phusion only parses a certain value from the cookie and then uses it as a custom Vary header, whereas the examples I linked to clean up the Cookie header and then varies on that cleaned up Cookie header. That boils down to exactly the same thing.

P.S.: downvoting? Not very nice.

You're talking about response headers. But this deals with sending responses, you only get requests. Request headers can't contain a custom header that you control (unless your JS is making the requests of course). Hence you have to transform the Cookie header into whatever you need.

> What if the cache can parse cookies and vary the cached response by the value of a specific cookie, not the entire header?

> This is caching that Varnish and other “normal” HTTP caches (including CloudFlare) could not have done.

This is false. I'm not at all very familiar with Varnish, but I know this is easily possible, and has been used for many, many years.

E.g. for Drupal + Varnish, i.e. to only keep Drupal's session cookie, I found these examples, in less than a minute of googling:

- https://www.varnish-cache.org/trac/wiki/VarnishAndDrupal

- https://www.lullabot.com/blog/article/configuring-varnish-hi... (grep for "inclusion")

Everything in this article has been well-known for at least half a decade, yet is being presented as major technical breakthroughs. Too much marketing, IMO.

Why fork something that is incomplete, unstable, has very limited test coverage, and doesn't tightly control the generated markup?

CKEditor has had the ACF (Advanced Content Filter) for >1.5 years now. It allows you to very tightly control which tags and attributes are allowed.

This feature, and the rest of CKEditor has much, much more test coverage to account for the many browser quirks (notably in contentEditable) that they have had to work around, to prevent regressions. It's a waste of time for everybody to solve the same problems and work around the same browser quirks over and over again.

The "Ability to add uneditable area inside editor text flow (useful when building modules like video tools, advanced image editor etc)." feature is probably the only interesting feature. But it's nothing compared to CKEditor Widgets, which does exactly this, and much more (think storing structured content but transforming it to the specific markup that a frontend developer wants). Just compare Wysihtml's "advanced" demo to the CKEditor Widgets demo: http://docs.ckeditor.com/#!/guide/dev_widgets

See http://docs.ckeditor.com/#!/guide/dev_advanced_content_filte... for more about ACF and http://docs.ckeditor.com/#!/guide/dev_widgets for more about Widgets.

And yes, it's open source: GPL/LGPL/MPL/commercial: http://ckeditor.com/about/license

If we'd collaborate more rather than reinventing the wheel, we'd get so much further. One does not just write a WYSIWYG editor…

If you use the Pinboard bookmarklet, there is autocomplete functionality that works just fine.

This is a PMS (Page Management System), not a CMS. With this, you can only build pages, not reusable content.

A CMS must be able to display the same content in different ways, display content filtered according to relationships, and so on. Not to mention render in other content types than just HTML.

I'm sure this is fine and fun to build pages with though!

Also: the demo is broken… so this is based on what seems to be their main selling points.

No ability to switch between sitting and standing? No thanks.

Sitting all day is bad. But so is standing. Switching between both is best.