- Development - lists.drupal.org

[drupal-devel] two MINOR problems
by Thomas Ilsche 16 Jul '05

16 Jul '05

Hello, I'm working on the SoC automated testsuite and during the automated testing I have encountered two really minor problems: 1. in user_pass_reset() (user.module:987) the supported timestamp must not be equal to the current time. So if someone clicks the one time login linksame second as it is created it does fail. Well it is quite unlikely that a human does this but it is theoretical possible. It would be nice, but it is not necesary for the test suite to have lessequal rather than less. Any comments? 2. in sess_read() (session.inc:22) the procedure fails with an sql-error for an inconsistent database where the user table misses a corresponding row to the sessions.uid. Well the assertation of a consistent db is not a problem at all but in exceptional cases it might not be a bad idea to have a fallback to the anonymous user. I think with a left join this should work with the same performance as currently. Just wanted to throw that in here, priority is really low. Best Regards Thomas

1 0

[drupal-devel] CVS problem
by Elek Márton 16 Jul '05

16 Jul '05

Hello, I am a Google Summer of Code participant. I requested a CVS account, and I received a mail about it has been approved. But I can't log in with my user name and password. ---------------------------------------------------------------- In C:\[...]: "f:\[...]\TortoiseCVS\cvs.exe" "-q" "checkout" "-P" "contributions" CVSROOT=:pserver:ee@cvs.drupal.org:/cvs/drupal cvs.exe checkout: Empty password used - try 'cvs login' with a real password cvs.exe [checkout aborted]: no such user ee in CVSROOT/passwd Error, CVS operation failed ---------------------------------------------------------------- Perhaps i made a mistake, i don't know. I read README.txt and FAQ.txt as the initial mail suggest, but didn't find any solution. I wrote two mail to dries_at_buytraert and drupal_at_buytaert (08.07,15.07) but i haven't received any answer yet. Please help me. I would commit my initial code before I go to a holiday. thx Elek, Márton

4 6

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by arnabdotorg 16 Jul '05

16 Jul '05

Issue status update for http://drupal.org/node/16216 Post a follow up: http://drupal.org/project/comments/add/16216 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: nedjo Reported by: paragkenia Updated by: arnabdotorg Status: patch I'd really like this to hit core too... (waits) arnabdotorg Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 10:27 : paragkenia I read the comparision discussion between *Drupal* and *Mambo*. In several messages it was outlined that Drupal can place blocks only in right and left and not flexible to put them on anywhere where one want. It will be great if this can be changed in upcoming versions. I am no pro at PHP, so don't know how much time this task will take, but I think it is very important. parag ------------------------------------------------------------------------ April 15, 2005 - 01:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 17, 2005 - 00:24 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions.patch (8.17 KB) This much-requested functionality - to have the ability to place blocks in more than the two predefined regions - was partially addressed in issue http://drupal.org/node/19694. [2]. But "blocks" are still limited to the "left" and "right" sidebars (hard-coded in block.module). This patch is a first step designed to enable multiple (eventually, admin-definable) regions for blocks. I've moved the existing "left" and "right" block regions to a 'region' table (with ids of 0 and 1, as currently used in themes). Then all references to the regions are drawn dynamically from the table. This way, if further records are added, they will appear in the list of available regions for block placement. Doing this actually reduces some duplicated code, since it's no longer necessary to repeat code blocks for each of "left" and "right". As it stands, the patch doesn't add any new functionality--but I don't think it breaks anything either. New functionality would need (a) new regions defined, and (b) changes to themes. A simple first step might be, e.g., to add a "footer" region and then add a call in the footer generation to append any blocks assigned to the footer region there. I'm setting this to patch, but I'm aware that it needs some discussion and refining before it'll be ready to apply. [2] http://drupal.org/node/19694. ------------------------------------------------------------------------ April 17, 2005 - 01:05 : nedjo Attachment: http://drupal.org/files/issues/block_regions.png (5.65 KB) Here's a screenshot showing the block admin page, with drop-downs for region placement (the options are dynamically generated based on defined regions). ------------------------------------------------------------------------ April 17, 2005 - 02:57 : adrian The biggest problem with this is that you can have multiple themes, and each of these themes can have different regions available. Also, the method of defining which regions are available needs to be standardised. Some of the work that me and Vlado are working on for the install system would go towards solving that problem (ie: meta information for modules, themes and styles). This has been discussed to death, but the general consensus has been that we _want_ to do this, but we need to solve a few other problems properly first, the most pertinent being the interface issue. Chris (factoryjoe) recently did a whole mess of workflows for something related to this. ------------------------------------------------------------------------ April 17, 2005 - 04:09 : syscrusher The first paragraph of adrian [3]'s post is a point that occurred to me also, as I read this thread. One suggestion would be to separate the definition and configuration of blocks, on one hand, from the placement of those blocks, on the other hand. In other words, Drupal core provides a mechanism defining what blocks exist, which of these are on by default or off by default and user-selectable vs. which are forced on for all users, and the configuration (if applicable) of specialized blocks defined by particular modules. Each theme provides a standard hook function that returns an array of region names and help/description text, e.g., array('left'=>t('This vertical region is left of the main content area'), 'right'=>t('This vertical region is right of the main content area'), 'footer'=>t('The footer is below the left, right, and main content areas of the page')). The theme part of Drupal core (i.e., theme.module itself, not the individual themes) provides a standard UI that is displayed within config of *each theme* (but is one physical code base within theme.module) that allows the administrator to map blocks defined by Drupal core into regions defined by the theme, and storing that mapping as an theme-to-block_ID-to-region_ID (with weight) table in the database. From there, the actual page rendering is similar to what's being done now, but there is more of it. I guess what I'm trying to say is that the key to solving this problem is breaking it along its degrees of orthogonality, and there are three -- two in Drupal core and one in the individual theme. Scott [3] http://drupal.org//user/1517 ------------------------------------------------------------------------ April 17, 2005 - 07:14 : Dries Scott, is right. The theme should export its available regions. Then the administrator's task is to assign blocks to regions (not to setup regions). A theme could have configurable regions, but that internal to the theme. To me, the real challenge is the UI and the interaction design. Configuring blocks could easily become a real pain (while most themes continue to use 'left' and 'right'.) Of course, we can implement all the functionality, default everything to 'left' and 'right', and worry about the UI later. This should be fairly straightforward to implement and nedjo's patch looks like a first step in the right direction. ------------------------------------------------------------------------ April 17, 2005 - 21:09 : nedjo I agree with the suggested approach of themes registering their regions. I'd see this happening when a particular theme is activiated (or upgraded). Regions would be an array of names (e.g., 'left', 'right', 'footer'). New records would be created in the region table only for region names not previously registered. Some areas I'm not clear on, or that need further work: * Table naming Should a new table be 'region' or 'regions' (I've used 'region')? I don't see a convention among existing table names, some of which are singular and others plural. * Default values I've kept the existing '0' and '1' ids for regions (left and right, respectively), for backward compatibility. But this means we can't use autoincrement for the region id (rid), since autoincrements seem to begin with 1. Likely we should change to autogenerated ids. * Initial records Using the INSERT INTO statements as I've done for the initial region entries is probably counterproductive, since sooner or later they'll have to be dynamically generated. I was hoping this could be a preliminary patch, with the main work coming later, but likely we need to solve region registration by themes before this patch is applied. I don't have a good idea of how region registration by themes would be implemented (a hook on theme activation?), and invite suggestions or implementations. * Theme system changes Besides region registration, the other change I'm seeing that would be needed in the theme system is loading blocks by region name, rather than region id. This is because the ids currently used ('0' and '1') in theory might be diffferent on a particular install. ------------------------------------------------------------------------ April 17, 2005 - 21:18 : syscrusher Instead of having themes "register" their regions, why not just add a theme API hook called them_regions() that returns an associative array of $region_name=>t($region_helptext)? This would be in keeping with other similar API functions, such as those that return what permissions apply to a module or what node types are defined by a module. Most themes are going to define only a small number of regions (two being the typical case now, but I could see five or six in a complex theme), so returning a constant array will be faster than querying SQL to obtain an array of rows. There could be (optionally, at the discretion of whoever builds this thing) another API hook like theme_region_properties($region_name) that returns an associative array with detailed info for a given region, such as extended help text with recommended usage instructions for the region. Scott ------------------------------------------------------------------------ April 17, 2005 - 21:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 22:47 : adrian Because. The most common 'theme' is a phptemplate theme. And there needs to be a generic method for specifying the regions available, in a non hook_function format.. Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. You would need a standard way to define meta-information for themes, that does not need to be modified when copied to a new directory. We are working on this in the install system work, as you need a way external of Drupal to define the module dependencies and some other things. My approach would be to add a theme.dsc text file to the directory, which would allow you to specify meta-information. For instance : ---- regions: left, right, footer, center, mountie author: Johnny McAngstyPants ---- ------------------------------------------------------------------------ April 18, 2005 - 02:00 : syscrusher Adrian wrote: " Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. " A very good point. But region names don't have to be unique across different themes, so my hook function wouldn't have to be modified. The suggestion I made for the mapping metadata was three factors: theme ID or name, region ID or name, and block ID (plus one non-key weight value to order the blocks within a region, but this is not relevant here). I'm not familiar enough with PHP template to be able to respond to your comments on that one, so if you say it's not feasible to work with my schema, then I'll take your word for it. :-) Scott ------------------------------------------------------------------------ April 18, 2005 - 02:03 : syscrusher Oh, wait.....I see now what you mean! It's not the output of the function that is the problem, but the *name* of the function. Never mind. I concede your point. Scott ------------------------------------------------------------------------ April 18, 2005 - 07:44 : Jaza I'm probably jumping ahead a bit here... but something that this patch will have to eventually account for, is how to allow regions to be defined as inline. Allowing a theme to define a region's position as being anywhere on the edge of the page (i.e. top, left, right, bottom, corners, etc) is relatively easy. But what about having a region that's in the middle of a node's body, or somewhere else that's not the edge of the page? What I'm thinking of, is eventually allowing the custom region system to integrate with the CCK. Like I said, I admit that I'm jumping ahead into the future - the CCK still has a long way to go before it's ready. But ultimately, it would be cool if a theme could define a region as being after, say, the "rating" field in nodes of type "movie review". This would make the region (and the blocks in it) truly inline and in context with the actual content of the node. This would be a huge step forward compared to the current block system, which doesn't allow you to mix the presentation of blocks and nodes at all. In Drupal ATM, blocks and "the rest of the page" are totally separate, and really you have no choice but to display them as such. The result of this is that information in blocks that really should be displayed as part of a node, gets literally "pushed to the side", and always seems secondary to the actual content. Often the block has content that is just as important as the content of the node itself. Another option (of less merit, IMO - because of the extra maintenance work, and lack of enforced consistency) would be to have a region filter. You could then choose where to place an inline region on a per-node basis, by entering text such as [region:2] (example based on image_filter syntax) into the node body. Anyway, just thought I'd throw that idea into the open. I don't expect it will be implemented any time soon, but it's something to think about. Jeremy ------------------------------------------------------------------------ April 18, 2005 - 08:54 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-1.png (1.29 KB) Imo the 'regions' are more than you guys name here.. FOr example I attached 2 screens which only shows you the regions.. What I think is that it should always be possible to have free names for the regions. No matter if i call - the region where my content appears in - 'content' or 'site items'.. See attached screens.. ------------------------------------------------------------------------ April 18, 2005 - 08:56 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-2.png (1.39 KB) And the second... See these links: - http://drupal.org/files/issues/regions---possibility-1.png - http://drupal.org/files/issues/regions---possibility-2.png ------------------------------------------------------------------------ April 18, 2005 - 15:22 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions2.patch (13.39 KB) Here's a revised patch implementing some of the ideas so far. I've used the theme engine - rather than individual themes - to generate the list of available regions. I know this isn't ideal, but e.g. for xtemplate it's at present the only option--no logic is possible in the individual theme. region is changed to a varchar field from the current tinyint. I've roughed in several regions--really just for demo purposes. More thought and work would be needed to refine them (e.g., styling, etc.). But this maybe moves the conversation forward. ------------------------------------------------------------------------ April 18, 2005 - 21:26 : Dries This patch enables different regions to be used. That is a good thing. The next question is: should we take into account that different themes could assign blocks to different regions? Lots of problems would be solved if (i) there could only be one active theme on a website or (ii) if all themes would have a common set of regions. (This "let users select their own theme"-thing is a left-over from the early days, except for WAP stuff maybe.) ------------------------------------------------------------------------ April 18, 2005 - 21:37 : killes(a)www.drop.org Giving up multiple theme support would be a great thing. People could still select from multiple style sheets. WAP shoud not be a user preference setting, but automatically detected and redirected to a special site with a WAP theme. ------------------------------------------------------------------------ April 18, 2005 - 21:48 : adrian You would then lose the ability to make a special front page theme for use with the sections module, for instance. Also, currently styles exist in the same namespace as themes, and we would have to make more a distinction of styles vs templates (or themes), but I do think this could help simplify things. ------------------------------------------------------------------------ April 21, 2005 - 16:54 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions3.patch (15.69 KB) The main issue raised, if I'm understanding well: if a theme or theme engine is present that offers regions other than those available in the default theme, any blocks assigned to those regions will be invisible to most users. Here's a revised patch addressing the concern. I've added a test for each region to see whether it's also available in the current default theme. (Actually, I'm realizing as I write this, I've used the theme engine--so it would need to be updated to test first if an engine is being used.) In any case, any regions not available by default are starred, and a message text appears (only if necessary). If there's support for the approach, I'd be happy to finish the patch. Remaining work: * extend to work with non-engine themes * finalize base set of regions to implement * implement common region set in all core themes (for now I've only done xtemplate) * work on CSS display (how blocks in each region should look) This last point I'm not too confident on and would look for help/suggestions. Screenshot to come. ------------------------------------------------------------------------ April 21, 2005 - 16:56 : nedjo Attachment: http://drupal.org/files/issues/block_regions_message.png (12.34 KB) Screenshot showing starring of non-default regions plus message. ------------------------------------------------------------------------ April 21, 2005 - 17:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 17:23 : resmini My two cents. If this has to be done (and it should), better get rid of spatial definitions for areas such as left, right, top, bottom, etc. Use semantic names related to content and let the theme take care of their positioning interely. Also note that there in an ongoing debate in IA trying to build up a standard naming convention for page regions in a way that is semantically (and logically) correct. Just for the sake of it, you can check http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html with follow-ups, including Eric Meyer's. There are more substantial contributes in the AIfIA web site, but I can't seem to find them now. I'll post a link or an abstract if I manage to. -- vector at exea dot it ------------------------------------------------------------------------ April 21, 2005 - 18:15 : nedjo Good points, useful references. The default regions I'm thinking of are: 'banner' => t('banner'), 'left' => t('left sidebar'), 'right' => t('right sidebar'), 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), 'footer' => t('footer') Perhaps "body" would be better as "content"? It would be easy enough to add in more regions, e.g., within the content (after title, after help, etc.) One issue is that many of these regions will already have rendered content. Should the blocks come before or after that other content? I've assumed after for banner and footer, while giving both options in body. In any case, refinements or suggestions would be great. ------------------------------------------------------------------------ April 21, 2005 - 18:56 : resmini Well, 'banner' => t('banner'), 'left' => t('left sidebar'), 'right' => t('right sidebar'), 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), 'footer' => t('footer') The classic (as far as classic goes for something Web related) scheme comprises 5 spatial regions, much like stefan's http://drupal.org/files/issues/regions---possibility-1.png with a left area mirroring the one called 'blocks'. Call them top, left, center, right, bottom. Variants usually exclude one or more of these, layout-wise. If we talk content (semantic) instead, things get a bit more complicated, as these spatial regions normally include more than one content-area. The top, for example, could include ad banners and the site's header, or the main menu. But these merge seamlessly with CSS definitions, which are definitely something that should get properly standardized (most of the errors / inconsistencies I'm encountering with Drupal today are related to this), but this is out of scope in this thread. What I somewhat object to the definitions above is that it mixes the two approaches. 'banner' is not spatial, is content, as it is the distinction between body top and bottom. If 'banner' goes there, it is 'top', whatever that might be. I designed a couple of web sites which had headers/logos/banners at the bottom of the page, and I'm not exactly the wildest designer you'll probably meet. And if we include body_top and _bottom, we should also add 'navigation', or 'menu' and some other content-related semantic region (impressum, or company_data, or whatever). I suggest that either we go along 'top' => t('banner'), 'left' => t('left sidebar'), 'center' => t('body'), 'right' => t('right sidebar'), 'bottom' => t('footer') or we dedicate some time to detailing what could possibly fit there semantically, which is perfectly possible without limiting design freedom or whatever, since the vocabulary is not infinite, but not something you do out of the blue. Please note that I understand t('something') to be an example, since such a layout only defines regions on the page, not semantic regions. My main content could fit nicely in the bottom region. As for the names for the regions, they are not important, as much as they are coherent and enforced. ------------------------------------------------------------------------ April 21, 2005 - 21:16 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions-final.png (2.39 KB) Maybe something like this??? But, I have to say that I _really_ liked the solution to split the 'content'-region into the 'content' and 'beneath content'.. I love that! ------------------------------------------------------------------------ April 21, 2005 - 22:20 : resmini Stefan, yes. That's basically what you can build if you stick with spatial, and this layout can generate quite an amount of (sane) layout variations even if you interpret it strictly (suppose a default) as <div id="header"> </div> <div id="left-bar"> </div> <div id="content"> </div> <div id="right-bar"> </div> <div id="footer"> </div> What you can do with this is left basically to the theme designers and their use of CSS, CSS-P or tables (brrr), but this could be an easy and proper way to identify macro-regions in which more accurate positioning happens at a more specific level. I'm all in favour of subsequent identification of sub-areas (top and bottom in body), but I don't think it would be a good idea to mix the different approaches I mentioned in my previous post. A site with lots of things going on or which is not just blogging surely has the need to use its content area in a wiser manner than just putting there 'content', the number of modules doing precisely this is more than proof, but that falls more in a 'Drupal definitive guide to semantics', in which CSS selectors are used or suggested strategically for such a scope. >From this point of view and for the sake of this thread, any unique area / div (#name) could (should?) be a target for blocks, and this in my opinion (*) would be the perfect solution, but I do not know if and how this is even remotely possible in the current Drupal. (*) It's quite late, local time, and it was a looong working day. ------------------------------------------------------------------------ April 21, 2005 - 22:38 : resmini Attachment: http://drupal.org/files/issues/regions-final-variation.png (1.9 KB) Just to be clear, I add a variation of stefan's scheme that shows how this is *not* by any means positional, but spatial, or better relational. Use your CSS imagination to take out regions, reduce them to empty containers, enlarge them, make them taller, shorter, whatever. 5 regions, do what you like. ------------------------------------------------------------------------ April 21, 2005 - 22:44 : resmini Sorry, I forgot. And this is also why I'm not too keen on calling anything 'content'. If I enlarge my right region enough, why not put my content there? Shouldn't this be a theme-level concern? It's nothing serious, but if my center area is called 'center' (or something similar and more sexy), I won't confuse anybody. This is left, center, right: do with them what you prefer. Content in the bottom? Show me. If I call something 'content', I'm more than suggesting that content goes there, and only there. ------------------------------------------------------------------------ April 22, 2005 - 08:17 : stefan nagtegaal Resmini, maybe it is only me but I think that you are making a mistake in your way of thinking.. I get the feeling that you're mixing the 'regions' and 'divs'.. the 'regioins' should have meaningfull sentences, but the divs shouldn'thave.. As an example: $region_name => $content_body here we go: 'header' => $logo 'left sidebar' => theme('blocks', 'left') 'right sidebar' => theme('blocks', 'right') 'content' => $content 'footer' => $footer. So, $region_name does not have to be equal to the id or class of the divs.. ------------------------------------------------------------------------ April 22, 2005 - 09:27 : resmini Stefan, >So, $region_name does not have to be equal to the id or class of the divs.. Yes, absolutely. I probably didn't make myself very clear: what I'm trying to point out is that in 'header' => $logo 'left sidebar' => theme('blocks', 'left') 'right sidebar' => theme('blocks', 'right') 'content' => $content 'footer' => $footer. there is no reason at all to call 'content' the region that holds $content. nedjo asked in #24 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), if /Perhaps "body" would be better as "content"?/ and all my reasoning is simply that no, that is not content, or it shouldn't be (or better: it may happen that main content is elsewhere). As a matter of fact, even the connotation 'sidebar' doesn't fit very well logically. To make it short: Today's method works, but has limits. Mambo, which paragkenia quotes at the beginning, handles more 'user regions' but in pure Mambo style conventions are so loose that they are hardly useful. If we define regions, as in nedjo's example, in my opinion these regions shouldn't imply informational layouting, only relational positioning (that is, where they stay in the browser viewport). I know it may look like overdesigning, but Drupal constantly enforces conventions and coding guidelines everywhere: this is one of the best aspects of the project and I think it should carry to the layout. ------------------------------------------------------------------------ April 22, 2005 - 09:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 17:48 : chx Let's get back to the code. If my understanding is correct the big discussion is about how to name potiental rectangular areas _after_ this is commited. So, first get this committed. What's need to make that happen? ------------------------------------------------------------------------ April 25, 2005 - 18:56 : chx I spoke with Moshe, Steven, JonBob and the result is: keys shall be numbers, and themes shall define the values. We will make region zero and one required. There will be a define('REGION_CONTENT', 0) and a define('REGION_SIDEBAR', 1); so you can have readable code still. Either wait for me to code it or feel to do it yourself, just drop me a mail via the contact form if you are doing it. ------------------------------------------------------------------------ April 27, 2005 - 16:14 : nedjo Károly, it's great if you're willing to take on finishing this. I tried to summarize remaining work in update 20, above [4]. The numerical keys look fine to me. In terms of an initial default set of regions, one quirk is this: for now, so far as I can see (and assuming the approach I sketched in), available regions can be defined only in (a) theme engines and (b) individual themes that don't use an engine. So, for instance, an individual xtemplate based theme can't define its own custom regions; they need to be defined in the theme engine. (Unless and until the whole theme system should switch to the sort of configuration file adrian suggested above [5].) Which is to say that, under this approach, we'll be defining a set of regions for each engine, and then all themes using that engine should try to implement those regions. (Otherwise, if a site admin selects a region defined in the engine but not implemented in the default theme, the content won't appear.) Please let me know if there's anything in what I've done that isn't clear, or if you want to pass some or all of this back. Thanks! [4] http://www.drupal.org/node/16216#comment-27398 [5] http://www.drupal.org/node/16216#comment-27052 ------------------------------------------------------------------------ May 9, 2005 - 20:36 : chx I had a "short" discussion with the UI team leader ie. Ber Kessels. The outcoming is that we will change hook_block so that it uses callbacks a bit like menu system. Here's an example: <?php function module_block() { $items = array(); $items['module_header'] = array('callback' => 'mymodule_page', 'weight' => -50, 'region' => 'content' , 'cache' => TRUE, 'pages' => "node/*\n<front>"); return $items; } ?> Please note that we are allowing caching the themed output of each block independently. The theme system will execute hook_block as it does now and it'll execute the callbacks defined in module_block as well. Of course if the callback is cacheable and in the cache, it'll print it from cache. If it's themeable and not in the cache, it'll cache it before printing. Pages contains a string (could be PHP code!) which can be overriden in the block configuration screen. Callbacks defined in hook_menu will have lot less functionality after this, they will be used for non-themed pages mainly. ------------------------------------------------------------------------ May 9, 2005 - 20:45 : chx More explanation is requested for the example. module_header is the unqiue name of the block. pages define on which pages the block is visible. ('pages' in the block configuration screen.) Maybe I'll implement 'visibility' from the same screen as well. callback, weight are well known Drupal terms. cache is a boolean which defines whether given output is cacheable or not. ------------------------------------------------------------------------ May 9, 2005 - 20:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 20:52 : Bèr Kessels Attachment: http://drupal.org/files/issues/more_regions_principle.png (123.29 KB) attached is a schematic which might clarify this a little. And I would also like to comment on me being the UI leader: I do not consider myself any leader, no ofeence, though. Just to clarify that. ------------------------------------------------------------------------ May 9, 2005 - 22:42 : nedjo I am not opposed to the idea of changing the _block() hook to use callbacks (I have no opinion on it, not immediately grasping the need), but this seems quite distinct from the aim of enabling multiple and extensible regions. Why can't we just move ahead with the block generalization? I suggest: * quickly implement the proposed block region generalization, using only the two existing regions (i.e., implementing them in core themes) * later worry about: - adding further regions (the details of which are best done by those primarily responsible for the particular themes) - possible changes to the _block() hook. Wouldn't this make sense? Or am I missing some pressing reason for which the block generalization has to wait? ------------------------------------------------------------------------ May 10, 2005 - 01:28 : killes(a)www.drop.org "Or am I missing some pressing reason for which the block generalization has to wait?" I might be missing something too, but I thought Chx was just talking about the block generalization and proposing a way to code it. ------------------------------------------------------------------------ May 10, 2005 - 02:41 : factoryjoe I wanted to chime in with this discussion because it's an important one and has some really huge implications for Drupal moving forward. That said, I also have a day job pulling all my attention which means that the big ideas I have for this problem can't be put into a complete visual form for at least a week or more. In the meantime, I'd like to offer a few thoughts on the matter. * *Regions do not belong in themes.* Blocks were originally separate from themes for a reason. Themes should define the general look and feel of a site -- and to some extent a site's behavior. Layouts which define the spatial relationship between regions belong in some intermediary between style and content, which does not currently exist in Drupal. * I would propose that *layouts become a new kind of CCK tool.* By that I mean that they can be defined, shared and deployed very easily -- even as simply as tossing a directory of some .layout textfiles into a layouts/ directory. Note that this suggestion has nothing to do with the way CCK /might actually/ work right now; instead I'm suggesting how I would like it to work. I would like, for example, to create a CCK item like a "person" and ship it with a .layout file that carries all the semantic goodness needed to output that "person" to the screen in juicy, semantic markup... which anyone can come along and theme to their heart's content. * *Creating shareable layouts should be relatively painless.* Dashboard [6] sets the bar for easy hackability. It should be that easy to create layouts for Drupal... I can imagine creating an "iTunes layout" or an "Image Gallery" layout and so on... If we used something akin to PHPTal to develop the layouts, we could keep development fairly standard while making it possible for more folks to hack up cool and innovative layouts. * *Layouts should be extensible.. to a degree.* I see a huge problem with how this discussion has floated back and forth between semantic and spatial region naming. Because we talk about this problem in those terms, we fail to identify the real problem and opportunities presented to us. Here's the thing: when you predefine regions, you limit creativity and the ability of people to really use the system. On the other hand, when you make a system too flexibile, it quickly becomes unwieldy. In all the mockups presented above, both classes of problems would arise. Therefore we need to think about a way to stay flexibile while "taming the beast." * To that end, I suggest developing *self-contained layouts that are contextually-complete.* So for the example of the iTunes search layout... you would know before hand that you get a couple multiple select boxes that you can hook up to whatever taxonomies you want to progressively filter [nodes]. You could even change the .layout file, allowing you to theme it to your liking -- even though that would totally optional, given the layout's internal default styling. Once you've got your layout, you would go into a layout module UI [7], create a new layout [8], select the layout from a list [9] and then give it a path so you can access the layout... You would then walk through a wizard [10] that would help you populate that layout with all kinds of nice Drupally goodies... feeds, node listings, PHP code, etc. The power in this approach is multifold. For one, it snaps Drupal out of its block mentality and allows designers to really innovate with individual page designs. In fact, I've already thought out how I could reimplement Flickr using this system, combined with Drupal's native feeds, taxonomy and menu module, and I'd barely break a sweat... sort of. ;) But anyway, this is a very productive conversation to be having, but I really think that we should consider whether the old paradigm, as such, really pushes Drupal as far forward as we have the opportunity to go. [6] http://drupal.org/apple.com/macosx/theater/dashboard.html [7] http://photos4.flickr.com/6944826_90af237c99_o.png [8] http://www.factorycity.net/demos/civicspace/layout/new.html [9] http://www.factorycity.net/demos/civicspace/layout/new_layout.html [10] http://www.factorycity.net/demos/civicspace/layout/testing_add.html ------------------------------------------------------------------------ May 10, 2005 - 04:34 : chx While factoryjoe may be right, I could be right as well. Regions has definitely something to do with themes, after all it's the theme that renders the page, and it can only render regions that it knows of. So, instead of postponing this into the far future when someone comes out with a layout system, I code this now. ------------------------------------------------------------------------ May 10, 2005 - 05:22 : Dries The proposed 'weight', 'region' and 'pages' would be configurable, not? Are these just defaults? The 'callback' and 'cache' options are nice to have. ------------------------------------------------------------------------ May 10, 2005 - 05:25 : chx Yes, blocks can provide a default for everything on the block and and configuration screen. Of course, you can override these in the UI. ------------------------------------------------------------------------ May 10, 2005 - 09:02 : Bèr Kessels Dries: yes, the region, weight and pages will be configurable from an admin interface. What we tried to address here, is a method for developers to choose good defaults. Take for example "logo". that should be enabled by default in a regions called header, rendered on all pages, and have a very light weight. We should not force an admin to visit the blocks admin before she can see or use the logo. Chris: I do not know if you have ever tried typo3. Its concept is some form of builder system. I do not like thar, because far too complex. If we ever get sme kind of builder in core (if ever) it will require a lot of work, and even more usability research. So for now such a builder is far out of our reach. Lets aim at goals that are more realistic ;) So: it does belong in themes, its the best place that is still realistic. I do like your visions, Chris, but I hope you agree they are not realistic, yet. So, maybe you can think of a path towards your visions, ow we can reach such a builder-system, you describe? ------------------------------------------------------------------------ May 10, 2005 - 14:52 : factoryjoe My browser crashed before I was able to submit my followup to chx's comment... I have no problem with the current work going forward and am happy to see it happening. I know that my ideas are typically outlandlish and far off... That's the kind of design I enjoy doing! In any case, I see chx's solution being a means to an end; once we have abstracted the region code, it become much easier for me to get some help creating my vision. In the meantime, and as a demonstration of how I see this layout system working (to answer, I hope, Ber's concerns about clunkiness), I've created a workflow movie that shows off how fast you'd be able to add content to the system. Check it out: http://factorycity.net/demos/civicspace/layout/media/layout_workflow_v1.mov Feedback appreciated. And, if you want to try the demo out yourself (it's all hardcoded, like a "movie set" for my UI), go here: http://factorycity.net/demos/civicspace/layout/ ------------------------------------------------------------------------ May 12, 2005 - 16:45 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions4.patch (13.56 KB) "I might be missing something too, but I thought Chx was just talking about the block generalization and proposing a way to code it. " Well, if I can say so respectfully, I don't think so. Not so far as I can see identifying problems with my original patch, this interesting discussion is rather addressing the (useful, but logically subsequent) question "once we have multiple regions, how should we work with them?". It's perhaps demonstrating our propensity to try to do more rather than less with a given patch--to talk for a long time when a first step solution is already in place. So here is a (yes, interim!) small, focused, and tested patch to remove the hard-coded regions. I've stripped it down so it does nothing more than (a) make block regions declared by themes rather than hard-coded and (b) implement the existing left and right regions in existing core themes. Please, try it out, I think you'll like it. I'm of the (I'm hoping not scandalous) opinion that it can be applied right away, and so clear the way for further progress. In particular, this patch leaves the adding and configuring of additional regions to theme authors/maintainers, who are best qualified for the work. "I spoke with Moshe, Steven, JonBob and the result is: keys shall be numbers, and themes shall define the values. We will make region zero and one required. " The reason I moved from numbers to strings (e.g., "left") is that a theme author defining regions has no way of knowing what regions might have already been defined, and therefore what integers might have aleady been used. It's like module and theme names--we'd have to use random numbers to avoid conflicts, so we're better off with string names. ------------------------------------------------------------------------ May 12, 2005 - 18:17 : Bèr Kessels nedjo, I am not a fan of your solution for blocks that dissapear. It breaks the ability to allow more themes on a site. if important blocks dont show up, your site will simply break. I would rather suggest that every theme MUST have a region called 'default'. any blocks that want to go into a non-existing region, will be placed there. We must define a standard listy of suggested region names. to avoid a wildgrowth of names. I am not sure if i like the way you do function phptemplate_regions(). these regions should be defined in the templqtes, not the engine. Otherwise all phptemplate themes will still all have two regions. Note that i did not test your patch thouroughly, just applied and looked at. ------------------------------------------------------------------------ May 12, 2005 - 19:38 : nedjo Thanks for your comments. I think we're getting somewhere. "I am not a fan of your solution for blocks that dissapear. It breaks the ability to allow more themes on a site. if important blocks dont show up, your site will simply break. I would rather suggest that every theme MUST have a region called 'default'. any blocks that want to go into a non-existing region, will be placed there. " Good suggestion. Having a default region for blocks to show up sounds like a valuable backup. I'm thinking we might want to have a way to designate a given region as the default, rather than having to have one named 'default'. Thoughts? "We must define a standard listy of suggested region names. to avoid a wildgrowth of names. " Sure. But the patch doesn't prevent doing that--it enables it. "I am not sure if i like the way you do function phptemplate_regions(). these regions should be defined in the templqtes, not the engine. Otherwise all phptemplate themes will still all have two regions. " Oh, I wholeheartedly agree, and I've noted the issue above. But unless we substantially rewrite the engines, some region definition is needed in the engines, as they call blocks. Should we therefore define a base set in the engine, then call a hook from the engine to add any other regions from themes based on that engine? If so, where in the theme's files should such a hook be located? And a side note. Do let's make an effort to keep our comments friendly. Taking the time to note one or two things that do work or are done well as part of a review is I believe a valuable habit. It helps to confirm what is indeed accomplished. Beyond this, it helps to maintain the idea that we are collaborating on shared goals, rather than pushing individual and competing visions, and that contributions and work are appreciated, rather than being invitations to criticism. Thanks, Nedjo ------------------------------------------------------------------------ May 12, 2005 - 19:42 : chx I am implementing http://drupal.org/node/16216#comment-29282 but it takes time. regions again have names. default and sidebar regions are mandatory. This has little to do with nedjo's code much more with his idea -- I looked at the screenshot and said, OK this is great but... we'd like to have a lot more 'blocks' if this comes through, henceforth the above mentioned solution. ------------------------------------------------------------------------ May 12, 2005 - 20:39 : nedjo Okay, thanks for the clarification, I hadn't understood that you were taking a new approach rather than building on what I'd begun. Given that that's the case, staging as I'd suggested obviously won't work so I'm content to wait and see what you accomplish. I'd only suggest, don't feel like you need necessarily to do everything all at once. ------------------------------------------------------------------------ May 13, 2005 - 08:34 : Bèr Kessels Nedjo, sorry if the sound of my comment was hostile. it was never meant to be that way. I am busy, and thus did not want to comment all the things i liked about your patch, but chose to pick the much smaller amount of things I thought could use some improvement. I will try to keep in mind to be more friendly next times. Also, not all of us are as fluent in English as our native English speakers. I think its good to keep in mind that for a lot of us, communication in English is not as easy as it may seem. For me, it often requires a lot of concentration to get the subtleties right. I mean: I can type some English text, look up words in the dictionary, but to get small yet important subtleties in my texts is very hard, often. But, that all said: I liked your patch. ------------------------------------------------------------------------ June 10, 2005 - 11:08 : jakeg How far off is this from being officially released or at least usable? If its usable now, what files will I need to implement it? ------------------------------------------------------------------------ June 10, 2005 - 12:19 : Kobus Attachment: http://drupal.org/files/issues/regions---possibility-3.png (2.21 KB) To add to Stefan's suggestions with the two screenshots, I modified one of them a bit, and this is how I understand Jaza's post, and yes, I agree, this would be a wonderful feature! I can't wait! Imagine how good it would look if I had a theme that has a clear white background (not visible blocks) and then these seemingly random boxes on the page, as shown in the screenshot. Especially where I can place it anywhere around the node like Jaza said with a [region:2] block etc. I say again: I can't wait! Kobus ------------------------------------------------------------------------ June 10, 2005 - 13:59 : chx I need 3-4 hrs of peace to implement the callback based thing. That's a lot these days. Let's hope I'll get on it in the following days. ------------------------------------------------------------------------ June 18, 2005 - 22:32 : chx Here's an example again of how hook_block will look like: <?php function module_block() { $items = array(); $items['module_header'] = array('callback' => 'mymodule_function', 'callback arguments' => arg(1), 'weight' => -50, 'region' => 'content', 'cache' => TRUE, ''pages' => "node/*\n<front>"); return $items; } ?> Items are keyed by unique IDs. The template system will call module_invoke_all('block'), put the rendered HTML of the blocks into regions sorted by weight. The rendered HTML is cached if it is allowed. More keys will be introduced later, but now basically we just throw everything from block configure in here, and add callback, callback arguments, region. Node teasers or fullly rendered nodes are blocks, too. Almost everything is. So, here what happens when we are on taxonomy/term/1: taxonomy_render_nodes is called it calls block_set('node_view', $weight, $node, $teaser, $page); a few times, so a few node_view blocks will be on the page later the theme system is invoked. It will ask the block system to collect all blocks, dynamic and the static blocks as well. For all dynamic blocks we have a block defined in hook_block somewhere, like the definition above, with one exception: it will have a 'standalone' => FALSE pair, so it is not a standalone block which is automatically rendered but something that needs to explicitely requested. Also, we may define a 'suffix' => 'somefunction' pair which provides us with a cache ID suffix. Look at the code below: <?php function block_collect_blocks() { // get all block definitions $static_blocks = module_invoke_all('block'); // iterate of the dynamic blocks set on the page foreach (block_get() as $dynamic_block) { // get the block definition for the given dynamic block $static_block = $static_blocks[$dynamic_block['block']]; // merge the callback arguments from the dynamic and static. dynamic_block['callback arguments'] is always set though // may be empty if (isset($static_block['callback arguments'])) { $dynamic_block['callback arguments'] = array_merge($static_block['arguments'], $dynamic_block['callback arguments']); } // try to get a cache ID suffix $suffix = function_exists($static_block['suffix']) && call_user_func_array($static_block['suffix'], $dynamic_block['callback arguments']); // if the block is cacheable or the suffix function says that it is cacheable by setting a suffix if ($static_block['cache'] || $suffix) { // set cache ID $cid = 'block:'. $dynamic_block['block'] .':'. $suffix; // try to get the rendered HTML from cache if ($block_rendered = cache_get($cid)) { $return[$static_block['region'][$dynamic_block['weight']][] = $static_block_rendered; continue; } } // render the block $block_rendered = call_user_func_array($static_block['callback'], $dynamic_block['callback arguments']); // store the block for return $return[$static_block['region'][$dynamic_block['weight']][] = $static_block_rendered; if ($static_block['cache'] || $suffix) { // if cacheable, do it cache_set($cid, $static_block_rendered); } } foreach ($static_blocks as $key => $static_block) { // is this a stand alone block, like in Drupal 4.6? if ($static_block['standalone']) { // now, the above is repeated, save that we do not have a dynamic_block here $suffix = function_exists($static_block['suffix']) && call_user_func_array($static_block['suffix'], $static_block['callback arguments']); if ($static_block['cache'] || $suffix) { $cid = "block:$key:$suffix"; if ($block_rendered = cache_get($cid)) { $return[$static_block['region'][$static_block['weight']][] = $static_block_rendered; continue; } } $block_rendered = call_user_func_array($static_block['callback'], $static_block['callback arguments']); $return[$static_block['region']][$static_block['weight']][] = $static_block_rendered; if ($static_block['cache'] || $suffix) { cache_set($cid, $static_block_rendered); } } } } function block_set() { static $blocks; $args = func_get_args(); if (count($args)) { $callback = array_shift($args); $weight = array_shift($args); $blocks[] = array('block' => $function, 'weight' => $weight, 'callback arguments' => $args); } return $blocks; } function block_get() { return block_set(); } ?> When to expire the block cache? Never. If functions can call cache_clear all, they can be smart enough to cache_clear only those blocks that are changed by them. Some blocks won't be cacheable anyways, say there is little use in caching 'active forum topics' ------------------------------------------------------------------------ June 19, 2005 - 07:15 : Dries Frankly, I don't understand what you are trying to say. What is a 'dynamic', a 'static' and a 'standalone block'? What is the suffix for? What is the advantage of making node and taxonomy views blocks? If there is no big advantage, this is just bloat. All in all, it looks pretty complex to me. If we make Drupal more flexible _and_ more complex, people will get upset, and we end up being like Plone. Drupal's simplicity is something to foster, as it allows people to go in, and change stuff. The focus is to make Drupal simpler _and_ more flexible. I merely spent 10 minutes looking at this (reading your explanation twice, staring at the code), and the newly added complexity simply turns me off. Maybe that is because I don't understand what we are gaining. ------------------------------------------------------------------------ June 19, 2005 - 07:34 : Bèr Kessels * The first thing we gain, is, very slmple: more regions. But, how many? what regions? on what pages? in what location? bearing which name? For all these issues we need some callback system. To allow themers, administrators and module developers to give answers to all these questions. what we have now: sidebars, with only admin settings, is simply too limited: It takes serious hacking (~15 lines of code in your theme) to get a login block in your header! * The second thing we get for free: We are passing along chuncks of HTML, so why not cache them in a central place. Practice points out that our current cache is not used well. We leave it to developers to cache. And developers are lazy by nature. Just looks at all the places where caching should have been done, but is not. 9/10contribs have at least one of these places. You must actually see these issues separate. The new central blocks pulling system, and the caching. the latter is something that we get for free, a high level of advanced caching (how often has not been put forward Drupal seiously lacks better/advanced caching?). But we get it only for free if it is co-developed with the new regions blocks. And Last but not least, everything is a block, from a themer point of veiw. I know developers tend to think: I do the content, and do not care about where and how it turns up. That results in a content-centric system, what we have now. Everythng is built around aa single chunk of content. while, in fact content, is yet another block. Look at http://www.terminus1525.ca/index.php?l=en or http://www.franklinpennsylvania.us/ as it stands now, its up to the developer to concenate all the HTML in the center area, into a huge chunk of HTML. While in fact everyone can see that these are a lot of separate blocks. ------------------------------------------------------------------------ June 19, 2005 - 07:39 : Dries Ber: I was talking about chx's latest changes, not the block system in general. ------------------------------------------------------------------------ June 20, 2005 - 18:06 : nedjo I appreciate the update on directions being contemplated, although I find it confusing. Again, I'd caution, let's keep focused on the aim at hand, and on a staged solution. A bigger patch means greater complexity, more difficulty getting meaningful review, and greater delays in getting a priority change. We're currently in a position where we have two hard-coded regions for blocks, a major issue if nothing else than because it reflects poorly on Drupal's usability and versatility. Moving from here directly to something like "everything you see anywhere is a (nested) block in its own (nested) region" strikes me as a bigger step than we need to take. And in belated reply to Ber's note (#53 above [11]), thanks for the thoughtful comments, I didn't mean to single you out and acknowledge that language & cultural differences play a role, I feel we can all benefit from attention to communication. [11] http://www.drupal.org/node/16216#comment-29633 ------------------------------------------------------------------------ June 21, 2005 - 19:39 : Dries Even with the explanation in chx's sandbox, this is too complex for my likings. Here is a suggestion: let's drop the caching and the 'suffix'-stuff. Let's also drop the 'complete' and 'incomplete' stuff. Keep it _simple_, chx. IMO, you're creating a monster. ------------------------------------------------------------------------ June 22, 2005 - 20:47 : chx nedjo, take over. I am out. ------------------------------------------------------------------------ June 22, 2005 - 22:51 : djnz Quick and dirty solution? Let blocks be assignable to 9 locations - Top left, middle, right, middle left, middle right, bottom left, middle, right. The actual location of these areas within a theme is up to a theme designer, but the designer should include each of them - how about $sidebar['tl'], $sidebar['tm'], $sidebar['tr'] ... Backwards theme compatibility could easily be maintained by only creating the $sidebar array if the theme has set (eg in its template.php file for a PHPtemplate theme) a flag, otherwise generate $sidebar_left from the blocks set (in sequence) to top left, middle left, bottom left, top middle and middle middle (arbitrary break) with $sidebar_right the remainder. I appreciate I have no karma here and only superficial knowledge of the Drupal code, but sometimes the clarity of a view unclouded by too much information is useful ;) ------------------------------------------------------------------------ June 27, 2005 - 06:26 : nedjo Attachment: http://drupal.org/files/issues/regioning.patch (24.74 KB) " nedjo, take over. I am out. " Um, okay. I've given the question some more thought and come to the following conclusions: 1. If we take regions to be areas of the page that specific types of content are rendered into, and a regioning system to be a system to accomplish this, we already have a number of regions and different types of regioning systems. They include: (a) our current blocks system, and (b) the various drupal_set_[region]() functions, like drupal_set_comment(). (c) specialized hooks like our help system, which assembles content to be rendered into a region. 2. LIkely we should tease out regions from blocks. So attached is a next rough cut at regioning. Features: * Default region is defined in general admin settings page * Regions are defined in both engines and themes. A particular engine-based theme has the regions it defines plus the engine's default ones. * Content can be written to regions in two ways: through blocks or through drupal_set_content($region, $content) calls. Initial comments are welcome. I'll work on getting a more polished patch and also more explanation of the approach. ------------------------------------------------------------------------ June 27, 2005 - 06:43 : deekayen Disclaimer: I offer no code for this, so this is just a bunch of idealism I can't back up. djnz's comment makes sense if you want quick and dirty, but it seems to me the correct way to do things would be in terms of relatives. I would think doing it right the first time would be easier than redoing block location code twice. For example set a standard starting location; perhaps the start is 100% height/width conceptually. If you want to put something on the right, it would be the first block on the right of the starting block - let the theme manage widths. Then if you want another block on the right, or 10, just keep adding them relative to the others kind of like the current ordering of book pages or like adding more TD cells in a HTML table. Using this example under the current standard layout, the main block could be in the middle with with relative blocks on the left and right. ------------------------------------------------------------------------ June 28, 2005 - 10:26 : arnabdotorg It would be totally awesome to see multiple regions in Drupal 5, if not 4.7. This topic has been discussed several times before, noting them down for reference: http://drupal.org/node/2790 /[September 9th 2003]/ http://drupal.org/node/10653 http://drupal.org/node/13008 I also think it would be nice to have people implement multi-region themes; see what problems we encounter, and learn from it. ------------------------------------------------------------------------ June 28, 2005 - 12:28 : arnabdotorg Forgot to add, I've patched nedjo's final patch [12] to Drupal HEAD, it's up at http://arnab.drupaldevs.org/ [13]. [12] http://drupal.org/files/issues/regioning.patch [13] http://drupal.org/files/issues/regioning.patch ------------------------------------------------------------------------ June 28, 2005 - 16:57 : nedjo Attachment: http://drupal.org/files/issues/regioning2.patch (25.03 KB) Here's an improved version of the patch--several bug fixes, no new functionality. There are still a couple of loose ends (e.g., implementing the option of particular blocks not to be themed), and I haven't fully tested it. Further to my previous explanation, here is a summary of what the patch does. I'll mark as "new" the bits added in this week's iteration. Problem addressed: Currently, Drupal has two hard-coded regions into which block content is rendered: left and right. This situation severely limits the flexibility of content presentation. Aim: Enable multiple and extensible regions for blocks and other content. Approach: 1. Hard coded regions are removed from block.module. Instead, available regions are loaded dynamically. 2. Available regions are defined in themes (and, optionally, in modules). A theme or a theme engine defines its available regions through a themename_regions() function in themename.theme file or a enginename_regions() function in an enginename.engine file. New: engine-based themes can define their own regions in a .theme file. They will have all the engine's regions plus any they define. New: modules can define their own regions through a hook_regions() call. This should allow modules to define and use "inline" regions. For example, a module could define a region, then use a nodeapi() call to load content for that block and then insert it into a formatted box in $node->body. 3. New: the regions associated with a theme are loaded as part of the system_theme_data() call, and available regions are loaded through a system_region_list() function. 4. Previously stored as an integer, blocks' regions are changed to varchar, to enable storing of strings (e.g., 'left'). 5. A "default" region is defined (as a core setting), into which content will be rendered in the case that it's assigned to a region that's not available in the current theme. The options available for the default region are "core" regions, defined as all those available in all available themes. In the main block admin page, all regions not available in the current default theme are marked with an asterix, with an explanatory note. ------------------------------------------------------------------------ June 28, 2005 - 17:04 : nedjo Attachment: http://drupal.org/files/issues/showregions.module.txt (1.13 KB) Here's a sample module using the patch's regioning. When installed, it visually marks all available regions when you visit the page ?q=showregions. This is implemented using the proposed system_region_list() and drupal_set_content() functions. (I've attached a .txt extension to the module file since otherwise module files seem to get rewritten when uploaded.) ------------------------------------------------------------------------ July 2, 2005 - 21:15 : nedjo Attachment: http://drupal.org/files/issues/regioning3.patch (28.83 KB) Okay, this is now ready for review. To install after applying the patch, run update.php, since some database fields need to be created and updated (see function update_141() in the patched update.inc). In this final version, I've: * simplified the handling of content assigned to regions not available in the current theme, by loading such content directly in theme_blocks(), so that no custom handling is required in themes. * finished the coding for designating particular blocks (including custom ones) as not themed, so that it's possible simpy to inject content. This introduces a new 'themed' parameter of blocks. * made several variables configurable in the declaration of blocks by modules. As well as $block['content'] and $block['title'], you can now set $block['status'], $block['weight'], $block['region'], $block['themed'], $block['pages'], and $block['custom']. To see the behaviour, set any phptemplate-based theme, or chameleon, as the default theme. In the blocks configuration page, configure blocks to go to display in various regions. Note that, as chameleon has only two regions (left and right), all others are written to the default region (set in the main settings page, under general settings). I believe this iteration answers all major outstanding requests for functionality. It also, I hope, leaves the way open for the sort of caching and other block system enhancements chx was working on. I've taken this patch as far as I can. I'm committed to basic fixes before or after it's applied, if such are needed. But if what's wanted is another major rewrite, we'll need someone different to take it on. Reviews and comments, please! ------------------------------------------------------------------------ July 3, 2005 - 07:43 : Bèr Kessels Nice approach! One thin i dislik though (read this as: I like the rest) is the configuration for a default region. 1) it adds clutter. 2) I cannot think of any theme that will not break when I statr putting lots of content other than ni the place the theme wants it to be. 3) This should really be up to the themer. A theme should provide the default region, not the administrator. ------------------------------------------------------------------------ July 3, 2005 - 15:40 : Dries The patch no longer applies ... Looking at the code, I wonder whether the 'themed' stuff makes sense. A theme might want to theme different blocks differently based on their ID. Not theming a block is a special case of this and is already possible. Allowing the designer to set IDs that he or she can intercept, makes more sense to me. The themed-field gets a -1 from me, but I might reconsider after having tested the patch. Looking at the code, I wonder what happens when one theme calls the sidebar "left sidebar" and another theme calls it "sidebar left" (words in different order)? Is there any limitations to the current approach? ------------------------------------------------------------------------ July 4, 2005 - 03:38 : nedjo Attachment: http://drupal.org/files/issues/regioning4.patch (25.73 KB) Here's an updated patch. I've removed the "themed" functionality (which gave the option, mostly useful for admin-defined blocks, of inserting content directly without it being themed). It wasn't necessary to the patch. I might consider submitting it as a separate patch, but in fact I think the main issue it addressed - that content often looked bad when inserted into areas like the 'content' region, and would be better without the theming - will be addressed as themes designate appropriate styling for these block regions. I've also implemented Ber's suggested solution to the question of how to designate a default region for content assigned to regions not available in the current theme. Yes, it's better to leave this to the theme author--and since this avoids needing to create a new setting, it's a Good Thing. ------------------------------------------------------------------------ July 5, 2005 - 08:03 : Kobus Inline blocks could perhaps also be used instead of absolute regioning. When patching the block admin page similar to uploads thread's screenshot (as shown here: http://drupal.org/node/26288) could improve blocks quite a lot. If you look at the first screenshot, it shows a checkbox "inline" for each uploaded file. If this can be used in conjunction with [inline:xx] tags to have precise placement of the images as they state here, the same can be done for blocks, by means of a tag [block:xx] or something like that. given, that if you want to use that, you would need to know HTML (and have it allowed in nodes) to achieve this precision layout of blocks inside nodes by means of tables, for example. I would really LOVE to see inline blocks together with inline images. The combination of these two elements can really provide for a total themed look instead of just blocks. I could, for example, have a node with two inline blocks, and another with no blocks and 3 images and one with one block and one image. This would break the left/right columns look completely, and, if you choose, eliminate it almost completely, as you can generate a "sticky" node at the top with the appropriate block inside it. I think that inline blocks is more important than more regions for blocks, but that might just be me :) Regards, Kobus ------------------------------------------------------------------------ July 6, 2005 - 21:11 : nedjo Because my patch allows modules to declare their own regions, it should be easy to implement inline regions through a module, e.g., inlineregions.module. Something like: <?php /** * Implementation of hook_nodeapi(). */ function inlineregions_nodeapi(&$node, $op, $arg = 0, $arg2 = 0) { switch ($op) { case 'view': foreach(inlineregions_regions() as $key => $value) { $node->body = str_replace ('[inline:' . $key . ']', theme('blocks', $key), $node->body); } break; } function inlineregions_regions() { return variable_get('inlineregions', array('inline1' => t('inline one'))); } function inlineregions_settings() { // Interface to allow site admins to define regions by setting variable 'inlineregions'. } ?> ------------------------------------------------------------------------ July 7, 2005 - 05:48 : Kobus I have no idea how to implement your code into a module as of yet, but once the new patch is approved, I will play around a bit with it :) Thanks for the hint! Kobus ------------------------------------------------------------------------ July 15, 2005 - 21:32 : stefan nagtegaal While I _really_ want to see such a thing hit the trunk, I'll soon review/test this patch..

1 0

[drupal-devel] Another ajax function: form_autovalidate()
by Jeff Robbins 16 Jul '05

16 Jul '05

A friend of mine works for iFilm and he was just showing me the AJAX functions for their registration form. It validates as you go: http://www.ifilm.com/user/registration/index.jsp Type in "robbins(a)jjeff.com" for the email address and see what happens. Also notice the sexxy CSS shaded textfields... It occurs to me that Drupal could do pretty much the same thing with its registration form. But we'll need a new ajax function. Something like form_autovalidate() that doesn't fire off until you actually exit the field (onblur). This would also be a good place to do some brainstorming about other ajax/javascript functions. HTTPPost has been mentioned. How about something like form_mastercheckbox() which would be a function that would create a checkbox that would check/uncheck all checkboxes of a given criteria within a form? (Good for admin/node!!) How about collapsible columns or something to make admin/access a little more manageable. Or a drupal_fade_element($trigger,$from_color, $to_color) function for real attention-getting drupal_set_message()es. Examples: http://www.axentric.com/aside/fat/ http://www.37signals.com/svn/archives/000558.php Sorry for all the long emails recently. Ever since I got addicted to crack, I've just got the f*ing greatest ideas in the world!!! ;-) -Jeff Robbins p.s. Should this actually be a feature request issue? It's seems a little too nebulous for that right now... _ _ ________ (_) (_)__ / __/ __/ _________ ____ ___ robbins(a)jjeff.com / / / / _ \/ /_/ /_ / ___/ __ \/ __ `__ \ www.jjeff.com / / / / __/ __/ __/_/ /__/ /_/ / / / / / / aim: jefforbit __/ /_/ /\___/_/ /_/ (_)___/\____/_/ /_/ /_/ /___/___/

2 1

[drupal-devel] Chat about mailing solutions with CivicSpace/Drupal
by Kieran Lal 16 Jul '05

16 Jul '05

Hi, we had a chat this morning about mailing solutions for Drupal. If anyone is interested in doing development for mail solutions for Drupal please let me know. To-do lists coming. Thanks, Kieran Ok, let's get started I'd like to start by going around the invitees talking about what your interest in mail for Drupal is. drob____ joined the chat room. My main goal is to introduce everybody and hope that we can develop some solutions collaboratively drob___ we are just starting introductions I'll start My name is Kieran and I am the development manager for CivicSpace labs we release mass mailer in our distribution and we are integrating it with CiviCRM for our next major release next hand dave-civicrm go ahead my name is dave greenberg project manager for civicrm we have two main thrusts dave-civicrm hand drob____ one is that we want to make sure the civicrm core can be used for folks who want to as the people/contacts datastore for various mass mailing solutions in drupal second is we are building a high capacity massmailer solution for release later this year based on the now open-souced EmailNow implementatoin which lobo, brian and others built at Groundsrpring.org done dave-civicrm drob morning drob____ go ahead dan robinson - civicactions we're a prof'l services firm using all this stuff for our customers we are working on civicgroups see my email for more info/background done drob____ hand georgeh go ahead My name is George Hotelling and I'm working on porting http:// www.citizenspeak.org/ to a Drupal node module We're releasing the module under an OSI approved license (probably GPL) and want to make sure it's useful to as many people as possible georgeh chx joined the chat room. hi all chx chx we are using hand system and doing introductions georgeh: more? So whatever techniques for scaling that the mass mailer projects come up with, I want to integrate with them to avoid wheel duplication done georgeh next person? hand killes go ahead I am Gerhard Killesreiter, I am a Drupal IT consultant and working for CivicSpace on CivicRM integration for a few Drupal modules. Among them the massmailer module. I am also the maintainer of the listhandler module.l done killes luksedj left the chat room. next person hand MegaGrunt go ahead Robert Castelo [MegaGrunt] - I'm developing eNewsletter module, which packages nodes based on terms to create a personalised newsletter. which has now been split up into component modules to handle various email tasks for any other Drupal modules which want to use them done MegaGrunt next person hand chx go ahead drob____ is now known as drob. I am Károly Négyesi (Charlie // chx) -- I am a core developer. for now, that's it chx brian? brian-civicrm brian mcfee (civicrm).. dave pretty much said it all, but i'm working on the update/reimplementation of emailnow (done) brian-civicrm great ok, so I hope those introductions will lead to partnerships Michael Haggerty won't be here today but will be reading transcripts he has a professional mailing service that is bonded get's 93% success rate it's a service that many folks in the CS community would like to see integrated Jo Lee from Citizen Speak isn't here yet georgeh: do you want to describe what Citizen Speak does Sure Citizen Speak is a non-profit that allows organizations to create email forms with pre-selected recipients and pre-filled content Basically a small, free version of CapWiz georgeh ok thanks The goal is to allow organizations to create advocacy campaigns on specific subjects to people who can make change done georgeh thanks So killes is doing development on mass mailer which uses php list php list is a php based mailing solution that should give better performanance than the php mail function hand killes we have had problems getting it installed on hosts killes go ahead I just want to suggest that everybody who has it reads the mail from Michael Haggerty from yesterday. killes hand drob it isnot onyl about sending x mails /hour it is also about how many of those actually get through to the recipient. done killes drob go ahead not sure which email - i just saw one about the "agenda" i have two issues i would like to deal with in the nearterm a) can we use phplist to do "listserve" i can explain later b) why don't we just let "phplist: be phplist" i can explain this as well if you want to go there done drob hand killes georgeh and MegaGrunt: how can we make mass mailer useful for you killes: go ahead to drob: a) I am not sure phplist can do that. We need to check this. I was under the impression it is just a announcemnet type mailign list thing. b) people apparently want the integration. done killes georgeh or MegaGrunt? georgeh is gathering his thoughts georgeh what functionality does MassMailer have that is not tied into PHPList? MegaGrunt hand killes killes i.e. take PHPLIst away and what is left? MegaGrunt go ahead massmailer itself does do much. doesn't killes hand MegaGrunt it is just the Drupal glue that you need to get list management screens and so on. the advantage of massmailer is that you can have also other backends than phplist. killes hand georgeh MegaGrunt go ahead everybody can have an account on my testsite and check massmailer out. done killes sorry georgeh your in queue the functionality of PHPList is locked into PHPList MegaGrunt (http://civicrm.civicspacelabs.com /home/ <== testsite) killes can't be leveraged by other modules done MegaGrunt hand drob hand killes georgeh go ahead drob then killes me? drob georgeh go ahea What I would need from MassMailer is an API doc saying "this function will send mail" and some thing saying how to plan for scaling That may exist, but I haven't seen it done georgeh drob go ahead my understanding is that the phplist team is currently working to separate their front-end from their back-end also it looks like if you look at the phplist engine that the api's are pretty straight forward but my question is why we expose a management interface to phplist at all i think i would be happy as a clam if if could just populate the db from cs and then use phplist to manage my mails they have a nice welll worked out mgmt interface done drob ok, now me again. killes killes, brian-civicrm comments MegaGrunt: you are wrong, massmailer is the tool to leverage phplist. georgeh: those apis are there. killes hand MegaGrunt MegaGrunt: go ahead drob: we shoudl get into touch with the phplist maintainers. I know that Aaron was. killes but no other module can leverage tasks like bounce handling MegaGrunt I think that the future massmailer version will use civicrm much more than massmailer used contact manager and so some stuff might go away. killes ? MegaGrunt hand drob there is currently no bounce handling implemented in massmailer. killes hand brian-civicrm but phplist has this feature,. done killes MegaGrunt you want to respond, killes, then brian but I mean for instance, ecommerce module can't react to bounce back after sending sale confirmation via PHLIst bounce handling? done MegaGrunt killes no, because massmailer does not yet provide the interface. done killes brian-civicrm i'm not too familiar with phplist (maybe dave can chime in?), but we have a pretty extensive set of bounce handling tools leftover from the old emailnow. much of it is currently in perl, but i'd be interested in working with other people to open it up and abstract it done brian-civicrm chx: could Drupal have mail interface in core? long term hm depends chx I think it could, there have been discussions about it. killes currently it has an SMTP interface as core itself does not mass mail, this seems to be enough chx hand MegaGrunt MegaGrunt hand killes not just bounce handling, but all other email related tasks they are all locked away in the third party application unless we expose them, or write our own component modules to handle specific tasks done MegaGrunt geilhufe joined the chat room. killes: go ahea d chx: I think there will be this subscription module by your SoC student. if Dries will use it on drupal.org, how long do you think it will take that it is in drupal cor?e ;) done killes hand drob hand chx drob i have to go pretty soon i would like to know if we can move forward on anything in short term as i said i think it would make sense to contact the phplist folks and clean up the use of the "engine" also would like to talk about using the phplist management interface instead of using drupal parrallel interface also the issue regarding Listserve capability done drob chx and then let's make some plans going forward ok so, that SoC applicant will not focus much on mailing itself he concentrates on "subscription" like you can subscribe on watchdog and such chx chx? done, sorry chx Ok list of tasks 1) get mass mailer API to MegaGrunt and georgeh 2)talk to phplist, drob or killes? 3)Look at a larger API drob and brian-civicrm and killes that's all suggestions hand drob drob what do people think about simply using phplist to do management? is that what you mean in 3) done drob brian-civicrm: is there an interest is integrating your mailing solution into Drupal or just CiviCRM hand dave-civicrm go ahead our mailing solution will be tied to CiviCRM but CIviCRM should be open to be used for contact and group storage for 'any' mailer solution for our solution - there will be lots of linkages between the mailer actions and the contact datastore so we don't think it will be separable dave-civicrm hand brian-civicrm hand go ahead hand georgeh georgeh in queue brian-civicrm go ahead ok georgeh go ahead If someone could point me to CiviCRM API docs that would be nice too, I'd like to look at any ways to integrate CitizenSpeak with CiviCRM where it makes sense My email is george(a)hotelling.net I'd looked for API docs but didn't see them georgeh irc needs one of those aim "person is typing" icons.. brian-civicrm done georgeh sorry brian-civicrm go ahead in addition to what dave said about our solution being integrated to civicrm, we're also trying to not rely on much other code for mail delivery. much of what we do happens at the mta level done brian-civicrm hand drob Ok, another meeting in the future? or follow up on email? I have to get going in 5 minutes drob go ahead yes is there an email list? i can set one up if you want done drob I'd like to see the traffic on Drupal-dev if possible see who else might show up hand drob go ahead ok so could you set up the discussion on drupal-dev with an email drob Yes, but not until tonight is that okay? k done drob Anyone else? hand MegaGrunt MegaGrunt go ahead I'd like to chat about coding in future or via email stratergies for scalability and such like done MegaGrunt Anyone else? hand dave-civicrm go ahead we'll be posting spec, progress etc. on our confluence site and will include info about architecture, scaling methods etc so we can post periodic updates to drupal-dev if that would be useful dave-civicrm Yes also would like to f/up w/ drob on his idea for just pushing DB stuff from CS to phplist and understand that better so - i can start that conversation after you announce start stuff on drupal-dev done dave-civicrm Anyone else? Ok thanks everybody, please feel free to contact each other about common interested I'll post this transcript and some follow ups to drupal dev please feel free to send me parts that you want me to conclude, to make sure I cover everything thanks everyone bye

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by stefan nagtegaal 15 Jul '05

15 Jul '05

Issue status update for http://drupal.org/node/16216 Post a follow up: http://drupal.org/project/comments/add/16216 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: nedjo Reported by: paragkenia Updated by: stefan nagtegaal Status: patch While I _really_ want to see such a thing hit the trunk, I'll soon review/test this patch.. stefan nagtegaal Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 12:27 : paragkenia I read the comparision discussion between *Drupal* and *Mambo*. In several messages it was outlined that Drupal can place blocks only in right and left and not flexible to put them on anywhere where one want. It will be great if this can be changed in upcoming versions. I am no pro at PHP, so don't know how much time this task will take, but I think it is very important. parag ------------------------------------------------------------------------ April 15, 2005 - 03:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 17, 2005 - 02:24 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions.patch (8.17 KB) This much-requested functionality - to have the ability to place blocks in more than the two predefined regions - was partially addressed in issue http://drupal.org/node/19694. [2]. But "blocks" are still limited to the "left" and "right" sidebars (hard-coded in block.module). This patch is a first step designed to enable multiple (eventually, admin-definable) regions for blocks. I've moved the existing "left" and "right" block regions to a 'region' table (with ids of 0 and 1, as currently used in themes). Then all references to the regions are drawn dynamically from the table. This way, if further records are added, they will appear in the list of available regions for block placement. Doing this actually reduces some duplicated code, since it's no longer necessary to repeat code blocks for each of "left" and "right". As it stands, the patch doesn't add any new functionality--but I don't think it breaks anything either. New functionality would need (a) new regions defined, and (b) changes to themes. A simple first step might be, e.g., to add a "footer" region and then add a call in the footer generation to append any blocks assigned to the footer region there. I'm setting this to patch, but I'm aware that it needs some discussion and refining before it'll be ready to apply. [2] http://drupal.org/node/19694. ------------------------------------------------------------------------ April 17, 2005 - 03:05 : nedjo Attachment: http://drupal.org/files/issues/block_regions.png (5.65 KB) Here's a screenshot showing the block admin page, with drop-downs for region placement (the options are dynamically generated based on defined regions). ------------------------------------------------------------------------ April 17, 2005 - 04:57 : adrian The biggest problem with this is that you can have multiple themes, and each of these themes can have different regions available. Also, the method of defining which regions are available needs to be standardised. Some of the work that me and Vlado are working on for the install system would go towards solving that problem (ie: meta information for modules, themes and styles). This has been discussed to death, but the general consensus has been that we _want_ to do this, but we need to solve a few other problems properly first, the most pertinent being the interface issue. Chris (factoryjoe) recently did a whole mess of workflows for something related to this. ------------------------------------------------------------------------ April 17, 2005 - 06:09 : syscrusher The first paragraph of adrian [3]'s post is a point that occurred to me also, as I read this thread. One suggestion would be to separate the definition and configuration of blocks, on one hand, from the placement of those blocks, on the other hand. In other words, Drupal core provides a mechanism defining what blocks exist, which of these are on by default or off by default and user-selectable vs. which are forced on for all users, and the configuration (if applicable) of specialized blocks defined by particular modules. Each theme provides a standard hook function that returns an array of region names and help/description text, e.g., array('left'=>t('This vertical region is left of the main content area'), 'right'=>t('This vertical region is right of the main content area'), 'footer'=>t('The footer is below the left, right, and main content areas of the page')). The theme part of Drupal core (i.e., theme.module itself, not the individual themes) provides a standard UI that is displayed within config of *each theme* (but is one physical code base within theme.module) that allows the administrator to map blocks defined by Drupal core into regions defined by the theme, and storing that mapping as an theme-to-block_ID-to-region_ID (with weight) table in the database. From there, the actual page rendering is similar to what's being done now, but there is more of it. I guess what I'm trying to say is that the key to solving this problem is breaking it along its degrees of orthogonality, and there are three -- two in Drupal core and one in the individual theme. Scott [3] http://drupal.org//user/1517 ------------------------------------------------------------------------ April 17, 2005 - 09:14 : Dries Scott, is right. The theme should export its available regions. Then the administrator's task is to assign blocks to regions (not to setup regions). A theme could have configurable regions, but that internal to the theme. To me, the real challenge is the UI and the interaction design. Configuring blocks could easily become a real pain (while most themes continue to use 'left' and 'right'.) Of course, we can implement all the functionality, default everything to 'left' and 'right', and worry about the UI later. This should be fairly straightforward to implement and nedjo's patch looks like a first step in the right direction. ------------------------------------------------------------------------ April 17, 2005 - 23:09 : nedjo I agree with the suggested approach of themes registering their regions. I'd see this happening when a particular theme is activiated (or upgraded). Regions would be an array of names (e.g., 'left', 'right', 'footer'). New records would be created in the region table only for region names not previously registered. Some areas I'm not clear on, or that need further work: * Table naming Should a new table be 'region' or 'regions' (I've used 'region')? I don't see a convention among existing table names, some of which are singular and others plural. * Default values I've kept the existing '0' and '1' ids for regions (left and right, respectively), for backward compatibility. But this means we can't use autoincrement for the region id (rid), since autoincrements seem to begin with 1. Likely we should change to autogenerated ids. * Initial records Using the INSERT INTO statements as I've done for the initial region entries is probably counterproductive, since sooner or later they'll have to be dynamically generated. I was hoping this could be a preliminary patch, with the main work coming later, but likely we need to solve region registration by themes before this patch is applied. I don't have a good idea of how region registration by themes would be implemented (a hook on theme activation?), and invite suggestions or implementations. * Theme system changes Besides region registration, the other change I'm seeing that would be needed in the theme system is loading blocks by region name, rather than region id. This is because the ids currently used ('0' and '1') in theory might be diffferent on a particular install. ------------------------------------------------------------------------ April 17, 2005 - 23:18 : syscrusher Instead of having themes "register" their regions, why not just add a theme API hook called them_regions() that returns an associative array of $region_name=>t($region_helptext)? This would be in keeping with other similar API functions, such as those that return what permissions apply to a module or what node types are defined by a module. Most themes are going to define only a small number of regions (two being the typical case now, but I could see five or six in a complex theme), so returning a constant array will be faster than querying SQL to obtain an array of rows. There could be (optionally, at the discretion of whoever builds this thing) another API hook like theme_region_properties($region_name) that returns an associative array with detailed info for a given region, such as extended help text with recommended usage instructions for the region. Scott ------------------------------------------------------------------------ April 17, 2005 - 23:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 18, 2005 - 00:47 : adrian Because. The most common 'theme' is a phptemplate theme. And there needs to be a generic method for specifying the regions available, in a non hook_function format.. Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. You would need a standard way to define meta-information for themes, that does not need to be modified when copied to a new directory. We are working on this in the install system work, as you need a way external of Drupal to define the module dependencies and some other things. My approach would be to add a theme.dsc text file to the directory, which would allow you to specify meta-information. For instance : ---- regions: left, right, footer, center, mountie author: Johnny McAngstyPants ---- ------------------------------------------------------------------------ April 18, 2005 - 04:00 : syscrusher Adrian wrote: " Themes get their names from the directory in which they are contained.. when copying the theme to another directory, there must be _no_ modifications necessary to allow normal usage. This is one of the tenets of the new template system I designed. " A very good point. But region names don't have to be unique across different themes, so my hook function wouldn't have to be modified. The suggestion I made for the mapping metadata was three factors: theme ID or name, region ID or name, and block ID (plus one non-key weight value to order the blocks within a region, but this is not relevant here). I'm not familiar enough with PHP template to be able to respond to your comments on that one, so if you say it's not feasible to work with my schema, then I'll take your word for it. :-) Scott ------------------------------------------------------------------------ April 18, 2005 - 04:03 : syscrusher Oh, wait.....I see now what you mean! It's not the output of the function that is the problem, but the *name* of the function. Never mind. I concede your point. Scott ------------------------------------------------------------------------ April 18, 2005 - 09:44 : Jaza I'm probably jumping ahead a bit here... but something that this patch will have to eventually account for, is how to allow regions to be defined as inline. Allowing a theme to define a region's position as being anywhere on the edge of the page (i.e. top, left, right, bottom, corners, etc) is relatively easy. But what about having a region that's in the middle of a node's body, or somewhere else that's not the edge of the page? What I'm thinking of, is eventually allowing the custom region system to integrate with the CCK. Like I said, I admit that I'm jumping ahead into the future - the CCK still has a long way to go before it's ready. But ultimately, it would be cool if a theme could define a region as being after, say, the "rating" field in nodes of type "movie review". This would make the region (and the blocks in it) truly inline and in context with the actual content of the node. This would be a huge step forward compared to the current block system, which doesn't allow you to mix the presentation of blocks and nodes at all. In Drupal ATM, blocks and "the rest of the page" are totally separate, and really you have no choice but to display them as such. The result of this is that information in blocks that really should be displayed as part of a node, gets literally "pushed to the side", and always seems secondary to the actual content. Often the block has content that is just as important as the content of the node itself. Another option (of less merit, IMO - because of the extra maintenance work, and lack of enforced consistency) would be to have a region filter. You could then choose where to place an inline region on a per-node basis, by entering text such as [region:2] (example based on image_filter syntax) into the node body. Anyway, just thought I'd throw that idea into the open. I don't expect it will be implemented any time soon, but it's something to think about. Jeremy ------------------------------------------------------------------------ April 18, 2005 - 10:54 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-1.png (1.29 KB) Imo the 'regions' are more than you guys name here.. FOr example I attached 2 screens which only shows you the regions.. What I think is that it should always be possible to have free names for the regions. No matter if i call - the region where my content appears in - 'content' or 'site items'.. See attached screens.. ------------------------------------------------------------------------ April 18, 2005 - 10:56 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions---possibility-2.png (1.39 KB) And the second... See these links: - http://drupal.org/files/issues/regions---possibility-1.png - http://drupal.org/files/issues/regions---possibility-2.png ------------------------------------------------------------------------ April 18, 2005 - 17:22 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions2.patch (13.39 KB) Here's a revised patch implementing some of the ideas so far. I've used the theme engine - rather than individual themes - to generate the list of available regions. I know this isn't ideal, but e.g. for xtemplate it's at present the only option--no logic is possible in the individual theme. region is changed to a varchar field from the current tinyint. I've roughed in several regions--really just for demo purposes. More thought and work would be needed to refine them (e.g., styling, etc.). But this maybe moves the conversation forward. ------------------------------------------------------------------------ April 18, 2005 - 23:26 : Dries This patch enables different regions to be used. That is a good thing. The next question is: should we take into account that different themes could assign blocks to different regions? Lots of problems would be solved if (i) there could only be one active theme on a website or (ii) if all themes would have a common set of regions. (This "let users select their own theme"-thing is a left-over from the early days, except for WAP stuff maybe.) ------------------------------------------------------------------------ April 18, 2005 - 23:37 : killes(a)www.drop.org Giving up multiple theme support would be a great thing. People could still select from multiple style sheets. WAP shoud not be a user preference setting, but automatically detected and redirected to a special site with a WAP theme. ------------------------------------------------------------------------ April 18, 2005 - 23:48 : adrian You would then lose the ability to make a special front page theme for use with the sections module, for instance. Also, currently styles exist in the same namespace as themes, and we would have to make more a distinction of styles vs templates (or themes), but I do think this could help simplify things. ------------------------------------------------------------------------ April 21, 2005 - 18:54 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions3.patch (15.69 KB) The main issue raised, if I'm understanding well: if a theme or theme engine is present that offers regions other than those available in the default theme, any blocks assigned to those regions will be invisible to most users. Here's a revised patch addressing the concern. I've added a test for each region to see whether it's also available in the current default theme. (Actually, I'm realizing as I write this, I've used the theme engine--so it would need to be updated to test first if an engine is being used.) In any case, any regions not available by default are starred, and a message text appears (only if necessary). If there's support for the approach, I'd be happy to finish the patch. Remaining work: * extend to work with non-engine themes * finalize base set of regions to implement * implement common region set in all core themes (for now I've only done xtemplate) * work on CSS display (how blocks in each region should look) This last point I'm not too confident on and would look for help/suggestions. Screenshot to come. ------------------------------------------------------------------------ April 21, 2005 - 18:56 : nedjo Attachment: http://drupal.org/files/issues/block_regions_message.png (12.34 KB) Screenshot showing starring of non-default regions plus message. ------------------------------------------------------------------------ April 21, 2005 - 19:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 19:23 : resmini My two cents. If this has to be done (and it should), better get rid of spatial definitions for areas such as left, right, top, bottom, etc. Use semantic names related to content and let the theme take care of their positioning interely. Also note that there in an ongoing debate in IA trying to build up a standard naming convention for page regions in a way that is semantically (and logically) correct. Just for the sake of it, you can check http://www.stuffandnonsense.co.uk/archives/whats_in_a_name.html http://www.stuffandnonsense.co.uk/archives/whats_in_a_name_pt2.html with follow-ups, including Eric Meyer's. There are more substantial contributes in the AIfIA web site, but I can't seem to find them now. I'll post a link or an abstract if I manage to. -- vector at exea dot it ------------------------------------------------------------------------ April 21, 2005 - 20:15 : nedjo Good points, useful references. The default regions I'm thinking of are: 'banner' => t('banner'), 'left' => t('left sidebar'), 'right' => t('right sidebar'), 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), 'footer' => t('footer') Perhaps "body" would be better as "content"? It would be easy enough to add in more regions, e.g., within the content (after title, after help, etc.) One issue is that many of these regions will already have rendered content. Should the blocks come before or after that other content? I've assumed after for banner and footer, while giving both options in body. In any case, refinements or suggestions would be great. ------------------------------------------------------------------------ April 21, 2005 - 20:56 : resmini Well, 'banner' => t('banner'), 'left' => t('left sidebar'), 'right' => t('right sidebar'), 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), 'footer' => t('footer') The classic (as far as classic goes for something Web related) scheme comprises 5 spatial regions, much like stefan's http://drupal.org/files/issues/regions---possibility-1.png with a left area mirroring the one called 'blocks'. Call them top, left, center, right, bottom. Variants usually exclude one or more of these, layout-wise. If we talk content (semantic) instead, things get a bit more complicated, as these spatial regions normally include more than one content-area. The top, for example, could include ad banners and the site's header, or the main menu. But these merge seamlessly with CSS definitions, which are definitely something that should get properly standardized (most of the errors / inconsistencies I'm encountering with Drupal today are related to this), but this is out of scope in this thread. What I somewhat object to the definitions above is that it mixes the two approaches. 'banner' is not spatial, is content, as it is the distinction between body top and bottom. If 'banner' goes there, it is 'top', whatever that might be. I designed a couple of web sites which had headers/logos/banners at the bottom of the page, and I'm not exactly the wildest designer you'll probably meet. And if we include body_top and _bottom, we should also add 'navigation', or 'menu' and some other content-related semantic region (impressum, or company_data, or whatever). I suggest that either we go along 'top' => t('banner'), 'left' => t('left sidebar'), 'center' => t('body'), 'right' => t('right sidebar'), 'bottom' => t('footer') or we dedicate some time to detailing what could possibly fit there semantically, which is perfectly possible without limiting design freedom or whatever, since the vocabulary is not infinite, but not something you do out of the blue. Please note that I understand t('something') to be an example, since such a layout only defines regions on the page, not semantic regions. My main content could fit nicely in the bottom region. As for the names for the regions, they are not important, as much as they are coherent and enforced. ------------------------------------------------------------------------ April 21, 2005 - 23:16 : stefan nagtegaal Attachment: http://drupal.org/files/issues/regions-final.png (2.39 KB) Maybe something like this??? But, I have to say that I _really_ liked the solution to split the 'content'-region into the 'content' and 'beneath content'.. I love that! ------------------------------------------------------------------------ April 22, 2005 - 00:20 : resmini Stefan, yes. That's basically what you can build if you stick with spatial, and this layout can generate quite an amount of (sane) layout variations even if you interpret it strictly (suppose a default) as <div id="header"> </div> <div id="left-bar"> </div> <div id="content"> </div> <div id="right-bar"> </div> <div id="footer"> </div> What you can do with this is left basically to the theme designers and their use of CSS, CSS-P or tables (brrr), but this could be an easy and proper way to identify macro-regions in which more accurate positioning happens at a more specific level. I'm all in favour of subsequent identification of sub-areas (top and bottom in body), but I don't think it would be a good idea to mix the different approaches I mentioned in my previous post. A site with lots of things going on or which is not just blogging surely has the need to use its content area in a wiser manner than just putting there 'content', the number of modules doing precisely this is more than proof, but that falls more in a 'Drupal definitive guide to semantics', in which CSS selectors are used or suggested strategically for such a scope. >From this point of view and for the sake of this thread, any unique area / div (#name) could (should?) be a target for blocks, and this in my opinion (*) would be the perfect solution, but I do not know if and how this is even remotely possible in the current Drupal. (*) It's quite late, local time, and it was a looong working day. ------------------------------------------------------------------------ April 22, 2005 - 00:38 : resmini Attachment: http://drupal.org/files/issues/regions-final-variation.png (1.9 KB) Just to be clear, I add a variation of stefan's scheme that shows how this is *not* by any means positional, but spatial, or better relational. Use your CSS imagination to take out regions, reduce them to empty containers, enlarge them, make them taller, shorter, whatever. 5 regions, do what you like. ------------------------------------------------------------------------ April 22, 2005 - 00:44 : resmini Sorry, I forgot. And this is also why I'm not too keen on calling anything 'content'. If I enlarge my right region enough, why not put my content there? Shouldn't this be a theme-level concern? It's nothing serious, but if my center area is called 'center' (or something similar and more sexy), I won't confuse anybody. This is left, center, right: do with them what you prefer. Content in the bottom? Show me. If I call something 'content', I'm more than suggesting that content goes there, and only there. ------------------------------------------------------------------------ April 22, 2005 - 10:17 : stefan nagtegaal Resmini, maybe it is only me but I think that you are making a mistake in your way of thinking.. I get the feeling that you're mixing the 'regions' and 'divs'.. the 'regioins' should have meaningfull sentences, but the divs shouldn'thave.. As an example: $region_name => $content_body here we go: 'header' => $logo 'left sidebar' => theme('blocks', 'left') 'right sidebar' => theme('blocks', 'right') 'content' => $content 'footer' => $footer. So, $region_name does not have to be equal to the id or class of the divs.. ------------------------------------------------------------------------ April 22, 2005 - 11:27 : resmini Stefan, >So, $region_name does not have to be equal to the id or class of the divs.. Yes, absolutely. I probably didn't make myself very clear: what I'm trying to point out is that in 'header' => $logo 'left sidebar' => theme('blocks', 'left') 'right sidebar' => theme('blocks', 'right') 'content' => $content 'footer' => $footer. there is no reason at all to call 'content' the region that holds $content. nedjo asked in #24 'body_top' => t('body top'), 'body_bottom' => t('body bottom'), if /Perhaps "body" would be better as "content"?/ and all my reasoning is simply that no, that is not content, or it shouldn't be (or better: it may happen that main content is elsewhere). As a matter of fact, even the connotation 'sidebar' doesn't fit very well logically. To make it short: Today's method works, but has limits. Mambo, which paragkenia quotes at the beginning, handles more 'user regions' but in pure Mambo style conventions are so loose that they are hardly useful. If we define regions, as in nedjo's example, in my opinion these regions shouldn't imply informational layouting, only relational positioning (that is, where they stay in the browser viewport). I know it may look like overdesigning, but Drupal constantly enforces conventions and coding guidelines everywhere: this is one of the best aspects of the project and I think it should carry to the layout. ------------------------------------------------------------------------ April 22, 2005 - 11:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 19:48 : chx Let's get back to the code. If my understanding is correct the big discussion is about how to name potiental rectangular areas _after_ this is commited. So, first get this committed. What's need to make that happen? ------------------------------------------------------------------------ April 25, 2005 - 20:56 : chx I spoke with Moshe, Steven, JonBob and the result is: keys shall be numbers, and themes shall define the values. We will make region zero and one required. There will be a define('REGION_CONTENT', 0) and a define('REGION_SIDEBAR', 1); so you can have readable code still. Either wait for me to code it or feel to do it yourself, just drop me a mail via the contact form if you are doing it. ------------------------------------------------------------------------ April 27, 2005 - 18:14 : nedjo Károly, it's great if you're willing to take on finishing this. I tried to summarize remaining work in update 20, above [4]. The numerical keys look fine to me. In terms of an initial default set of regions, one quirk is this: for now, so far as I can see (and assuming the approach I sketched in), available regions can be defined only in (a) theme engines and (b) individual themes that don't use an engine. So, for instance, an individual xtemplate based theme can't define its own custom regions; they need to be defined in the theme engine. (Unless and until the whole theme system should switch to the sort of configuration file adrian suggested above [5].) Which is to say that, under this approach, we'll be defining a set of regions for each engine, and then all themes using that engine should try to implement those regions. (Otherwise, if a site admin selects a region defined in the engine but not implemented in the default theme, the content won't appear.) Please let me know if there's anything in what I've done that isn't clear, or if you want to pass some or all of this back. Thanks! [4] http://www.drupal.org/node/16216#comment-27398 [5] http://www.drupal.org/node/16216#comment-27052 ------------------------------------------------------------------------ May 9, 2005 - 22:36 : chx I had a "short" discussion with the UI team leader ie. Ber Kessels. The outcoming is that we will change hook_block so that it uses callbacks a bit like menu system. Here's an example: <?php function module_block() { $items = array(); $items['module_header'] = array('callback' => 'mymodule_page', 'weight' => -50, 'region' => 'content' , 'cache' => TRUE, 'pages' => "node/*\n<front>"); return $items; } ?> Please note that we are allowing caching the themed output of each block independently. The theme system will execute hook_block as it does now and it'll execute the callbacks defined in module_block as well. Of course if the callback is cacheable and in the cache, it'll print it from cache. If it's themeable and not in the cache, it'll cache it before printing. Pages contains a string (could be PHP code!) which can be overriden in the block configuration screen. Callbacks defined in hook_menu will have lot less functionality after this, they will be used for non-themed pages mainly. ------------------------------------------------------------------------ May 9, 2005 - 22:45 : chx More explanation is requested for the example. module_header is the unqiue name of the block. pages define on which pages the block is visible. ('pages' in the block configuration screen.) Maybe I'll implement 'visibility' from the same screen as well. callback, weight are well known Drupal terms. cache is a boolean which defines whether given output is cacheable or not. ------------------------------------------------------------------------ May 9, 2005 - 22:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 22:52 : Bèr Kessels Attachment: http://drupal.org/files/issues/more_regions_principle.png (123.29 KB) attached is a schematic which might clarify this a little. And I would also like to comment on me being the UI leader: I do not consider myself any leader, no ofeence, though. Just to clarify that. ------------------------------------------------------------------------ May 10, 2005 - 00:42 : nedjo I am not opposed to the idea of changing the _block() hook to use callbacks (I have no opinion on it, not immediately grasping the need), but this seems quite distinct from the aim of enabling multiple and extensible regions. Why can't we just move ahead with the block generalization? I suggest: * quickly implement the proposed block region generalization, using only the two existing regions (i.e., implementing them in core themes) * later worry about: - adding further regions (the details of which are best done by those primarily responsible for the particular themes) - possible changes to the _block() hook. Wouldn't this make sense? Or am I missing some pressing reason for which the block generalization has to wait? ------------------------------------------------------------------------ May 10, 2005 - 03:28 : killes(a)www.drop.org "Or am I missing some pressing reason for which the block generalization has to wait?" I might be missing something too, but I thought Chx was just talking about the block generalization and proposing a way to code it. ------------------------------------------------------------------------ May 10, 2005 - 04:41 : factoryjoe I wanted to chime in with this discussion because it's an important one and has some really huge implications for Drupal moving forward. That said, I also have a day job pulling all my attention which means that the big ideas I have for this problem can't be put into a complete visual form for at least a week or more. In the meantime, I'd like to offer a few thoughts on the matter. * *Regions do not belong in themes.* Blocks were originally separate from themes for a reason. Themes should define the general look and feel of a site -- and to some extent a site's behavior. Layouts which define the spatial relationship between regions belong in some intermediary between style and content, which does not currently exist in Drupal. * I would propose that *layouts become a new kind of CCK tool.* By that I mean that they can be defined, shared and deployed very easily -- even as simply as tossing a directory of some .layout textfiles into a layouts/ directory. Note that this suggestion has nothing to do with the way CCK /might actually/ work right now; instead I'm suggesting how I would like it to work. I would like, for example, to create a CCK item like a "person" and ship it with a .layout file that carries all the semantic goodness needed to output that "person" to the screen in juicy, semantic markup... which anyone can come along and theme to their heart's content. * *Creating shareable layouts should be relatively painless.* Dashboard [6] sets the bar for easy hackability. It should be that easy to create layouts for Drupal... I can imagine creating an "iTunes layout" or an "Image Gallery" layout and so on... If we used something akin to PHPTal to develop the layouts, we could keep development fairly standard while making it possible for more folks to hack up cool and innovative layouts. * *Layouts should be extensible.. to a degree.* I see a huge problem with how this discussion has floated back and forth between semantic and spatial region naming. Because we talk about this problem in those terms, we fail to identify the real problem and opportunities presented to us. Here's the thing: when you predefine regions, you limit creativity and the ability of people to really use the system. On the other hand, when you make a system too flexibile, it quickly becomes unwieldy. In all the mockups presented above, both classes of problems would arise. Therefore we need to think about a way to stay flexibile while "taming the beast." * To that end, I suggest developing *self-contained layouts that are contextually-complete.* So for the example of the iTunes search layout... you would know before hand that you get a couple multiple select boxes that you can hook up to whatever taxonomies you want to progressively filter [nodes]. You could even change the .layout file, allowing you to theme it to your liking -- even though that would totally optional, given the layout's internal default styling. Once you've got your layout, you would go into a layout module UI [7], create a new layout [8], select the layout from a list [9] and then give it a path so you can access the layout... You would then walk through a wizard [10] that would help you populate that layout with all kinds of nice Drupally goodies... feeds, node listings, PHP code, etc. The power in this approach is multifold. For one, it snaps Drupal out of its block mentality and allows designers to really innovate with individual page designs. In fact, I've already thought out how I could reimplement Flickr using this system, combined with Drupal's native feeds, taxonomy and menu module, and I'd barely break a sweat... sort of. ;) But anyway, this is a very productive conversation to be having, but I really think that we should consider whether the old paradigm, as such, really pushes Drupal as far forward as we have the opportunity to go. [6] http://drupal.org/apple.com/macosx/theater/dashboard.html [7] http://photos4.flickr.com/6944826_90af237c99_o.png [8] http://www.factorycity.net/demos/civicspace/layout/new.html [9] http://www.factorycity.net/demos/civicspace/layout/new_layout.html [10] http://www.factorycity.net/demos/civicspace/layout/testing_add.html ------------------------------------------------------------------------ May 10, 2005 - 06:34 : chx While factoryjoe may be right, I could be right as well. Regions has definitely something to do with themes, after all it's the theme that renders the page, and it can only render regions that it knows of. So, instead of postponing this into the far future when someone comes out with a layout system, I code this now. ------------------------------------------------------------------------ May 10, 2005 - 07:22 : Dries The proposed 'weight', 'region' and 'pages' would be configurable, not? Are these just defaults? The 'callback' and 'cache' options are nice to have. ------------------------------------------------------------------------ May 10, 2005 - 07:25 : chx Yes, blocks can provide a default for everything on the block and and configuration screen. Of course, you can override these in the UI. ------------------------------------------------------------------------ May 10, 2005 - 11:02 : Bèr Kessels Dries: yes, the region, weight and pages will be configurable from an admin interface. What we tried to address here, is a method for developers to choose good defaults. Take for example "logo". that should be enabled by default in a regions called header, rendered on all pages, and have a very light weight. We should not force an admin to visit the blocks admin before she can see or use the logo. Chris: I do not know if you have ever tried typo3. Its concept is some form of builder system. I do not like thar, because far too complex. If we ever get sme kind of builder in core (if ever) it will require a lot of work, and even more usability research. So for now such a builder is far out of our reach. Lets aim at goals that are more realistic ;) So: it does belong in themes, its the best place that is still realistic. I do like your visions, Chris, but I hope you agree they are not realistic, yet. So, maybe you can think of a path towards your visions, ow we can reach such a builder-system, you describe? ------------------------------------------------------------------------ May 10, 2005 - 16:52 : factoryjoe My browser crashed before I was able to submit my followup to chx's comment... I have no problem with the current work going forward and am happy to see it happening. I know that my ideas are typically outlandlish and far off... That's the kind of design I enjoy doing! In any case, I see chx's solution being a means to an end; once we have abstracted the region code, it become much easier for me to get some help creating my vision. In the meantime, and as a demonstration of how I see this layout system working (to answer, I hope, Ber's concerns about clunkiness), I've created a workflow movie that shows off how fast you'd be able to add content to the system. Check it out: http://factorycity.net/demos/civicspace/layout/media/layout_workflow_v1.mov Feedback appreciated. And, if you want to try the demo out yourself (it's all hardcoded, like a "movie set" for my UI), go here: http://factorycity.net/demos/civicspace/layout/ ------------------------------------------------------------------------ May 12, 2005 - 18:45 : nedjo Attachment: http://drupal.org/files/issues/block-dynamic-regions4.patch (13.56 KB) "I might be missing something too, but I thought Chx was just talking about the block generalization and proposing a way to code it. " Well, if I can say so respectfully, I don't think so. Not so far as I can see identifying problems with my original patch, this interesting discussion is rather addressing the (useful, but logically subsequent) question "once we have multiple regions, how should we work with them?". It's perhaps demonstrating our propensity to try to do more rather than less with a given patch--to talk for a long time when a first step solution is already in place. So here is a (yes, interim!) small, focused, and tested patch to remove the hard-coded regions. I've stripped it down so it does nothing more than (a) make block regions declared by themes rather than hard-coded and (b) implement the existing left and right regions in existing core themes. Please, try it out, I think you'll like it. I'm of the (I'm hoping not scandalous) opinion that it can be applied right away, and so clear the way for further progress. In particular, this patch leaves the adding and configuring of additional regions to theme authors/maintainers, who are best qualified for the work. "I spoke with Moshe, Steven, JonBob and the result is: keys shall be numbers, and themes shall define the values. We will make region zero and one required. " The reason I moved from numbers to strings (e.g., "left") is that a theme author defining regions has no way of knowing what regions might have already been defined, and therefore what integers might have aleady been used. It's like module and theme names--we'd have to use random numbers to avoid conflicts, so we're better off with string names. ------------------------------------------------------------------------ May 12, 2005 - 20:17 : Bèr Kessels nedjo, I am not a fan of your solution for blocks that dissapear. It breaks the ability to allow more themes on a site. if important blocks dont show up, your site will simply break. I would rather suggest that every theme MUST have a region called 'default'. any blocks that want to go into a non-existing region, will be placed there. We must define a standard listy of suggested region names. to avoid a wildgrowth of names. I am not sure if i like the way you do function phptemplate_regions(). these regions should be defined in the templqtes, not the engine. Otherwise all phptemplate themes will still all have two regions. Note that i did not test your patch thouroughly, just applied and looked at. ------------------------------------------------------------------------ May 12, 2005 - 21:38 : nedjo Thanks for your comments. I think we're getting somewhere. "I am not a fan of your solution for blocks that dissapear. It breaks the ability to allow more themes on a site. if important blocks dont show up, your site will simply break. I would rather suggest that every theme MUST have a region called 'default'. any blocks that want to go into a non-existing region, will be placed there. " Good suggestion. Having a default region for blocks to show up sounds like a valuable backup. I'm thinking we might want to have a way to designate a given region as the default, rather than having to have one named 'default'. Thoughts? "We must define a standard listy of suggested region names. to avoid a wildgrowth of names. " Sure. But the patch doesn't prevent doing that--it enables it. "I am not sure if i like the way you do function phptemplate_regions(). these regions should be defined in the templqtes, not the engine. Otherwise all phptemplate themes will still all have two regions. " Oh, I wholeheartedly agree, and I've noted the issue above. But unless we substantially rewrite the engines, some region definition is needed in the engines, as they call blocks. Should we therefore define a base set in the engine, then call a hook from the engine to add any other regions from themes based on that engine? If so, where in the theme's files should such a hook be located? And a side note. Do let's make an effort to keep our comments friendly. Taking the time to note one or two things that do work or are done well as part of a review is I believe a valuable habit. It helps to confirm what is indeed accomplished. Beyond this, it helps to maintain the idea that we are collaborating on shared goals, rather than pushing individual and competing visions, and that contributions and work are appreciated, rather than being invitations to criticism. Thanks, Nedjo ------------------------------------------------------------------------ May 12, 2005 - 21:42 : chx I am implementing http://drupal.org/node/16216#comment-29282 but it takes time. regions again have names. default and sidebar regions are mandatory. This has little to do with nedjo's code much more with his idea -- I looked at the screenshot and said, OK this is great but... we'd like to have a lot more 'blocks' if this comes through, henceforth the above mentioned solution. ------------------------------------------------------------------------ May 12, 2005 - 22:39 : nedjo Okay, thanks for the clarification, I hadn't understood that you were taking a new approach rather than building on what I'd begun. Given that that's the case, staging as I'd suggested obviously won't work so I'm content to wait and see what you accomplish. I'd only suggest, don't feel like you need necessarily to do everything all at once. ------------------------------------------------------------------------ May 13, 2005 - 10:34 : Bèr Kessels Nedjo, sorry if the sound of my comment was hostile. it was never meant to be that way. I am busy, and thus did not want to comment all the things i liked about your patch, but chose to pick the much smaller amount of things I thought could use some improvement. I will try to keep in mind to be more friendly next times. Also, not all of us are as fluent in English as our native English speakers. I think its good to keep in mind that for a lot of us, communication in English is not as easy as it may seem. For me, it often requires a lot of concentration to get the subtleties right. I mean: I can type some English text, look up words in the dictionary, but to get small yet important subtleties in my texts is very hard, often. But, that all said: I liked your patch. ------------------------------------------------------------------------ June 10, 2005 - 13:08 : jakeg How far off is this from being officially released or at least usable? If its usable now, what files will I need to implement it? ------------------------------------------------------------------------ June 10, 2005 - 14:19 : Kobus Attachment: http://drupal.org/files/issues/regions---possibility-3.png (2.21 KB) To add to Stefan's suggestions with the two screenshots, I modified one of them a bit, and this is how I understand Jaza's post, and yes, I agree, this would be a wonderful feature! I can't wait! Imagine how good it would look if I had a theme that has a clear white background (not visible blocks) and then these seemingly random boxes on the page, as shown in the screenshot. Especially where I can place it anywhere around the node like Jaza said with a [region:2] block etc. I say again: I can't wait! Kobus ------------------------------------------------------------------------ June 10, 2005 - 15:59 : chx I need 3-4 hrs of peace to implement the callback based thing. That's a lot these days. Let's hope I'll get on it in the following days. ------------------------------------------------------------------------ June 19, 2005 - 00:32 : chx Here's an example again of how hook_block will look like: <?php function module_block() { $items = array(); $items['module_header'] = array('callback' => 'mymodule_function', 'callback arguments' => arg(1), 'weight' => -50, 'region' => 'content', 'cache' => TRUE, ''pages' => "node/*\n<front>"); return $items; } ?> Items are keyed by unique IDs. The template system will call module_invoke_all('block'), put the rendered HTML of the blocks into regions sorted by weight. The rendered HTML is cached if it is allowed. More keys will be introduced later, but now basically we just throw everything from block configure in here, and add callback, callback arguments, region. Node teasers or fullly rendered nodes are blocks, too. Almost everything is. So, here what happens when we are on taxonomy/term/1: taxonomy_render_nodes is called it calls block_set('node_view', $weight, $node, $teaser, $page); a few times, so a few node_view blocks will be on the page later the theme system is invoked. It will ask the block system to collect all blocks, dynamic and the static blocks as well. For all dynamic blocks we have a block defined in hook_block somewhere, like the definition above, with one exception: it will have a 'standalone' => FALSE pair, so it is not a standalone block which is automatically rendered but something that needs to explicitely requested. Also, we may define a 'suffix' => 'somefunction' pair which provides us with a cache ID suffix. Look at the code below: <?php function block_collect_blocks() { // get all block definitions $static_blocks = module_invoke_all('block'); // iterate of the dynamic blocks set on the page foreach (block_get() as $dynamic_block) { // get the block definition for the given dynamic block $static_block = $static_blocks[$dynamic_block['block']]; // merge the callback arguments from the dynamic and static. dynamic_block['callback arguments'] is always set though // may be empty if (isset($static_block['callback arguments'])) { $dynamic_block['callback arguments'] = array_merge($static_block['arguments'], $dynamic_block['callback arguments']); } // try to get a cache ID suffix $suffix = function_exists($static_block['suffix']) && call_user_func_array($static_block['suffix'], $dynamic_block['callback arguments']); // if the block is cacheable or the suffix function says that it is cacheable by setting a suffix if ($static_block['cache'] || $suffix) { // set cache ID $cid = 'block:'. $dynamic_block['block'] .':'. $suffix; // try to get the rendered HTML from cache if ($block_rendered = cache_get($cid)) { $return[$static_block['region'][$dynamic_block['weight']][] = $static_block_rendered; continue; } } // render the block $block_rendered = call_user_func_array($static_block['callback'], $dynamic_block['callback arguments']); // store the block for return $return[$static_block['region'][$dynamic_block['weight']][] = $static_block_rendered; if ($static_block['cache'] || $suffix) { // if cacheable, do it cache_set($cid, $static_block_rendered); } } foreach ($static_blocks as $key => $static_block) { // is this a stand alone block, like in Drupal 4.6? if ($static_block['standalone']) { // now, the above is repeated, save that we do not have a dynamic_block here $suffix = function_exists($static_block['suffix']) && call_user_func_array($static_block['suffix'], $static_block['callback arguments']); if ($static_block['cache'] || $suffix) { $cid = "block:$key:$suffix"; if ($block_rendered = cache_get($cid)) { $return[$static_block['region'][$static_block['weight']][] = $static_block_rendered; continue; } } $block_rendered = call_user_func_array($static_block['callback'], $static_block['callback arguments']); $return[$static_block['region']][$static_block['weight']][] = $static_block_rendered; if ($static_block['cache'] || $suffix) { cache_set($cid, $static_block_rendered); } } } } function block_set() { static $blocks; $args = func_get_args(); if (count($args)) { $callback = array_shift($args); $weight = array_shift($args); $blocks[] = array('block' => $function, 'weight' => $weight, 'callback arguments' => $args); } return $blocks; } function block_get() { return block_set(); } ?> When to expire the block cache? Never. If functions can call cache_clear all, they can be smart enough to cache_clear only those blocks that are changed by them. Some blocks won't be cacheable anyways, say there is little use in caching 'active forum topics' ------------------------------------------------------------------------ June 19, 2005 - 09:15 : Dries Frankly, I don't understand what you are trying to say. What is a 'dynamic', a 'static' and a 'standalone block'? What is the suffix for? What is the advantage of making node and taxonomy views blocks? If there is no big advantage, this is just bloat. All in all, it looks pretty complex to me. If we make Drupal more flexible _and_ more complex, people will get upset, and we end up being like Plone. Drupal's simplicity is something to foster, as it allows people to go in, and change stuff. The focus is to make Drupal simpler _and_ more flexible. I merely spent 10 minutes looking at this (reading your explanation twice, staring at the code), and the newly added complexity simply turns me off. Maybe that is because I don't understand what we are gaining. ------------------------------------------------------------------------ June 19, 2005 - 09:34 : Bèr Kessels * The first thing we gain, is, very slmple: more regions. But, how many? what regions? on what pages? in what location? bearing which name? For all these issues we need some callback system. To allow themers, administrators and module developers to give answers to all these questions. what we have now: sidebars, with only admin settings, is simply too limited: It takes serious hacking (~15 lines of code in your theme) to get a login block in your header! * The second thing we get for free: We are passing along chuncks of HTML, so why not cache them in a central place. Practice points out that our current cache is not used well. We leave it to developers to cache. And developers are lazy by nature. Just looks at all the places where caching should have been done, but is not. 9/10contribs have at least one of these places. You must actually see these issues separate. The new central blocks pulling system, and the caching. the latter is something that we get for free, a high level of advanced caching (how often has not been put forward Drupal seiously lacks better/advanced caching?). But we get it only for free if it is co-developed with the new regions blocks. And Last but not least, everything is a block, from a themer point of veiw. I know developers tend to think: I do the content, and do not care about where and how it turns up. That results in a content-centric system, what we have now. Everythng is built around aa single chunk of content. while, in fact content, is yet another block. Look at http://www.terminus1525.ca/index.php?l=en or http://www.franklinpennsylvania.us/ as it stands now, its up to the developer to concenate all the HTML in the center area, into a huge chunk of HTML. While in fact everyone can see that these are a lot of separate blocks. ------------------------------------------------------------------------ June 19, 2005 - 09:39 : Dries Ber: I was talking about chx's latest changes, not the block system in general. ------------------------------------------------------------------------ June 20, 2005 - 20:06 : nedjo I appreciate the update on directions being contemplated, although I find it confusing. Again, I'd caution, let's keep focused on the aim at hand, and on a staged solution. A bigger patch means greater complexity, more difficulty getting meaningful review, and greater delays in getting a priority change. We're currently in a position where we have two hard-coded regions for blocks, a major issue if nothing else than because it reflects poorly on Drupal's usability and versatility. Moving from here directly to something like "everything you see anywhere is a (nested) block in its own (nested) region" strikes me as a bigger step than we need to take. And in belated reply to Ber's note (#53 above [11]), thanks for the thoughtful comments, I didn't mean to single you out and acknowledge that language & cultural differences play a role, I feel we can all benefit from attention to communication. [11] http://www.drupal.org/node/16216#comment-29633 ------------------------------------------------------------------------ June 21, 2005 - 21:39 : Dries Even with the explanation in chx's sandbox, this is too complex for my likings. Here is a suggestion: let's drop the caching and the 'suffix'-stuff. Let's also drop the 'complete' and 'incomplete' stuff. Keep it _simple_, chx. IMO, you're creating a monster. ------------------------------------------------------------------------ June 22, 2005 - 22:47 : chx nedjo, take over. I am out. ------------------------------------------------------------------------ June 23, 2005 - 00:51 : djnz Quick and dirty solution? Let blocks be assignable to 9 locations - Top left, middle, right, middle left, middle right, bottom left, middle, right. The actual location of these areas within a theme is up to a theme designer, but the designer should include each of them - how about $sidebar['tl'], $sidebar['tm'], $sidebar['tr'] ... Backwards theme compatibility could easily be maintained by only creating the $sidebar array if the theme has set (eg in its template.php file for a PHPtemplate theme) a flag, otherwise generate $sidebar_left from the blocks set (in sequence) to top left, middle left, bottom left, top middle and middle middle (arbitrary break) with $sidebar_right the remainder. I appreciate I have no karma here and only superficial knowledge of the Drupal code, but sometimes the clarity of a view unclouded by too much information is useful ;) ------------------------------------------------------------------------ June 27, 2005 - 08:26 : nedjo Attachment: http://drupal.org/files/issues/regioning.patch (24.74 KB) " nedjo, take over. I am out. " Um, okay. I've given the question some more thought and come to the following conclusions: 1. If we take regions to be areas of the page that specific types of content are rendered into, and a regioning system to be a system to accomplish this, we already have a number of regions and different types of regioning systems. They include: (a) our current blocks system, and (b) the various drupal_set_[region]() functions, like drupal_set_comment(). (c) specialized hooks like our help system, which assembles content to be rendered into a region. 2. LIkely we should tease out regions from blocks. So attached is a next rough cut at regioning. Features: * Default region is defined in general admin settings page * Regions are defined in both engines and themes. A particular engine-based theme has the regions it defines plus the engine's default ones. * Content can be written to regions in two ways: through blocks or through drupal_set_content($region, $content) calls. Initial comments are welcome. I'll work on getting a more polished patch and also more explanation of the approach. ------------------------------------------------------------------------ June 27, 2005 - 08:43 : deekayen Disclaimer: I offer no code for this, so this is just a bunch of idealism I can't back up. djnz's comment makes sense if you want quick and dirty, but it seems to me the correct way to do things would be in terms of relatives. I would think doing it right the first time would be easier than redoing block location code twice. For example set a standard starting location; perhaps the start is 100% height/width conceptually. If you want to put something on the right, it would be the first block on the right of the starting block - let the theme manage widths. Then if you want another block on the right, or 10, just keep adding them relative to the others kind of like the current ordering of book pages or like adding more TD cells in a HTML table. Using this example under the current standard layout, the main block could be in the middle with with relative blocks on the left and right. ------------------------------------------------------------------------ June 28, 2005 - 12:26 : arnabdotorg It would be totally awesome to see multiple regions in Drupal 5, if not 4.7. This topic has been discussed several times before, noting them down for reference: http://drupal.org/node/2790 /[September 9th 2003]/ http://drupal.org/node/10653 http://drupal.org/node/13008 I also think it would be nice to have people implement multi-region themes; see what problems we encounter, and learn from it. ------------------------------------------------------------------------ June 28, 2005 - 14:28 : arnabdotorg Forgot to add, I've patched nedjo's final patch [12] to Drupal HEAD, it's up at http://arnab.drupaldevs.org/ [13]. [12] http://drupal.org/files/issues/regioning.patch [13] http://drupal.org/files/issues/regioning.patch ------------------------------------------------------------------------ June 28, 2005 - 18:57 : nedjo Attachment: http://drupal.org/files/issues/regioning2.patch (25.03 KB) Here's an improved version of the patch--several bug fixes, no new functionality. There are still a couple of loose ends (e.g., implementing the option of particular blocks not to be themed), and I haven't fully tested it. Further to my previous explanation, here is a summary of what the patch does. I'll mark as "new" the bits added in this week's iteration. Problem addressed: Currently, Drupal has two hard-coded regions into which block content is rendered: left and right. This situation severely limits the flexibility of content presentation. Aim: Enable multiple and extensible regions for blocks and other content. Approach: 1. Hard coded regions are removed from block.module. Instead, available regions are loaded dynamically. 2. Available regions are defined in themes (and, optionally, in modules). A theme or a theme engine defines its available regions through a themename_regions() function in themename.theme file or a enginename_regions() function in an enginename.engine file. New: engine-based themes can define their own regions in a .theme file. They will have all the engine's regions plus any they define. New: modules can define their own regions through a hook_regions() call. This should allow modules to define and use "inline" regions. For example, a module could define a region, then use a nodeapi() call to load content for that block and then insert it into a formatted box in $node->body. 3. New: the regions associated with a theme are loaded as part of the system_theme_data() call, and available regions are loaded through a system_region_list() function. 4. Previously stored as an integer, blocks' regions are changed to varchar, to enable storing of strings (e.g., 'left'). 5. A "default" region is defined (as a core setting), into which content will be rendered in the case that it's assigned to a region that's not available in the current theme. The options available for the default region are "core" regions, defined as all those available in all available themes. In the main block admin page, all regions not available in the current default theme are marked with an asterix, with an explanatory note. ------------------------------------------------------------------------ June 28, 2005 - 19:04 : nedjo Attachment: http://drupal.org/files/issues/showregions.module.txt (1.13 KB) Here's a sample module using the patch's regioning. When installed, it visually marks all available regions when you visit the page ?q=showregions. This is implemented using the proposed system_region_list() and drupal_set_content() functions. (I've attached a .txt extension to the module file since otherwise module files seem to get rewritten when uploaded.) ------------------------------------------------------------------------ July 2, 2005 - 23:15 : nedjo Attachment: http://drupal.org/files/issues/regioning3.patch (28.83 KB) Okay, this is now ready for review. To install after applying the patch, run update.php, since some database fields need to be created and updated (see function update_141() in the patched update.inc). In this final version, I've: * simplified the handling of content assigned to regions not available in the current theme, by loading such content directly in theme_blocks(), so that no custom handling is required in themes. * finished the coding for designating particular blocks (including custom ones) as not themed, so that it's possible simpy to inject content. This introduces a new 'themed' parameter of blocks. * made several variables configurable in the declaration of blocks by modules. As well as $block['content'] and $block['title'], you can now set $block['status'], $block['weight'], $block['region'], $block['themed'], $block['pages'], and $block['custom']. To see the behaviour, set any phptemplate-based theme, or chameleon, as the default theme. In the blocks configuration page, configure blocks to go to display in various regions. Note that, as chameleon has only two regions (left and right), all others are written to the default region (set in the main settings page, under general settings). I believe this iteration answers all major outstanding requests for functionality. It also, I hope, leaves the way open for the sort of caching and other block system enhancements chx was working on. I've taken this patch as far as I can. I'm committed to basic fixes before or after it's applied, if such are needed. But if what's wanted is another major rewrite, we'll need someone different to take it on. Reviews and comments, please! ------------------------------------------------------------------------ July 3, 2005 - 09:43 : Bèr Kessels Nice approach! One thin i dislik though (read this as: I like the rest) is the configuration for a default region. 1) it adds clutter. 2) I cannot think of any theme that will not break when I statr putting lots of content other than ni the place the theme wants it to be. 3) This should really be up to the themer. A theme should provide the default region, not the administrator. ------------------------------------------------------------------------ July 3, 2005 - 17:40 : Dries The patch no longer applies ... Looking at the code, I wonder whether the 'themed' stuff makes sense. A theme might want to theme different blocks differently based on their ID. Not theming a block is a special case of this and is already possible. Allowing the designer to set IDs that he or she can intercept, makes more sense to me. The themed-field gets a -1 from me, but I might reconsider after having tested the patch. Looking at the code, I wonder what happens when one theme calls the sidebar "left sidebar" and another theme calls it "sidebar left" (words in different order)? Is there any limitations to the current approach? ------------------------------------------------------------------------ July 4, 2005 - 05:38 : nedjo Attachment: http://drupal.org/files/issues/regioning4.patch (25.73 KB) Here's an updated patch. I've removed the "themed" functionality (which gave the option, mostly useful for admin-defined blocks, of inserting content directly without it being themed). It wasn't necessary to the patch. I might consider submitting it as a separate patch, but in fact I think the main issue it addressed - that content often looked bad when inserted into areas like the 'content' region, and would be better without the theming - will be addressed as themes designate appropriate styling for these block regions. I've also implemented Ber's suggested solution to the question of how to designate a default region for content assigned to regions not available in the current theme. Yes, it's better to leave this to the theme author--and since this avoids needing to create a new setting, it's a Good Thing. ------------------------------------------------------------------------ July 5, 2005 - 10:03 : Kobus Inline blocks could perhaps also be used instead of absolute regioning. When patching the block admin page similar to uploads thread's screenshot (as shown here: http://drupal.org/node/26288) could improve blocks quite a lot. If you look at the first screenshot, it shows a checkbox "inline" for each uploaded file. If this can be used in conjunction with [inline:xx] tags to have precise placement of the images as they state here, the same can be done for blocks, by means of a tag [block:xx] or something like that. given, that if you want to use that, you would need to know HTML (and have it allowed in nodes) to achieve this precision layout of blocks inside nodes by means of tables, for example. I would really LOVE to see inline blocks together with inline images. The combination of these two elements can really provide for a total themed look instead of just blocks. I could, for example, have a node with two inline blocks, and another with no blocks and 3 images and one with one block and one image. This would break the left/right columns look completely, and, if you choose, eliminate it almost completely, as you can generate a "sticky" node at the top with the appropriate block inside it. I think that inline blocks is more important than more regions for blocks, but that might just be me :) Regards, Kobus ------------------------------------------------------------------------ July 6, 2005 - 23:11 : nedjo Because my patch allows modules to declare their own regions, it should be easy to implement inline regions through a module, e.g., inlineregions.module. Something like: <?php /** * Implementation of hook_nodeapi(). */ function inlineregions_nodeapi(&$node, $op, $arg = 0, $arg2 = 0) { switch ($op) { case 'view': foreach(inlineregions_regions() as $key => $value) { $node->body = str_replace ('[inline:' . $key . ']', theme('blocks', $key), $node->body); } break; } function inlineregions_regions() { return variable_get('inlineregions', array('inline1' => t('inline one'))); } function inlineregions_settings() { // Interface to allow site admins to define regions by setting variable 'inlineregions'. } ?> ------------------------------------------------------------------------ July 7, 2005 - 07:48 : Kobus I have no idea how to implement your code into a module as of yet, but once the new patch is approved, I will play around a bit with it :) Thanks for the hint! Kobus

1 0

[drupal-devel] [bug] Tablesort and $_REQUEST array handling
by Steven 15 Jul '05

15 Jul '05

Issue status update for http://drupal.org/node/5371 Post a follow up: http://drupal.org/project/comments/add/5371 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: mathias Reported by: mathias Updated by: Steven Status: patch If we're going to have an array2uri() function, we might as well add urlencode() calls in there... this would centralize a lot of existing urlencode() calls, I think. Steven Previous comments: ------------------------------------------------------------------------ January 23, 2004 - 18:07 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays.patch (652 bytes) Tablesort tries its best to rebuild the URI from which it was called. The problem is when $_REQUEST holds arrays such as $edit. Tablesort will process this as: example.com?edit=Array This can be problematic since many module conditions rely on whether or not the $edit array is set. My patch disallows tablesort to append "array $_REQUEST variables" to it's new query string, since it serves no purpose. ------------------------------------------------------------------------ January 31, 2004 - 13:00 : Dries I'd like to hear Moshe's take on this as I'm not sure this is the proper fix. I'd think that the tablesort code knows exactly what fields it should add to the URL. ------------------------------------------------------------------------ January 31, 2004 - 15:24 : moshe weitzman I don't think this is the proper fix either. For example, - browse to the Drupal.org issue search page [1]. - press Search button - On the results page, look at the links in the table header and the pager. The query state gets passed along by tablesort. This patch would break this behavior. Changing Status to 'Active', since this patch shouldn't be applied without modification. [1] http://drupal.org/project/drupal/issues/search ------------------------------------------------------------------------ January 31, 2004 - 19:01 : mathias I'm pretty sure the project system is hacking the request object just like I am before sending it to tablesort: <?php if ($_SERVER['REQUEST_METHOD'] == 'POST' && is_array($_POST['edit'])) { foreach ($_POST['edit'] as $key => $value) { if (!empty($value) && in_array($key, $fields)) { $query->$key = $value; $_POST[$key] = is_array($value) ? implode(',', $value) : $value; } } unset($_POST['edit'], $_POST['op']); } ?> Basically, we're both moving the edit array into separate name / value pairs and then destroying it before handing it off to tablesort. I don't understand what the benefit is of passing an array into a GET query string since the key/value pairs aren't retained. We could set an option in tablesort to ask it to decompose the array into it's key/value pairs for us and pass them back in the query string. For example an edit array such as: <?php $edit['a'] => 1 $edit['b'] => 2 would have a query string of: &edit_a=1&edit_b=2 instead of the currently meaningless: &edit=Array ?> ------------------------------------------------------------------------ January 31, 2004 - 19:12 : Goba You mean: <?php $edit['a'] => 1 $edit['b'] => 2 would have a query string of: &edit[a]=1&edit[b]=2 instead of the currently meaningless: &edit=Array ?> This reuses the wonderful array handling provided by PHP (as long as nested arrays are handled properly). ------------------------------------------------------------------------ February 1, 2004 - 17:02 : Kjartan Indeed project module hacks the request data. I don't really like this as a general fix as it is a hack, but for now it is the best way. I dont think the original patch will break this as it just ignors arrays(). Project module loops through the array and converts them to normal array string elements; $_POST['edit']['status'] = value becomes $_POST['status'] = value, then I think I unset the edit array to clean up the urls. ------------------------------------------------------------------------ February 5, 2004 - 15:42 : moshe weitzman After feedback from Matias and Kjartan, I now consider this patch to be desireable ------------------------------------------------------------------------ August 12, 2004 - 17:10 : killes(a)www.drop.org Patch doesn't apply anymore. ------------------------------------------------------------------------ October 8, 2004 - 06:14 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_0.patch (2.55 KB) This patch resolves the hacks project module and the ecommerce package use to rebuild the $_REQUEST arrays when implementing paged resultsets and/or tablesorting. I know some other developers have ran into this bug as well usually after form submissions. Tablesort will now fully handle multi-dimensional $_REQUEST arrays and convert them to a valid querystring and preserve user-submitted data. ------------------------------------------------------------------------ October 8, 2004 - 06:34 : moshe weitzman very nicely done ... bonus points for converting pager to use the new array2uri() function ... tablesort's poor handling of arrays frustrated me in a recent client project. this will simplify almost all cases where a form post leads to a sortable "results" table, such as in project.module. ------------------------------------------------------------------------ October 15, 2004 - 16:01 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_1.patch (2.99 KB) Moved the new array2uri function to live with its array2* counterparts in common.inc and cleaned up the function documentation a wee bit. ------------------------------------------------------------------------ December 21, 2004 - 18:43 : moshe weitzman this is a nice code consolidation IMO ------------------------------------------------------------------------ December 22, 2004 - 12:50 : Dries This patch adds more code than it removes. That aside, it would be nice if the function's PHPdoc comments were extended. Looking at the patch, it is easy to see how/when this function is being used, but reading the PHPdoc comments it is not. I'd add a simple example and some context information. Also, it is unclear what $current_key is used for without inspecting the function's code. For readability, maybe rename $array to $attributes? If that makes sense, maybe rename 'array2uri' to 'attributes2uri'? Which makes me wonder: how does this stack with the existing drupal_attributes() function? Do we really need the recursive array handling? ------------------------------------------------------------------------ March 13, 2005 - 22:25 : killes(a)www.drop.org Doesn't apply anymore. ------------------------------------------------------------------------ July 13, 2005 - 00:49 : mathias Attachment: http://drupal.org/files/issues/tablesort_and_REQUEST_arrays_2.patch (3.19 KB) Updating this patch since I've been bitten by this issue again. The new array2uri() function really shines for tablesorting and/or paging search results after a $_POST request. The only coding change involved for developers is to use $_REQUEST['edit'] and $_REQUEST['op'] instead of $_POST['edit'] and $_POST['op'] within their function callback where this functionality is desired. As an added benefit these pages could also be bookmarked. Dries, I've updated the documentation to hopefully makes things a little easier to understand. I don't think renaming the $array variable to $attributes or calling the function attributes2uri instead of array2uri would make the function and its purpose more transparent. It's not used for HTML attributes like the drupal_attributes function, but rather for form submitted data (e.g., the $edit array) that needs to be tablesorted/paged. Project module and the ecommerce package still currently hack the $_POST vars to circumvent this problem. Not sure if other modules are also doing this.

1 0

[drupal-devel] [bug] Search module UTF-8 compatibility
by Poetro 15 Jul '05

15 Jul '05

Issue status update for http://drupal.org/node/26688 Post a follow up: http://drupal.org/project/comments/add/26688 Project: Drupal Version: 4.6.0 Component: search.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Poetro Updated by: Poetro Status: patch The search module contains some bugs when using native UTF-8 database connection. To correct this some of the strtolower function should be changed to some UTF-8 compatible versions of the function like mb_strtolower. The following lines should be changed: 398: - $word = strtolower($word); + $word = mb_strtolower($word, 'UTF-8'); 493: - $arguments[] = str_replace('?', '%', strtolower($word)); + $arguments[] = str_replace('?', '%', mb_strtolower($word, 'UTF-8')); 497: - $arguments[] = strtolower($word); + $arguments[] = mb_strtolower($word, 'UTF-8'); Poetro

2 4

[drupal-devel] oops, looks like I killed Drupal.org again
by Robert Douglass 15 Jul '05

15 Jul '05

http://slashdot.org/

1 0

RE: [drupal-devel] drupal-devel
by Boerland Bert 15 Jul '05

15 Jul '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org > I like the idea of Drupal hosted developer blogs. Anyone with a CVS > account gets one and can use it or not. If we're really lucky, we'll get > Hani Suleiman[1] to convert to Drupal and start making fun of us instead > of JBoss. now that (hardware) "size doesnt matter anymore" credo seems to be valid, its time to think how we can better use these resources (not buring them, better use). a developer blog is something i would like a lot, so people can see what the progress is and what keeps you guys bizzy without going through 30+ mail per day i suggested drop.org for that, home of the drupal with the potential slogan "it takes a village to raise a cms". but "corporate wise" it might be betet to use hosts under drupal.org for that, so i am for anyone with a cvs account to have a post under developer.drupal.org. we ought to make some Terms&Conditions since somehow people will be abusing drupal.org for spamming :-(

1 0