![Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]](../sites/all/themes/drupal4hu/images/bg-center/bg-center_4.png)
As this is the first in my update report series, it will contain a look at the past and try to explain things to people who are not so familiar with Drupal.
Tl;dr: for the first time, right now it seems the dream of running Drupal 8 on MongoDB only is totally attainable.
Previously, I was writing these in private email to my boss at 10gen, but I believe it's better in public. Most of this one was actually sent so the tone here and there might not actually be of a blog post. Recommended reading: Updated Drupal 8 release schedule from Dries.
Drupal always had modules extending its functionality (modules) and pluggable subsystems replacing some of the functionality. The method of pluggability was very simple and incredibly crude: the name of the file to be included, say, for session handling was read from a setting. Such settings are called 'variables' and they can be stored either in settings.php (where database connection details are) or in the database. So you added $conf['session_inc'] ='sites/all/modules/mongodb/mongodb_session/mongodb_session.inc'; and you were done. mongodb_session.inc implemented the same functions as session.inc did. If you consider that Drupal 7 was the first version to require PHP 5, this is not as bad as it soiunds: it was a fast, cheap, simple way to implement pluggability in a language (PHP 4) without interfaces. There was zero meta data, there was no discoverability and so it was absolutely impossible to provide an UI.
Drupal 8 attacks this from several fronts. One front is the plugin API itself. There is a very nice OOP-based plugin API http://drupal.org/node/1637614. Obviously, quite some of the things need to be overridden to make Drupal 8 run with MongoDB only will become plugins and so a good plugin API is necessary. The Drupal community have chosen annotations as the way to provide metadata. The interest on the community side in plugins were using them to provide a unified mechanism of output ( http://groups.drupal.org/scotch ) which means there will be a lot of plugins. That didn't lie well with the fact that the Doctrine annotation reader relied on ReflectionClass -- doing discovery might have meant consuming a lot of memory. I have
added the capability to use the PHP tokenizer to extract the doxygen from the source code which is slower and uses more peak memory but once the reading of one class is done, the tokens can be dropped and so it does not matter how many classes go through the annotation reader, the memory consumption does not skyrocket. Our annotation reader is based on this capability, it was well received and at the Midwest Drupal Developer Summit Dries accepted it and on August 11, this was committed. With this, the plugin system is ready.
Another front is using the Symfony dependency injection container (DIC). Now, this obviously won't work everywhere because Drupal core is a gigantic codebase and converting that to be fully injection-based is not feasible within one release cycle. To bridge this, Drupal 8 has a DIC statically stored and retrievable from any of the old code, the static function is called drupal_container(). There is a lot of work going on to make the DIC more widely used, speedier and so on. I am working on this too because fostering a more DIC-based codebase is clearly beneficial. It is now possible to write PHP files from Drupal and the DIC will be the first to use it.
Now, it is possible to change the services necessary for bootstrap from the same settings.php mentioned in paragraph 1, the rest can be changed from a module (this duality might or might not be resolved by release time). This is of course much nicer than the current pluggability and will work well for us.
That's about pluggability.
One of the biggest hindrances in getting Drupal to work with MongoDB only was how the configuration information is read from arbitrary, scattered SQL tables. This is rapidly coming to an end, there is a configuration management initative which provides a centralized way to manage configuration. The community is interested in this for deploy purposes, for MongoDB the interest lies in getting rid of those pesky SQL tables. The canonical storage for configuration are YAML files and normal caching is used to make sure it stays speedy. I am working hard on helping this initative -- its success is absolutely paramount. I got close to get rid of the "system" table (storing the modules data) but it was decided it's not fully configuration but also needs the new key-value API. I have made the latter ready and converting the modules to it right now. I am worried a little about the brittleness of this whole system install time.
The other thing I will work on CMI-wise is the date format storage. I already cleaned up the dependencies for that by finishing the basic API for multilingual configuration. While multilingual capabilities have nothing to do with MongoDB, getting rid of the three date formats table is absolutely necessary, it's three tables joined together on bootstrap if the cache is cold, so they must be gone.
Meanwhile a lot of simpler settings forms are getting converted to the config system and as Dries posted today, this conversion can be done before April 1, not December 1, making it very likely the conversion finishes.
The biggest problem for CMI is the lack of funding for the initative leader http://heyrocker.com/funding-cmi .
A thorny problem for the Drupal community is the path alias storage. It does not fit anywhere neatly. However, this is pluggable already in the old fashion (with a notion to convert it to the new fashion) so solving this is not a priority, writing a MongoDB specific path lookup implementation is already possible.
Drupal provides flexible data storage by the means of field API. This is progressing well without my help, other companies are financing progress here on several fronts. And , it already worked in Drupal 7 mostly, so this doesn't require much of my attention just a little review to make sure the pluggability is kept. I am not worried: the ability to handle remote data with this API is considered a priority so pluggability will not regress.
Drupal has a listing API which was not part of core before but it likely will be in Drupal 8. An update just has been posted
http://drupal.org/node/1772494 here. This seems to progress nicely aswell, some companies are providing funding but this is a tremendous undertaking also needing funding http://www.angrydonuts.com/help-fund-views-in-core Whether EFQ Views will become part of core is not yet clear altough Dries' mentioned it in the updated schedule. I had recent conversations with some of the Views on retooling EntityFieldQuery to disallow queries spreading across multiple entity type and so drop the trinity (entity, property, field) of the conditions and sorts and have a single condition and a single sort. Because once we know the entity type, the entity-level conditions can be specified as properties and fields can be derived by looking at which fields are attached to said entity type. Once this unification is done, we can unify conditions used in the database layer, in EFQ and in Views into one system. This will add AND / OR to EFQ and make efq_views hopefully smaller making the integration a lot easier. We have some use cases for cross entity type queries posted to an issue in the efq_views, I will think on those and provide recipes avoiding cross entity type queries (involving some sort of references for sure) -- they already need help for Drupal 7 and for D8, even the capability for these sort of queries will be gone. Also, I already looked into this and while the actual refactor is not a lot of work, the tests simply are not salvageable, they need to be rewritten.
Lastly, as Dries clarified what is possible between December 1 and April 1, I have some hopes on converting a lot of listing pages (aggregator, forum etc) to Views and further perhaps, perhaps to efq_views. Previously I had no hope of these modules having a chance working without some serious override work but now even these look hopeful.
Commenting on this Story is closed.
Note that Karen, Chris, Arlin, Adrian, Tim and I have picked up the pace on working on Karen's Date in 8 initiative. Karen will handle formal public updates. However we have been discussing the issue of CMI and date format storage, including the multilingual/localization issues and the prospect of removal of the date formats table (Chris have been working ons some potential patches/code). We'll make sure that we keep you up to date to ensure you're in agreement with the approach, and in the hopes that we can reduce your workload, help facilitate the D8 & Mongo DB work, and ideally help Karen succeed with her Date in 8 efforts. - Willy Karam
here
Getting Towards You Around The Web Hosting World
When designing a site, you'll must select a internet hosting business in the course of time. Although you may don't know much about website hosting, there are many simple questions you can request to ensure you get what you need at a cost within your budget. Please read on for what you must watch out for in your search.
The downtime from the web host should be cautiously scrutinized. The time utilized to conduct web host maintenance, along with the time of day the constant maintenance is carried out, ought to be taken into account. If they seem to be traditional while in top several hours or regularly through the calendar month, you need a much better host.
Back up all your information, don't count on any hosting company to achieve this. It's up to you to make sure you support your site frequently. This really is the best way to ensure a difficulty doesn't destroy your data. If your site is Search engine marketing intense, it is actually particularly essential to never take a chance on shedding all that function.
Make sure that there are actually no charges for cancellation. You could plan to terminate your service soon after few weeks. When you go to terminate, you might find out your company features a massive cancellation cost. This can be a normal exercise, especially for website hosting professional services which are economical. Make sure you understand what the consequences will likely be of ending a contract earlier.
Cheap web hosts is probably not the best option. Although you'll without doubt be tempted by their low prices, you need to know that they often translate to poor professional services. They possibly have got a unsafe business model, or they can be cutting edges in ways that will turn out impacting you and the web site.
Find out about your possible number to see what sort of web sites they take care of. A great deal of cost-free sites offer you only static internet pages, therefore you can't add more words scripts of your very own. If you discover on your own needing a active scripting page, you might need to find an reasonably priced spend variety as an alternative.
Do not allow the number of alternatives provided by web hosting firms to overwhelm you. Above recent years, numerous new hosting providers have came into the industry several present rock-base prices. Remember that in web hosting, like in the majority of things, you receive the things you pay money for. You are able to filter the options down by in search of your best preferences inside a web host, and evaluating costs and products appropriately.
A great hosting company is communicative. You want a number that communicates using its buyers and offers them info on any updates or downtime and upkeep. Also, it is important to get a hosting provider that can answer your queries ought to any issues develop.
Read more about the backdrop of your web hosting support just before buying a prepare. Some service providers make outlandish statements or claims that should not be substantiated. Performing your research is the best way to make the right judgements.
Work out how huge your website will likely be in the next season and choose a internet hosting plan that offers you sufficient harddrive room. An HTML webpage will take hardly any place, but incorporating images or videos will need a lot extra space. For web hosting documents alone, around 100MB - 1 Gigabyte need to give you a good beginning program for your personal domain name.
If you love services or style user interface from one company, you don't must sense that you need to utilize the internet hosting services they provide as well. Most hosts that you deal with allows you to use distinct professional services, even if you may very well use a tougher time addressing problems by doing this.
Simply because an internet host clients are cost-free, does not necessarily mean you ought to guideline it out entirely. You may be cautious about free website hosts simply because most of them location banner ad advertisements in addition to your web sites, making your site appear not professional. Even so, some totally free hosts don't use banner ad adverts, so it's really worth thinking about cost-free internet hosting providers that appeal to your interest instead of judgment them out automatically. Keep in mind that by using a totally free variety will save you lots of money every single year.
Ensure that your domain address is signed up on your part rather than your hosting provider to help you make it should you transform suppliers. This places the charge of your domain name in your hands, as an alternative to your host's.
Picking a hosting company which is actually situated in the exact same country as the site visitors will increase the speed of your respective site considerably. By way of example, if your enterprise web site is geared towards United kingdom citizens, make certain that your computer data host is in close proximity to your viewers.
Usually do not opt for a free hosting company because the services are free of charge. Internet hosting providers which can be totally free normally force you to have adverts on your own website. In some instances, the adverts will not be relevant to your web site and you will probably struggle to handle what presents itself in your web site. Ads will pop up randomly, entirely outside your handle. This will not only give your website an not professional visual appeal, your viewers will more than likely resent the invasion.
Check out the internet site of your potential hosting company. In case the organization has a questionable, glitchy or otherwise in question website, avoid it. They might be a brand new firm without any expertise or maybe a swindle. A properly constructed internet site reveals that they have a great interest in relation to depth and they have excellent practical experience when it comes to web site design as well as in relation to Html code.
Prior to signing about the dotted internet range, make certain you understand the details of your responsibility using a hold provider. You should know about secret service fees that their ads don't point out. Specific things, including secret costs, costs, and charges if the contract's length isn't followed by way of, could add up in a big way if you don't exercise caution.
Searching for a web host is really the same as looking around for everything else. You need to understand particularly what you wish and then figure out what can be a cost that is useful for you, afterwards you need to find services which aligns by using these expectations. Hopefully, with the details you possess acquired with this particular post, you will be able to perform just that.