drupal

Pimping the CCK display fields UI

Ever dreamed of having a node template with only this in it: print $content; ? Well, my sandbox site currently runs a patched version of CCK which does the following: order the fields on every display, not when managing them. You are also able to render the fields in what we call node regions. Screenshots and a first patch is available at the end of this post.

Rendering fields

In the UI of CCK we all know right now, it's possible to set the order of the fields on the 'manage fields' tab. This affects the order on the node form and on the full node, teaser etc view. Since the arrival of http://drupal.org/project/nodeformcols, it's easier to have a more finer control of the node edit form and we wanted to have that same control over the full node, teaser, sticky view .. Adding a weight property wasn't that hard to accomplish. You can see that the order of fields is different in those 3 contexts on the sandbox site. We're still looking howto affect search results too ..

Node Regions

To make our themers happy, we added node regions, so it's easier for them play around with the fields while creating their views, teasers, full nodes etc. They can play with 5 regions without having to create one single template file. Only CSS, that's what they were hired for in the first place :) If you look at the sandbox site, you'll see that with those regions, a full view vs sticky looks different, only through the magic of css.

Extra fields

In the version we currently have at work, we are able to add extra fields with custom formatters. It resembles a bit like the 'content_extra_fields' hook you can currently implement. This gives us the benefit to render the title beneath an image for instance. In the next few days, we'll be looking on howto to extend that functionality in the CCK module.

Patch

We won't release this as a module or as a fork of CCK, the best way to contribute is to release a patch of course. We're still cleaning up the code a bit, but a first version is available. Apply it against the 6--2 branch of CCK - latest dev will probably work too. As soon as we think the patch is clean, we'll post it in the issue queue of CCK. In the meantime, if you have any questions or suggestions, ping us on IRC (swentel, stalski or zuuperman).

Screenshots

The manage fields now only manages the cck fields.

Display fields now controls the order and the region, here the full node.

Same screen, but now the sticky context.

Shot of firebug where you can see that 3 node regions are rendered.

Topics 

drupal, theming, cck, planet

Dear edit button, welcome back!

It's a very old issue, a frustrating one in fact: the edit tab on nodes disappears sometimes due to input format permissions. I wrote a module that fixes this for D6 which works for the default body field , CCK textareas and I'll be adding support for other textareas on other pages too (think blocks & views). It's available in my sandbox for testing at http://cvs.drupal.org/viewvc.py/drupal/contributions/sandbox/swentel/edi.... There are a few todos left, marked accordingly in the code, so if you want to help out, go nuts! I'm not sure yet if I'll release this as an official project on d.o, I'll wait for some reactions from the community first, so leave a comment, contact me, ping me on irc .. we'll see after that.

Anyhow, say hi to the edit button again if you test it :)

Hack Drupal core!

No better title to get everyone's attention - well, any Drupal developer out there who once pledged never to touch any code of core when running sites in production. I used to be one of them, but I stepped over to the Dark side recently.

For a fairly large community site (think OG, node access control, private messages etc), we were getting in trouble giving authenticated users a decent browsing experience. The worst page was taking 16 (yes, sixteen) seconds to load and others were getting in trouble too now that the number of users and nodes was growing rapidly. Not acceptable of course, so we went searching for solutions:

  • Advcache: the advcache module comes with a few patches but we only applied the one that caches URL aliases per page. While drupal_lookup_path is generally fast, it's sometimes scary to see it appear 300 times in the query log for one page. With cache_get('cache_path') you suddenly feel much better.
  • Memcache: it's possible to swap the default caching implementation, so this seemed like a good solution. It took me a few clicks to realize that it actually makes loading pages extremely faster and seeing another 100 queries less, no further discussion. Since this is the first time we're using it, we opted to use memcache.db.inc which still writes the cache to the database so in case memcache dies we still have a fallback.
  • Block cache alter: I'm biased since I actually maintain the module and I don't feel any pain hacking block module :)
  • Rewriting one query generated by views that took around 11 seconds to give back its results. We analyzed what data we wanted and wrote our own block implementation. I'm not critising views here, in fact, we still have a lot of views pages and blocks in the site which run perfectly fine. It's up to a developer to take a good look at the mysql logs and see which ones are getting in trouble and fix them if needed.

After every step, done in the same order listed above, we recorded the numbers that Yslow gave us which you can see in this picture. I still regret not logging the number of queries that dropped after every step; some pages which sometimes needed 600 queries now only need 60-70 db hits to generate the page for an authenticated user. The conclusion is that our server now has less load, pages are generated faster so we have a happy user now - and hacker too in my case.

I hope I don't have to apply patches anymore though in D7, so I'll start following http://drupal.org/node/367257 (and swappable path.inc and handlers) even more closely than I did right now - we all should!

Topics 

drupal, cache, memcache, planet

It is not always the fault of Drupal

Take a look at following HTML snippet:

<img src="/sites/default/files/LOGO_adview_70_0_4.png" style="display: none;">

If you know a bit of css, you'll know that the image will be hidden in your browser. However, we had no idea where the inline style element came from, it shouldn't be there at all. We are using a simple node list generated by Views and after looking in the templates, custom modules, filters and tinymce settings we decided that this couldn't be a Drupal problem and had to look somewhere else.

In comes Adblock Plus, which is probably the first add-on I always install in my browser on a fresh OS install to block those annoying banners. And in our case, the add-on worked a bit to good. Take a close look at the name of the image file: LOGO_adview_70_0_4.png. The adview in the name is were things went wrong: when editing the same node again, Adblock Plus automatically added the inline style element in the HTML which is saved when updating the node.

It's really amazing how much time you can waste in debugging sessions.

Topics 

drupal, bughunt, planet

Block cache alter just started rocking!

A few months ago I released block cache alter which did nothing more than adding a fieldset on the block configuration page enabling you to change the cache setting of a block. A small first step making block cache rock a bit more in Drupal 6. I wasn't sure how to take it a step further, but I'm happy I'm not alone on this case.

With a tremendous patch submitted by batbug2 (see #354080), the module got much smarter. You are now able to set expire values for each block or have it refreshed on certain actions (nodeapi, comment and user). In fact, a lot of the patch by batbug came from the excellent Blockcache module which never got ported to D6. After some thinking I decided to add the patch into the module because in the end, they really have some differences:

  • You need to apply a patch to the block module if you want to have all possibilities. 2 patches are available, take a look at the documentation that comes with the download which one suits you best. Note: you can still simply run without a patch, you simply won't have that much control when the cache is cleared.
  • If you choose to refresh on say a node action (insert, update, delete), you can also specify which node type.
  • 206 passes, 0 fails, and 0 exceptions. That's right, it's fully tested, if that ain't nice ..

If you're interested, please help out testing. The development release is available at http://drupal.org/node/395422. The sooner I get feedback - good or bad, post comments and follow up patches at #354080 - the faster I can release a new version and start writing patches to fix block caching for good in D7!

Pages

Subscribe to RSS - drupal

You are here