 So today we are going to take a trip down memory lane and we're going to see something many most of you Haven't never seen which is the original drop.org site before it became known as Drupal It all started like this once upon a time Dries decided first we are making a slash.site something a weblogger that offers all you need to know that was in 2000 in March and And then started things starting to be started to change As you can see here the complexity and the richness of the code We have been developing for years has evolved a lot of time in the beginning at the drop.org time What was to become Drupal was only about 2000 lines of PHP? And it had some data No JavaScript and just a tiny bit of additional code and not even no CSS And we went to where we are today with half a million line of PHP one thousand one hundred thousand line of J S and all the rest Just to give you a more accurate idea of the PHP here's how it evolved version by version One thing I find interesting when we look at this is how the ratio of Code size and comments to code has evolved if you look at the early code We had about only half the command lines. We had as the code lines and All in a very small number of files and if you look at Drupal 8 This is the striking because there's almost as much Commands as code and the number of files per line of code has dramatically increased This is this is the most thing a Dries posted about recently when he said we are going to have more code which is in a simpler Files smaller files and with an individually simpler structure some other points about history here CSS Maybe the front-end developers about you are going to be surprised But it only appeared in Drupal for seven until for six. There was no CSS in Drupal same for JS It appeared in earlier than CSS actually And it increased very fast. It may be even more than PHP itself So drop.org the original when the drop.org was created The block system was already present Block.org being a slash dot Inspired product was just basically a header a list of posts and a footer But in addition it has blocks on the other side So how did we think of blocks at the time? They were called boxes a block is essentially a box Which can have a specific look and feel not only for its color, but also its position This is in the files we can you can still find them in git If you go to the very early commits and you extract our sheaves from the commits to get to the earlier versions Which are inside it you will find these decisions The doc also included at the time examples of what blocks were for Latest headlines older headlines. These are things. We still have today the recent posts that the recent users are still there There's a current an issue which has been worked on even yesterday, which still touches this Of course now it's based on views, but it was already there 13 years ago oops Already in this first version before the software was even called Drupal There was already the notion of a theme support meaning Blocks and boxes as they were known were expected to have a modifiable look Unposition and at the time the two were not separated. They were just properties look is one thing Position is another and both were just settings of the block Briefly, how did the Drupal build its page at the time there was no front controller As we know it today, and you know most of you probably know that Until Drupal 7 we've been using index dot PHP as a front controller Which dispatch then to a menu execute execute active handler and then in Drupal 8 we have the kernel at the time This does not exist and drew a drop dotter was a much more traditional PHP application Which had individual pages each with all its functions within it For instance, you see there was an index PHP, which was the home page at the time There was a fact PHP, which was a list of articles article dot PHP, which listed individual article page and so on At the time we still did register globals and there was a dedicated back office which disappeared quite quite soon Going to blocks at the time blocks had these settings for colors and for look But there could not be placed by the UI you had to patch the code at the time to modify the how the blocks were going to be placed The placement where it was also very limited you can only place them at the top or the bottom header and footer and At the time there was this young designer called Dress, which some of you probably know Who created the first version of the theme system and at the time it was Based on a class as you can see the Dress theme was implemented by the Dress theme class so Originally on drop.org We had an object-oriented system and it worked by invoking as you see the theme object and the box method on it Much as you would expect these days Then within this it was much less cleaner if you look at the markup we had at the time You see the uppercase marker everything as HTML being built from PHP and In the end the theme box And these parameters Another example was how you would implement the theme for the box the future block This one is taken for the Natrack theme which was created by Kjartan Manz another of the early Drupal coin contributors So as you can see you would have this box method on your theme object And you would include the file for its configuration This is what this is how you would configure it at the time and then just build your HTML in PHP And sometimes of course already at the time because there was there are even earlier versions We didn't make it to the repository you would find a theme box in addition to just the box And which much the same thing This was because this was implemented in the what was called at the time the web board Which was a list of stories and it used the function form Whereas the other pages which were in the in their individual files as I just explained would invoke the theme method already compatibility issues And it looked like this This is typically how you would then have a node page because there was These were the article pages at the time You can see we already have many familiar elements the the author with its link the blocks laid out on the side And the region of the top and the top and bottom and the very very early of Incarnation of the Drupal logo which would become the duplicum later Except at the time it was black and had no eyes How did it fair performance wise at the time? As you can see it was not that bad How did I measure this? This is interesting to know probably I I took every version of Drupal every release of Drupal And I ported them all to php 5.3 and run them and the exact same machine this one So all the timings are taken on the php 5.3 on this machine So you can really compare them to see how you have evolved over time So at the time 10 milliseconds per request, which was quite good But remember we had only about 2000 lines of php to run and no front controller And this is the default theme which you would you would get if you took the code and tried to go to the home page Still no no duplicum on that one. It was the old drop.org logo which was an image of drops falling into water And then speed ahead here comes Drupal one. This was nine months nine months later What changed in Drupal one besides the name? Well at the time or at this time all the fundamental concepts we have been using in Drupal scenes are born the module system Is introduced the notion of a hook with its magical naming properties Is born and the notion of a white which we have been using in conjunction with hooks, but not only with them are born too At the time one thing I find interesting is that hooks were not magical like they became later You had to declare them as you can see in this example The module object declares that it will implement something called help something called block and something called admin And the hooks are registered in something called the repository Which will later become familiar if you follow the Drupal 7 development At some point for maybe six months to one year we tried to keep a track in the registry of Function and hook implementations Only to drop them at some point because this was not efficient But already at the time this was introduced as a potential optimization to find hooks Remember they were being declared at the time There were just seven of them Admin block, which is the one we are interested in in this history chron export help page and user Some of them are still there with us today What were blocks then as according to block help? Blocks are boxes okay two words for the same thing As you can see it will take some time for the two concepts to be differentiated in Drupal Blocks could be created by the code They were exported by the engine as the documentation says And in Drupal 1 they can now be placed by the administrator in using a ui But there's at least the difference what the administrator places are called is considered custom blocks And you can place them basically in the left or right region But placement in the header and footer is still code and controlled by code White is already used to place them what is within a block Again, let's refer to the documentation blocks are bits of takes html html or php Which will be added to existing content So at this point we have this notion of a central content and block being extra content being added Being pulled after the code itself And what is this content made of it has a subject and a text exactly like today But although we have now at this point blocks And the doc says blocks are boxes. We now have a separate theme function Which is called theme box in addition to the theme block function What's going on? Well there's the first start at refactoring the page cycle So some pages still have their own page controllers But a few of the other ones are using the module php page Which redirects the calls to invoke individual controllers and actions So basically the controller is invoked by the front controller in module php. It loads the includes They take the configuration from the environment Define the action functions and then we'll check for the parameters to share the action and invoke them How is an action built? It receives the data Recreates the build and then we'll invoke a box box repeatedly to build everything as blur as blocks The block admin UI can lay out the files on the left center on our right And the only the administrator can do this But a header and footer are controlled by the theme not even by the module logic or by core But by the theme so it's up to the theme to decide if it wants to include some boxes in the header or footer Oh one last thing at that time the blocks table which locates this which keeps the settings and the location for the themes Is theme independent meaning that any theme you would write at this time Has to accept play placement info which is based on the core theme definitions Because the blocks always expect to be placed in a region with the same name And the admin UI looks like this gorgeous, isn't it the block hook Is here and it basically much like it like it will look later except it has additional information Like today it must return the subject and the content But it also returns to another information which will be lost later on which is the information Which is which will be called the title in addition to the subject And a link the link is the strangest parameter in all this because it is not used anywhere The block needs to export it But it is only deployed on the back office and the UI placement So maybe the admin can see what this is supposed to be for It does not never appear on the front end Here is a simple implementation as you can see the code has already been cleaned up quite a bit over drop.org There's no html basically being built within a block implementation Which differs rendering to external functions cleanup already split form and function Themes for blocks or boxes have evolved They do still build the html, but at least now it's separate from the data building You can see an orange in the middle I think the subject and the content are now just variables in php which are printed and returned by the box How do you think they evolved? Well drop Drupal 1 is quite a bit faster than the original drop org although the code size has almost doubled It's about a 30% faster It can now render the home page in 6 milliseconds instead of 10 And it looks like this This is the uncowned theme created by Steven Wittens, a long time early contributor from Drupal Which was then known as uncowned and which who created later the garland theme Drupal 2 At the time the rhythm of versions watch much much faster than today's is only two months later Something some changes have still happened The box content is now filtered In the controller originally The filtering was done when the data was being extracted without any knowledge of the rendering which would be done upon them For security reasons already the filtering moves one step up from the model to the controller And this is the first place where internationalization comes in The block subject can now be translated although the content cannot There are not many changes regarding blocks in Drupal 2 The file layout introduced this is the MISC directory where you will find the favicon the javascript for common The PHP short tags are abandoned and you can start to see some blue Because the drop in the uncowned theme has turned blue one thing too themes were implemented as inherited from the original In team implementation And they had a method called abstract which was at that time not a reserved keyword in PHP Because this was for early PHP versions like PHP 3 And it had to change that that version to accommodate for PHP 4 And another place where OOP appears is you can see the content types like story Are now classes inheriting from a base node class I think Who would have expected at that time to see OOP in Drupal who knew this would exist? Yeah, not many I think The locale table appears and you have the first update script to to care for migrations from earlier versions Change log and credits appear and for me, this is very interesting Because this is how the first mark of the community taking place Dries at taking care to credit people where they are being where they need to be credited So to build on the the work of the others to show that this is not his work, but but community contribution Performance-wise we are still back to nine milliseconds, which is not as good as it could have been And you can see the first dropleton welcome dropleton Drupal 3 takes much longer It's only at the end of that second year that Drupal 3 sees the day And now blocks have changed quite a bit. They can be created by modules And they now have the the status of being disabled optional or required previously. They were just there You could choose to display them or not, but they were there anyway You had to change the code to make them disappear And blocks are no longer confused with boxes But boxes which are just visual elements found the team without blocks in the actual block content can also Be enabled disabled Many changes at the time new node concept itself Evolves there's the first page cache appearing for anonymous users The form building functions appear until that and time you didn't have any form dedicated building functions You had to build forms in each page which needed any kind of form And there's a flurry of new themes goofy, which we will see and jeroen yaron And the very early incarnation of what would become the stark theme I mean some machine thing which contains basically no markup. No styling just to see what's going on The registration of hooks in a global repository is now replaced by the user function exists So we now have the magical naming for hooks New version of the dropleton And the notion of relationships between entities content pieces at the time is introduced Also html markup has changed a lot. There were 74 font elements in dropleton 2. There are only 14 left in dropleton 3 The configuration UI has improved as you can see it now now has colors tables and a bit of styling And the interesting thing I think to look for is that you have this whole administration menu on the top Which lists the administration for every module installed on the site The blocks configuration is no longer part of the administration itself It's within within a section of the administration Region and it shows all blocks within a simple diagram like the block placement page We now have in since drupal 7 New dropleton new version of the uncone theme And these as you can see blocks in the center blocking on the side But still no blocks in the header and footer How does a theme for a block look like at the time? You can see the theme inherits the base theme And it implements the box method Which just drops out of php and I would put html It's still rendered raw from there by closing php and reopening it at the end of the class The base theme theme class only includes themes for links image and command controls Performance wise We have a problem because we are from we go from nine milliseconds to 14 milliseconds with drupal 3 This is the goofy theme With its dropleton on the right it can also have one on the left This is completely table-based at the time And most of the themes of that epoch are fluid they take up the full screen screen width and they are table-based The geron theme which was at some time visible on drupal.org and you can see the themes have settings Per user user can choose the the preferred theme This is something which was there early on and which was only removed rather recently in drupal history Drupal 4 again takes longer than drupal 3 it takes a full year for it to appear What changes? The block box duality has not been resolved and the box module is no longer there The placement is defined by blocks and it now stores both the region and the white separately All blocks are configured now by the administrator and there's an interesting feature we didn't make it in later versions When a block is scheduled to be placed in a region for a given theme and the that region does not exist In another theme there's a fallback mechanism by which the block which is configured to appear will still appear in the closest Closest region it can find This is a safety net which has disappeared since The visibility of the blocks is now controlled by a regular expression Which can be defined by the themes and controllers The content is still provided by the box method instead of the block method Lofts of changes. I won't list them all because it will take too long You can find the presentation on the site later on anyway For me the the most interesting thing is that xml rpc is introduced Since I'm the maintainer of xml rpc. This is quite dear to me And you can find the the first version of the the database layer abstraction There's a move from raw my mysql to using a db api based on pair db at the time And this is how posgresql made it into drupal The block admin placement ui is a bit better style but not much And the operations column is introduced Much like what we have later on and with the new operation controllers for drupal 8 Another look at the ui And the node form with this was really a striking to me when I saw This improvement in the rendering of the node form with the two column edit begin to avoid having pages too long This is an improvement we've seen again in drupal 8 Which was reintroduced in 6 and 7 by the tau and rubik themes But which had disappeared for most of drupal 4 and drupal 5 This is the node another strange thing is that you have now two node forms This is the the basic node form which you see with which is themed and accessible to contributors And you have the admin node form for the same node Which doesn't carry the theme possibly to go faster Performance wise, this is really dramatic We've gone from 15 40 milliseconds to 32 the response time has more than doubled For one, this is the first minor version which was actually actually recorded with a tag and it took six months There are some errors in the messages. They don't match the dates of the commits. I'm not sure which one is actually correct But the the order of magnitude is the same There's a big change here regarding performance of blocks Because previously all blocks were always build whether they were displayed or not And this was part of the reason why drupal 4.0 was so slow And in 4.1 we only build the blocks which are actually enabled Beyond that there are new theme functions introduced the profile module is introduced And you can now have a visual UI for to sort user blocks on per user That means that every user can choose how he wants the blocks to appear on his pages I'm not sure this is very readable, but the red text is just not by me It shows that that the blocks are listed in something which is not Understandable by the users. It is not the the order of the other node titles It's actually ordered by module name and delta Which doesn't make much sense visually Here is how the conditional build is being done. I won't go into the detail But basically you now have a blocks hook which builds a list of blocks And this is where the ordering is done and a separate block hook to build the the block themselves Performance wise We are back from 34 to 15 milliseconds, which is much better New minor version 4.2 Hook block has now two operations one for the list of blocks and one for the individual block view The deltas which were integers are not allowed to be strings although no code takes advantage of it And there's now the notion of a block preview So that blocks can the content of blocks which are can be edited on the site can be previewed Internationalization also allows to translate anything with the t function And the box function which was in charge of Building the block content receives content which has been sanitized above It no longer has to to be to to be preoccupied with both building the content and sanitizing it Again, we see the pattern of separating responsibilities. So that Many places in the code only do one thing where they would do several things initially Basically, as you can see the our practice as developer is evolving toward more standards better engineering plastics and so on The block class in the theme which is the block method receives now the region as a parameter Which means that blocks can now choose to have different renderings based on the region in which they are they are supposed to display This can be interesting. I don't know if anyone did any use of it But because it can afford blocks to have a build Adaptable renderings depending on the situation For instance a block could be rendered as a large table if it's supposed to be in the in the footer And only as a small list of titles if it is on the side for instance with the same block Something completely unexpected with the support for a sequel server Yeah, microsoft was supported in 4.2 The front controller is now index php and we now have a Theme engine which is extemplate The the use of the the individual theme methods Is gone there's only system module still using a theme Arrow method the other just called the new theme function, which we have been using ever since Clean URLs are introduced. There's a whizzy wig at this time And the the back of this no longer has its separate page which are without the theme Blue appears in most themes at this time and the first CSS fields appears Indeed much blue if it looks a lot like Drupal 4 or 5. Yeah, it does Let's compare implementations of how things were done in 4.2 versus 4.1 You see in 4.1 you have you had this function which took the three parameters No change in 4.2 and then you would concatenate strings And print in the end This is better than jumping in and out of php as was done in Drupal 3 But it still prints which means that if there is any output buffering it has to be done outside And also that you cannot control whether something which is in vote will modify the output or not In Drupal 4.2 again separation of concerns block only builds the box I mean prepare the build but the fact of actually outputting it is controlled by the block method The X template which is the first theme based on the X template engine With the new Drupal wordmark could we say which looks a lot like the newer versions of the Drupal wordmark Performance wise again, we are slowing 22 milliseconds There were a lot of 4.3.x versions Apparently there was an idea of going with three levels of numbering for Drupal versions at the time There was a 3.0, 3.1, 3.2 And then at some point after 3.2 the 3.x later was never tagged as an actual release and Drupal moved on to 4.4 It's only four weeks later. There's not much many things changing Basically the ability to have multiple sites within a single database because of database prefixing An interesting change regarding coding practice is that some controller actions no longer print, but they return This is a tendency which will evolve the other time Not much four weeks only again Performance wise this is dramatic Again, we are back to 15 milliseconds like we were in in a 4.1 4.4 We we see more delegation more separation of concerns the theme blocks functions delegate the listings to the block list functions Which is no longer a theme function instead of requesting the data itself It then called theme block to perform the individual rendering And the theme box function has almost disappeared. It's only there in the function for extemplate, but it's no use And finally someone notices that having a table of blocks without a primary key Is maybe bad and maybe something to should be done about it Because at that time there there's no pk on the blocks table Lots of other changes Considering the small amount of time elapsed the throttle module is introduced to reduce load for heavily working sites The cached pages no longer load all the code, which is a progress The locale module starts to cache translations smaller than a given length The push button theme appears and all theme functions now return instead of printing Marvin is introduced with the notion of a sub theme of the chameleon theme The microsoft SQL server is no longer with us It only stayed for the duration of 4.3 The goofy theme is also removed In 4.4 the the the theme blocks function which builds the list Is built by using a db query and some quite complex testing in 4.4 Again, there's a separation of the Concerns where the list is built by invoking the block list and then Only calling the the function A theme block implementation looks like this as you can see you are building a string Segment by segment and returning it much cleaner than previous versions again The chameleon theme looks like this it will stay until six i believe And performance wise we are still a bit slower at 20 milliseconds Six months later we have Drupal 4.5 There are a number of changes but nothing of concern for the block system Most notable changes are the fact that the new menu system The new menu system had how it was not at the time is introduced with the make cache parameter Which the Drupal 5 developers will know SQL can handle multiple connections and postgres is now used directly from Drupal db API instead of being based on per db The the theme and genes have been refactored the template settings and string shots the Ex template and gene is removed Sorry, the ex template theme is removed, but the ex template in gene is still the standard The international is internationalization support is completely based on the ui Here is the marvin sub theme of chameleon And performance wise it's a 15 50 drop we're at 28 milliseconds on the from the home page 4.6 which is when i discovered Drupal myself took six months to build And it changes the visibility settings on the block system Previously our visibility was based on computing regular expressions And you could decide to have an pp on 4.6 on match or accept on But we could still not build a php build php-based visibility control A change also in the visibility of rules is that previously the visibility was calculated Without decoding the alias which meant that you had either to not to use aliases or to to take into account The aliases when choosing on which pages the blocks would appear In in 4.6 you now have a canonical path which makes it makes it much simpler to decide whether or not to show a block You can now also filter by node type A new block value appears on the hook block you can now configure a block So it has its own hook for configure to build the form and save to save the configuration Other changes UTF-8 is now a standard everywhere php-5 is supported And the page cache shows how effective it is because without the page cache We are all around 90 milliseconds on the home and only 19 with the page cache Per db is completely removed at this point and the admin controller finally disappears The block configuration Is now on a page which can also display blocks itself And performance wise we are a bit better at 90 milliseconds Drupal 4.7 Regarding blocks does not change much. It was a big release because notably of the form from api introduction But blocks are just Much the same as in 4.6 I wonder if on the changes you can see them Basically the page cache has this notion of a loose caching That free tagging is introduced for taxonomy Themes are converted to php template which is the new engine and completely replaces x template Postgresql which would previously use stored procedures Only relies on normal queries at this time and the queue module is withdrawn Let's not mistake things the queue module had nothing to do with the queue It was a list of content to be moderated not a queue api like the one we have later Let's take a look at the theme changes which are supposed to be simpler As you can see the Themes in x template would just print variables by putting them within braces if that sounds familiar And in php they are just variables within php code You can create custom blocks in the ui This is on marvin And performance wise 4.7 is very good. It's back to 10 milliseconds much like drupal one drupal 5 took Eight months to build The only change for blocks is the visibility by role which is very important from an access control standpoint And you are no longer Required to provide a title for the block by default it will use the admin title Many other changes we have no time to look at them just the cache 50 milliseconds without the cache instead of 92 in 4.6 7 milliseconds with the normal cache and 5 milliseconds with the new aggressive cache The site directory is introduced And we have this colorful push button theme The per role visibility is configured on the page of the block configuration page like the others And here is this extraordinary number 5 milliseconds for the fully cache in the home page Drupal 6 One year later Introduces the block cache because because you see drupal 6 is a big release. We've had lots of code changes in it It became much lower than 5 so changes have to be done and the block cache was introduced because the cache The blocks are places where lots of extra work is done in comparison with the main content of the page I mean when you are doing building a page content Basically, you do a main query to list some things or you load an entity or something like that That this is one unit of work one could say and then most of the blocks will do Much the same type of work as the main content Meaning as you multiply the blocks in the ui which was quite the fashion at the time You have lots of work being done for blocks may be much more than the main content of the page itself So it was important to introduce caching for these blocks to avoid having to rebuild them all the time The theme block function is now a term become a theme template instead of a function The other functions don't change and box template is still present At last there's a primary key on the blocks key on a table Many many changes. We don't have time to list them Note that at this time it is recommended to develop under error reporting e strict and e all The block cache I made this orange square on the that end on the page It can be disabled if you have any software of access control on the site Disabled or enabled There were interesting questions about this caching that this page shows how it is implemented And I had just two questions about it about it. Why does it work that way? And what's in the cid the key used for the cache? If you have the time to look at the the details of this presentation You should ask these questions to you. They are really interesting to resolve There's a lot of documentation regarding the use of the new block cache But regrettably it's only in the source code. It didn't make it to the documentation pages on drupal.org And as you can see, it explains that user one is excluded from block caching So if you try to debug something and see if your caching works, you should never log as the user one, of course And users and developers I mean are encouraged to roll their own caching logic in most cases You have many rules explanations of what to cache and what not what how not to cache But there's a major advice lacking I mean you can cache per role you can cache per user per page and have a global cache The problem and you must think of it because this still applies even on 8 today If you decide to have the per page per role or per user caching You will just have a geometrical growth of the number of caching trees and you will just bust your cache So this is why in many cases I've been I've had to audit The block the block cache was not useful because it's been is always full Because people want to be true to granular And in the end it's much less efficient than not caching 4 milliseconds, this is absolute record And drupal 7 3 years, which we all know these days The hook block doesn't change much except it's being renamed where we had previously One single hook with parameters We now have four separate simpler hooks, which takes less parameters. And again, this is separating missions So the responsibility of the block hook Were multiple and now each hook has its own single responsibility Many many properties we have no time for this the constants for block caching change name because the this non page level caching Is used elsewhere in drupal The tables change name And we know here is the final block preview for 7 using garland performance wise In cached mode drupal 7 is almost as good as the 6 or press flow It's still 6 milliseconds only And drupal at the time I still expected it to be three years later, but as dristolder it's yesterday It will probably be three and a half or four years probably What well, you know, uh, it's been a lot a large discussion topic drupal 8 is ascetic composer doctrine Whatever and there's also some drupal code in it Regarding the hook system That it's basically going for blocks because blocks are not plugins Which means there are classes and the properties instead of being defined by an info hook for discovery Are defined by annotations doctrine annotations on the block classes Uh, this doesn't change the basic functionality the info hook becomes the annotation The hook block view becomes becomes the build method on the on the block class Configure and save all the same rform and submit methods But there are new properties which were Spread in various places within the code base and which are now gathered much more cleanly on the block interface There's first the access interface Which is generalized from the need to filter bind type by path by whatever It's now just a method for access like just like you have for any sort of entity You have a settings Hook which can provide the default configuration settings much like the option definition in views And finally you have validation of the settings configuration Because although you have you've had a form configuration forms for blocks since drupal 4 whatever You didn't have any form of validation on this at the time. You had to build your own form level validation Derivative blocks are a complex concept. I would say that it enables to have multiple instances Of blocks with from the same base class And here is an example of how a block implementation looks in drupal 8 As you see it's a class within a name the normal namespace for the block plugins within your module It's it inherits from the block base It takes the plugin annotations and it inherits translation in order to be able to translate the block content and title The implementation of blood docs just has the methods to implement to provide the content settings and whatever And here is some data about how the code base evolved in recent releases As you can see in drupal 6 the block system was three files 600 lines and a tiny bit of javascript in 7 it has tripled to almost 1100 lines Still a tiny bit of js and in drupal 8 it has exploded to 5000 lines yesterday And that javascript doubled and 400 lines of fiamma in core Just as a comparison point drupal 3 Completely complete on his own without commands was 5600 lines So this means the block system in drupal 8 will probably be about about the same amount of code as drupal 3 The ui for blocks has very interesting changes Because something you may have suffered from in drupal 6 and 7 is the very high Blocks pages which a load needs to load all the blocks and hide very high memory Requirements and takes forever to load because it needs to learn to load build everything This is now no longer present in drupal 8. This is a very good ux change for me Because you now have separately per module the lists of blocks And a separate simplified configuration form. This looks like this if you have never installed drupal 8 As you can see you have the list of enabled blocks and only these on the main list Blocklist page. So this means you only need as much memory and cpu as you have chosen to display in what will be your Frontend pages in the end And then separately you have the list of On which you add new blocks to this list through this page of used blocks And you can filter it as you can see on the right by the module providing it Or even search within the list of modules, which is a boon for sites with many many modules And the list will be filtered by what you have chosen in the search box And you can still add a custom block by clicking on the blue button on the top No image and it will adjust upon a dedicated form for this This is very good ux change for my point of view Performance wise we all know The problems we have with this or the best case I have with the default class loader is 46 milliseconds for a fully cached page And with the apc class loader only down to 36 Which is not Satisfying I would say Some more great numbers. This is the how the landscape goes version by version As you can see, we started at 10 milliseconds. We hovered around it in one, two, three, four, seven, five, six, seven And other versions have had problem As you can see, Drupal 8 is a bit slower than 40, but it's orders of magnitude a greater And it's still not much slower than Drupal 40. So maybe that's not as dramatic as it may seem to some people Thank you Are there any questions you can take the mic if you have anything to ask about this? Well Then it's done. Oh, yes, please. Please go to the microphone so it can be recorded I'm not sure how relevant it is, but what about the reintroduction of the boxes module in Drupal 6? I'm sorry. I didn't understand what you said or the introduction of the boxes module in Drupal 6 There was an alternative module called boxes. I don't know if it's relevant I only cared about core at this point. I didn't look into this module. I'm not even sure what it did exactly One thing I could say about box versus block is that there seems to have been much rejoicing at the time Box finally went away in Drupal 7 I know it's probably just a naming more than the functionality Just interesting that a module called boxes back up in Drupal 6 It's more used with features and stuff like that. Thank you I was at a Session yesterday and they showed how contextual links and the new marker was loaded dynamic by javascript So they can cache the html And the user will have it in the local storage and only get it if they want it And I was thinking is it possible for that kind of future for the blocks? So you just have a place marker with some hash code and you output it and then the user will load the blocks If they don't have it already in the local storage Yes, that's typically something you you could do probably using a variation on the oath cache oath cache module Or using yes, I of course, which is another technique But basically if you output markup that way the problem with this is that you cannot know where you are building the page for an anonymous user Whether the information will be there. So you still have to provide it anyway Or if you just output the hash marking the block identifier Then some code must run on each page for all users just to Do further calls to load the cache the information basically from local storage And that oath cache does this today For seven of course Yeah, they they had some caching based on the roles the user have and could make it But there are problems when you have uses specific Indeed oath cache if I remember correctly does not use local storage basically It's just using the normal browser caching and based on the headers output by the by the site But it could be done. It's an interesting idea. Maybe you should suggest it in the issue queue for oath cache So a comment on performance Oh pita. Yeah, so I think Drupal 8 optimization is just starting now So the performance numbers there should be actually You know two or three fold better by release. So I think people shouldn't be disheartened By those performance comparisons. It's still really in the middle of finalizing A lot of the optimizations and so the one mentioned though in terms of loading contextual links part of the problem is also of course that that The ajax system hasn't really been optimized. So those requests are still relatively slow So if you have to do many many requests to build one Drupal page, it's going to be slower So to trade off between what you can cache and how slow rendering the pages Also a plug. I'm giving a talk on the Drupal 8 plug-in system This afternoon. So if you want to hear more about that, please come to my talk All I'll go and go to the cpeter. He's a very interesting speaker most of the time And yes, I introduced these performance notes because I wanted to show we've already been through this You see when 40 milliseconds appeared in floor zero I it wasn't there at the time But I imagine it must have been quite a shock for people used to seeing pages in less than 10 milliseconds and still we recovered from this I'm confident we could we can recover from it for 8 to There was a point in your slides when the template system went from squiggly brackets to like embedding PHP Which everybody laughed at because it looks looks like kind of going from twig to php Do you do you know the background to why that change was made and I think there was I'm not sure because I was not involved in in front at all at the time But one thing I've heard from people working with x templates or smart here, which was mostly like it functionally wise is how This was part of the reason for being slow because at the time the smarty and x template would just load and perform transformations based on regular expressions on the pages And they had to do substitutions using the reg x engine So this means loading code into a completely dynamic code which cannot be cached And twig works completely differently from this I think you're referring to this page Because twig actually takes your code with the braces the double braces actually not simple not simple ones like this And it it translates that to a class-based code in your generator the code directory in sites default files php twig And this code translates all your the interplay it replaces all the interpolations By by building the code Markup directly in php So this is the reason why twig although it first Frightened many people is actually quite good and can be as fast or faster than php templates and just on that You know dribble for the people implementing dribble were still largely developers. So when php template came along The power of it It was just so popular that People never ever you could still use smarty at the time when it came along and people just didn't use it Okay, I think we're done and thank you for having attending and the interesting questions Don't forget to rate the session on the site as always. Thank you