Over the past month, I've been attempting to learn more about Drupal 8 by attempting to port the @font-your-face module which has a lot of different pieces; it touches on Content Entities, Config Entities, regular entities, views, classes, hooks, and more! I'll try and blog on my experiences with that in the near future but an interesting problem that I ran into is that I am using taxonomy terms to categorize Font Classifications, supported languages/subsets, and generic tags.
Acquia Dev Desktop is a quick and easy way to get your drupal site up and running quickly. Its easy to recommend to other developers who are just starting out with Drupal. Even now, I'll use it on my own projects since it is easy to work with. But what if I want to use my own version of Drush?
About 2 years ago (soon after Drupal 7 was released), I had a site with a number of fields attached to a content type. When I had to clear caches and reload a page, it would take an awfully long time. This is because the site would need to run load each node, run a query for each field, process it, and more. What was good, though, is that all of these fields would then get placed into the cache_field table so the node could load faster on subsequent loads.
Most folk that talk to me about linking content within a Drupal site (and use a wysiwyg module) know that I am a big fan of the Linkit module with pathologic. It provides a nice way to reference content within your site, keeps a simple url, and pathologic will convert it to the nice url. However, I recently ran into a problem with the course catalog on our campus.
I've been playing around with using the new version of migrate for a little while. But its been on the more boring side and learning how to use migrate with CSV files (which admittedly feels quite good ^_^) And it was only after an email from Tom Camp and in an effort to get my presentation on Migrate ready for NYC camp and Drupal Camp LA.
A few months back, I blogged about creating dynamic migrations. With a small amount of code, you can do something very powerful. You can bring in large amounts of data that need to fit into different places with one simple class. And when all of these containers are holding close to the same kind of data, it makes it an obvious choice. Commerce Migrate approaches migrating data from Ubercart to Commerce in such a way and does a great job of bringing over the core fields of an Ubercart product. But what do you do when you need to add additional sets of data for a particular type of entity bundle? The client that needed my help had various kinds of information attached to their products - taxonomy terms for various vocabularies, additional image fields, text fields, stock, etc. Fields that do not get associated with Commerce products / product displays in the initial migration. When I initially saw this, I was completely stumped - it meant rewriting all the dynamic migrations that were being done by commerce migrate as actual migrations (not a task I was looking forward to given that I would essentially copying/pasting code to get the desired effect without actually using Commerce Migrate).
Yesterday evening, I was working with a client on their site who are doing some interesting things with one of their custom search pages. They send ajax requests to the backend to get 2 types of values for their user:
- A count on the total number of a node type X that matched the criteria
- A count on the total number of another node type Y that is referenced in node type X (Y can be referenced multiple times by various X but for this, we just want to get back that value.
Instead of opting to go with straight database queries to get the data, they were using the EntityFieldQuery manner to get the initial list of X since they were using fields. Its not quite as fast, but its a much more flexible approach (and if they opt to change their field storage in the future to something like MongoDB, they can have something really fast without having to change a single line of code!). The one problem with EntityFieldQuery, however, is that it will only return back a listing of entity IDs. Meaning that if we want to get other pieces of data, we have to load up the entity. In their scenario, the only other piece of data that they wanted to retrieve was the reference field data. And performing an entire entity_load (or node_load to be specific) would mean they would also need to load up the 50 other fields that they are storing. So doing a retrieval like this on uncached content meant that the retrieval of this data alone took 3 to 4 seconds.
As many folk know (and as folk can see by my posts on the topic), I am very big fan of Migrate. It takes a while to figure out what you want to do and how to do it, but the power is absolutely immense. And having complete control over the source object down to manipulating the destination node/user/entity while still working within a framework has made this my favourite module.
I am a big fan of the Display Suite module. Its quite flexible and gets you up and running with a look/feel fairly quickly. One of my favourite features of Display Suite is that you can create various build modes so that they can power your views or results or have then get used in a various areas of your site. Find out how I keep things speedy through the use of the Entity Cache module with Drush.
Over the years, I've seen and heard the phrase "Don't hack core!" mentioned by countless Drupal developers, designers, site administrators, etc. There are many blog posts on the matter (the most recent being a few weeks ago though his stance is slightly different from what I see from the rest of the community) and the number of kittens that die whenever someone hacks core. There was even a wristband created a few Drupal Conferences back. Heck, I may have had it and worn it at some point. Read on to find out.
Click here if you want to skip directly to the 'how' and slides.