Hey there, Drupal people! Time for the monthly unstable release! Lots of goodies this time... For module developers who wish to get a jump on upgrading their modules to Drupal 7 ahead of time, check out http://drupal.org/node/224333 for a list of API changes. Remember: there are only 165 days left until code freeze, when we must cease and desist all world domination plans until Drupal 8! http://drupal.org/community-initiatives/drupal-core has a nice list of all the current initiatives going on (feel free to add your own as well!). If you're looking for the places to make the biggest splash, those are them. :) Or, if you're just getting your feet wet with patching and want something a bit easier to cut your teeth on, try tackling one of the issues listed at http://drupal.org/patch/novice ! Friendly volunteers are always available in #drupal in irc.freenode.net to offer assistance. With that out of the way, here are some of the highlights of DRUPAL-7-0-UNSTABLE-6 (full release notes attached at the end). - In JavaScript-y news, Drupal 7 now comes with jQuery 1.3.2 and jQuery Forms 2.21. it's also now possible to use jQuery alongside other JS libraries (Prototype, etc.)! This requires a small change to your JS code that you can do even now in Drupal 6 as a best practice. See http://drupal.org/node/224333#javascript_compatibility for more details. You can also now reference external JS files from drupal_add_js() rather than having to do silly workarounds with drupal_set_html_head(). Yay for consistency! - Massive re-working of image handling libraries (basically ImageAPI in core), which gives us important groundwork towards ImageCache in core http://drupal.org/node/371374 and even possibly ImageField in core. OoOoOoo... :) - The new database system (DBTNG) now supports pager and tablesort queries via "extenders," which means that we can now work on converting pretty much all of Drupal core queries to DBTNG. Feel free to pick off an issue from http://drupal.org/project/issues/3060/term/ 131 if you'd like to get a head start on learning this essential part of Drupal. - For designers, lots of exciting news! First, page.tpl.php now has some nice, cleaner markup to make it easier for CSS designers to jump in and start theming without any PHP knowledge. w00t! Next up: node.tpl.php: http://drupal.org/node/382870. Also, our aging, ugly pals Bluemarine, Chameleon, and Pushbutton have been retired from core so they no longer offend designers new to Drupal and make them think that apart from Garland, all Drupal can ever be is ugly and non- standards compliant. ;) Hooray! Thanks to JohnAlbin, who took a hit for the team, they're still in contrib if anyone needs them. :) - Drupal 6 -> Drupal 7 core upgrades should actually work now without any manual monkeying with settings.php! :) Yay! - A new filter was added which will let you post a link to <a href="[internal:node/123]">About Us</a> and automatically figure out the right path. -Angie
- The new database system (DBTNG) now supports pager and tablesort queries via "extenders," which means that we can now work on converting pretty much all of Drupal core queries to DBTNG. Feel free to pick off an issue from http://drupal.org/project/issues/3060/term/131 if you'd like to get a head start on learning this essential part of Drupal.
Can these extenders be used to make pagers that *DON'T* do a pager query, but just go to the next chunk until there isn't any? The reason I ask is that the current pager system barfs with millions of nodes. Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 1" take enormous amounts of time to execute with millions of nodes, but are a part of every q=node front page. There are other examples.
Yes, the extender system allows for mini pagers and such which can have better performance and fewer features. Here is a great article describing some techniques: http://www.mysqlperformanceblog.com/2008/09/24/four-ways-to-optimize-paginat.... As for your specific example of the front page query, an alternate approach for such a site is to swap in a materialized view - http://drupal.org/project/materialized_view (no code in CVS yet) On Fri, Mar 20, 2009 at 6:04 AM, Robert Douglass <rob@robshouse.net> wrote:
- The new database system (DBTNG) now supports pager and tablesort queries via "extenders," which means that we can now work on converting pretty much all of Drupal core queries to DBTNG. Feel free to pick off an issue from http://drupal.org/project/issues/3060/term/131 if you'd like to get a head start on learning this essential part of Drupal.
Can these extenders be used to make pagers that *DON'T* do a pager query, but just go to the next chunk until there isn't any? The reason I ask is that the current pager system barfs with millions of nodes. Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 1" take enormous amounts of time to execute with millions of nodes, but are a part of every q=node front page. There are other examples.
- The new database system (DBTNG) now supports pager and tablesort queries via "extenders," which means that we can now work on converting pretty much all of Drupal core queries to DBTNG. Feel free to pick off an issue from http://drupal.org/project/issues/3060/term/131 if you'd like to get a head start on learning this essential part of Drupal.
Can these extenders be used to make pagers that *DON'T* do a pager query, but just go to the next chunk until there isn't any? The reason I ask is that the current pager system barfs with millions of nodes. Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 1" take enormous amounts of time to execute with millions of nodes, but are a part of every q=node front page. There are other examples.
I've a pet peeve annoyance on pagers too: can they work without database queries yet? ;) About a dozen times over the years, I've had a need to use pagers, but couldn't becauase it wasn't a single query (or, worse, it was the result of a hook call, where there was no database activity going on at all...) -- Morbus Iff ( there is no morbus, there is only zuul! ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
On Fri, Mar 20, 2009 at 13:13, Morbus Iff <morbus@disobey.com> wrote:
I've a pet peeve annoyance on pagers too: can they work without database queries yet? ;) About a dozen times over the years, I've had a need to use pagers, but couldn't becauase it wasn't a single query (or, worse, it was the result of a hook call, where there was no database activity going on at all...)
I have reused Drupal's pager in combination with data retrieved using SOAP. I have described it in this blog post: http://www.norio.be/blog/2008/07/reusing-drupals-pager-non-sql-data -- Litrik De Roy Norio ICT Consulting - http://www.norio.be/
On Fri, Mar 20, 2009 at 13:13, Morbus Iff <morbus@disobey.com> wrote:
I've a pet peeve annoyance on pagers too: can they work without database queries yet? ;) About a dozen times over the years, I've had a need to use pagers, but couldn't becauase it wasn't a single query (or, worse, it was the result of a hook call, where there was no database activity going on at all...)
I have reused Drupal's pager in combination with data retrieved using SOAP. http://www.norio.be/blog/2008/07/reusing-drupals-pager-non-sql-data
Yep, that's how I've done it in the past too. A bit ooky, really. -- Morbus Iff ( notice how he deftly sidesteps the panty issue. ) Technical: http://www.oreillynet.com/pub/au/779 Enjoy: http://www.disobey.com/ and http://www.videounderbelly.com/ aim: akaMorbus / skype: morbusiff / icq: 2927491 / jabber.org: morbus
Robert Douglass wrote:
- The new database system (DBTNG) now supports pager and tablesort queries via "extenders," which means that we can now work on converting pretty much all of Drupal core queries to DBTNG. Feel free to pick off an issue from http://drupal.org/project/issues/3060/term/131 if you'd like to get a head start on learning this essential part of Drupal.
Can these extenders be used to make pagers that *DON'T* do a pager query, but just go to the next chunk until there isn't any? The reason I ask is that the current pager system barfs with millions of nodes. Queries like "SELECT COUNT(*) FROM node WHERE status = 1 AND promoted = 1" take enormous amounts of time to execute with millions of nodes, but are a part of every q=node front page. There are other examples.
That is exactly the goal. Right now the PagerDefault extender is a direct port of the existing procedural code, and therefore is horrifically bad and uses global variables that are undocumented and have completely obscure names that I cannot follow. Someone not named Crell needs to fix that, hopefully. :-) But yes, the idea was exactly to allow alternate paging mechanisms, at least for the query level itself. The pager UI part is, unfortunately, rather tied to that, and still needs refactoring. Again, someone who is not me needs to own that, and maybe even throw a new pager type or two into core. (I'd be totally cool with that!) --Larry Garfield
participants (6)
-
Angela Byron -
larry＠garfieldtech.com -
Litrik De Roy -
Morbus Iff -
Moshe Weitzman -
Robert Douglass