I LOVE Gutenberg, don’t get me wrong, but a real pagebuilder competitor, it has not been – so far.
With the newest release of Gutenberg features that makes page building a breez might change all that. There is of course much more to page builders, but a good mastering of nested blocks and the ability to group blocks is a big step in the right direction.
It’s great to see Gutenberg spread to other Content Management Systems – it strengthens the editing experience but of course also puts a thick line under one of the WordPress goals for 2019 “Building a WordPress.org directory for discovering blocks, and a way to seamlessly install them”.
That directory might very soon need to be cross CMS capable.
In the same year I turned 4 o, WordPress finally went and did something slightly out of character – and for its age, something that it perhaps should have been clever enough to do a few years back… Just like the tattoo I finally got, at the age of 40, where most settle into the comfort of knowing who you are, and how you will look and dress for the many years to come – WordPress went and got itself a page-builder.
Was it worth the wait?
WordPress, with its 16 internet years (at least 50 human years), started a project some 2 years back and named it after an old guy… The result; as time-tested as a tattoo, a block editing experience as seen in the most popular themes and frameworks out there.
So what is this new thing, and did WordPress only now, come to a conclusion, that most of us already knew… Tattoos are cool, and so are block-based editing?
No.. I think the many page builder setups had run its course, causing WordPress to handle all sorts of data in its options tables, and markup data within content fields, to such an extent that sites became too hard to work with, and well… just plain slow. The expandability we love from plugins, custom post types and custom fields has for years now, put a strain on the table structures of the WordPress database.
It was time to take charge and regain control of what is most important to WordPressMe, in this blog post
The most important to WordPress has always been to democratize publishing. Sometimes democratizing means putting all the great ideas others had already put into plugins and feature packed themes, into the core of a system. And so they did…
Gutenberg: the future of publishing
In core, Gutenberg lay the cornerstone for a future with no widgets no, one page – one layout, and perhaps most important, no reason to store content into only one database field for a page or post. Blocks themselves could, in theory, do away with custom fields, and enable WP to change how data is stored, in much smaller chunks of data. Data that we can pull in, when and if needed in a given view.
All of this is speculation, some closely related to ideas already alive in the WordPress community. Others just imaginations by me.
We already see the effects of putting blocks with layout capabilities into the hands of the content owners, instead of UX and design people. Blocks and their layouts and functions are now put in place, in context – or removed, if not needed in context.
Context is king, and blocks make it easier than ever to put the right blocks of content in the right context. I can’t wait to see conditional logic in blocks – based on device, surrounding blocks, geo, time or even personal information (if GDPR will allow it).
WOW what a ride! Some 200 days has passed since I first started reading EU General Data Protection Regulation, finding GDPR friends in the WordPress COmmunity, and seeing the project take form inside WordPress core.
The day has arrived – 25th of May – I’ve said that date quite a few times now, and although it’s an important data as the deadline has kept us focused in our work – the work is not at all “done”.
Our work continues, and updates to the current GDPR hooks and filters you will find in WordPress code as well as backend tools for site administrators, are first versions of the central tools. Many more to come I suspect.
One such tools is a logging feature which we started working on at Peytz when we where still had about 50 days to go before the 25th…
Although you see a logging feature as part of the current GDPR tools in admin, these do not meet the requirements of logging, in terms of the regulation.
Therefore we’ve set out to define an logging feature that can hook into WordPress actions allowing developers log actions performed in code
– separated from the database
Wait – what: re-actionable and separated from the database. That sounds messy!
Well, yes, and it’s not strictly WordPress but let me explain.
To make a log compliant with GDPR, we need to make sure that it does not hold any information that can identify a natural beeing.
We also need to maintain a log that is not part of the data it’s logging.
This makes for an external logging mechanism you can put data into, and also query to fetch previous actions performed on certain data.
A unique but non-personal hashed value will serve as an ID. One that only make sense if a user provides the personal data on which the hashed value has been created.
Stay tuned for more information after today 🙂
Am I poud? Hell ya. Did i code a single line – nope 😉
But nonetheless, my team has spend roughly 125hours to help out on this project that we gave birth to. The project was adpoted by the WordPress community and the result is now in Beta for the upcoming WordPress 4.9.6 version:
I’m quite sure, by know, you know that I’m heavily invested in GDPR. Specifically when it comes to looking past the law texts surrounding the regulation, focusing on providing the actual tools needed to comply with the new lives of a website administrator after May 25th, 2018.
Another thing is how to handle the request your users are now permitted to bring before you because of the General Data Protection Regulation.
Yes yes yes – I’m STILL talking about:
- What data do you have on me?
- Can you provide me with a copy of the data you have on me(readable, and machine-readable?)
- Can you allow me to make changes to the data?
- Can you please delete or otherwise anonymize the data you have on me so that it is no longer data that points to me as a human being?
- Do you have means of notifying me and the appropriate authority within your country if a data breach occurs?
- Can I retract consent previously given to you partly or in full?
- Do you have a log in place that collects any interaction I might have on your system when it concerns personal data and given content on my part?
- How do you handle if a backup with my data is re-introduced after I’ve asked for deletion?
- How do you handle if a 3rd party element of your website changes it’s compliance texts and ways they use any data your website might share with them ?
Soo many questions – many are possibly easy to answer from a technical standpoint, and some might not even require a technical solution – a simple written Todo might be sufficient in some cases.
For WordPress at least, we’re making real headway with since the GDPRWP.com project has been adopted by the community and now lives inside WordPress Trac tickets – being actively developed by the community – something I’m quite happy with 🙂
Interested in GDPR in relation to your website?
Please don’t hesitate – reach out
Kåre Mulvad Steffensen
In December 2017 together with Peter Suhm from WPPusher.com, we’d just launched the basic idea of a PHP object Interface to tackle the upcoming GDPR challenges. Our Ideá was that a common interface adopted and implemented by the general community of WordPress would ensure a unified way of identifying Personal Data, and this makes it possible for the ecosystem to create plugins utilizing this interface to provide the needed tools for Website administrators to uphold the law of the regulation.
GDPRWP.com was live and a GitHub repository to go with it, with a basic readme file to explain the idea. With the help of Peters contacts, we got a few articles on WPTavern which lead to this interview for the monthly Meetup in Porto, Portugal.
This is the full article about the meetup:
Since then, the GDPR for WP project has moved forward, and to focus more on how WordPress is doing things, it’s not a strict PHP interface anymore.
The carefree “let’s code this stuff, and ask visitors for their names and personal preferences” so that we can ____ is over!
In about 192 days from now, EU General Data Protection Regulation will protect any personally identifiable information on any EU citizen, anywhere on the web – no matter where in the world your company or server is located.
I’ve been reading through the final text of the regulation, and the more I read, I feel the urge to remove the “EU” from the name of this regulation. It may be a massive regulation already, and how it’s going to be enforced by various controlling bodies within the EU alone is anybody’s guess. But from a personal perspective, in a world where big data is used more and more to target users in both commercial and political situations, this law lay the foundation that should reach across borders.
GDPR is coming – in one form or the other. If not from the top, then from the people fed up with the non-transparent usage of their personal data.