Development

Download

development@drupal.org

May 2005

81 participants
503 discussions

[drupal-devel] [bug] Poll not inserting correctly, options missing on edit
by rbarreca 13 May '05

13 May '05

Issue status update for http://drupal.org/node/22715 Project: Drupal Version: 4.6.0 Component: poll.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: rbarreca Updated by: rbarreca Status: patch When I would enter a poll into the submission queue it worked fine, but then when I went back to edit it, the choice labels were not displaying. I noticed that the chorder on the poll_insert() function was not working as it should. This fix should do it: Change on line 177 or so: foreach ($node->choice as $choice) { to $i = 0; foreach ($node->choice as $choice) { since $i is used above that and not reset. rbarreca

1 0

[drupal-devel] admin/node is not sorted
by K B 13 May '05

13 May '05

In 4.6, the admin/node page presents nodes in an unsorted manner. Moreover, the table columns are not sortable either. This does not make sense. Should I cook up a patch for that, or is this by design for some reason that is obscure to me?

2 3

[drupal-devel] [task] Performance issues with path aliases
by Dries 12 May '05

12 May '05

Issue status update for http://drupal.org/node/22035 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: mathias Reported by: mikeryan Updated by: Dries Status: patch Attachment: http://drupal.org/files/issues/alias.patch (7.97 KB) I upgraded the patch to HEAD (didn't apply) but it still doesn't work ... my URLs are not replaced by their aliases. I attached the updated version of your last patch. No need to optimize this more so let's evaluate this first. I'll test it on drupal.org, which only has a few aliases. Let's hope other people will test this too. Dries Previous comments: ------------------------------------------------------------------------ May 5, 2005 - 03:10 : mikeryan See Investigate use of conf_url_rewrite [1] for context... The current core support for translating incoming path aliases to the internal Drupal path (drupal_get_path_alias) and substituting aliases when generating links to internal paths (drupal_get_normal_path) does not scale well with many aliases. The ease with which pathauto enables site administrators to generate large numbers of aliases exposes this issue, but it is inherent in the core implementation, because drupal_get_path_map reads in the entire url_alias table at bootstrap time. I'd like to discuss ideas on how to improve the performance... Most obviously, why not simply query the url_alias table as needed instead of loading the whole table? In the incoming case, only a single simple SELECT is necessary, which will always be more efficient than reading the table. In the outgoing case, there might be some slight performance advantage to caching the table with a small number of aliases, but the disadvantage can become huge as the alias table grows. One note - I've noticed that the src column in url_alias is not indexed, I think adding an index should significantly help the performance in the outgoing case if we were to do individual SELECTs. Any other thoughts? [1] http://drupal.org/node/21938 ------------------------------------------------------------------------ May 5, 2005 - 04:02 : mikeryan Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB) What the hell, I went ahead and gave it a shot... On my home system, where I'm testing out 4.6.0, page loads have been taking several seconds, which I attributed to the fact that it's an old computer and I'm multi-tasking like crazy. I implemented my own suggestion, and now pages load in about one second, it makes an incredible difference (FWIW, my url_alias table has over 4000 rows). Patches attached, go give it a try... ------------------------------------------------------------------------ May 5, 2005 - 04:02 : mikeryan Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes) One attachment per note, that's tedious... ------------------------------------------------------------------------ May 5, 2005 - 04:03 : mikeryan Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB) ------------------------------------------------------------------------ May 5, 2005 - 04:03 : mikeryan Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes) ------------------------------------------------------------------------ May 5, 2005 - 04:04 : mikeryan Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes) ------------------------------------------------------------------------ May 5, 2005 - 04:07 : mikeryan Note: I just noticed that the database.*sql patches showed an extra diff (not mine) to the location field in locales_source. I did my diffs against a freshly-updated DRUPAL-4-6, and had made the edits against a release from a few days ago... Those locales_source changes should probably be removed from my patches before applying. ------------------------------------------------------------------------ May 8, 2005 - 01:13 : mikeryan I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these patches. Performance is very noticeably improved. [2] http://fenway-views.com/ ------------------------------------------------------------------------ May 8, 2005 - 15:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB) I've merged the patch into one. Much more convenient. I also changed it to cvs as only there new features will be added. Upgrade path needs to be added. Mike, can you run some more tests? We are especially interested in "hard" data ie numbers with possibly error bars. it would be interesting to know how this patch affects sites that have only a few path aliases vs those with a lot of them. Also, how pages with a lot of node links (tracker) are affected. It might be worthwhile to add static caching in drupal_get_normal_path if it gets calle dmore than once for a link on one page view. ------------------------------------------------------------------------ May 8, 2005 - 19:21 : mikeryan Thanks for merging the patches, I wasn't aware you could patch multiple files at once. If this is accepted, of course, adding the index on src should be incorporated into updates.inc. In terms of hard data, I've never profiled PHP code - what tool(s) do you use? I couldn't find anything referenced in the PHP manual... re: pages with lots of links - on Fenway Views the big test is the calendar [3], and the performance improvement seems even more dramatic here. I don't know why - the url_alias table is read once per page, so I would expect as you do that preloading the table would tend to look better when you have a hundred internal links on the page. Maybe we're both underestimating exactly how fast a simple MySQL query on an indexed key can be (I'm using MySQL 4.0.20, BTW)... [3] http://fenway-views.com/calendar ------------------------------------------------------------------------ May 8, 2005 - 19:26 : killes(a)www.drop.org As we speak, Mathias is doing some tests. The tool of choice is usually apache bench. If you have a lot of url aliases, the generated array will be huge. Part of the improvement could be due to the fact that you need less memory now. ------------------------------------------------------------------------ May 8, 2005 - 19:28 : mikeryan Great, thanks! ------------------------------------------------------------------------ May 8, 2005 - 19:34 : Dries On drupal.org it takes 800 ms or more to generate a page. Of these 800 ms, only 4 ms is spent building the path alias map (incl. the SQL query time which takes about 1 ms). That is, building the map takes 0.5% of the total time which is neglible. In our url_alias table are only 321 aliases though. How many aliases do you have? What is more, when we build drupal.org's main page, we query this map 215 times. I believe your patch would introduce 215 SQL queries ... I'm afraid that if we'd apply your patch, we'd pay a serious performance penalty (unless we have many more aliases). Can you provide some numbers/measurements? ------------------------------------------------------------------------ May 8, 2005 - 19:37 : Dries Note: my measurements did not take into account the time spent searching the map. On the main page, we search this array 215 times. ------------------------------------------------------------------------ May 8, 2005 - 20:08 : puregin I believe that it's felt that adding path aliases would improve the Drupal documentation. This may well add 400+ paths to the URL aliases table on Drupal.org ------------------------------------------------------------------------ May 8, 2005 - 20:27 : Dries I spent some more time investigating this. The relevant code in bootstrap.inc is this: function drupal_get_path_alias($path) { if (($map = drupal_get_path_map()) && ($newpath = array_search($path, $map))) { return $newpath; } ... Turns out that the time to build the map is neglible (< 5ms, see previous comments), however the total time spent on 'path aliasing' it about 70ms per page! 50ms of these 70ms are spent on $map = drupal_get_path_map(). The remaining 20ms is spent on $newpath = array_search($path, $map). The first call to drupal_get_path_map() takes 3 to 5 ms, each subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms. However, if you have to do this 130+ times, this adds up to a whopping 70 ms. Remind that we have 321 aliases in our map. As drupal_get_path_alias() is typically called from code>url(), which in turn is typically called from l() I set out to investigate the time spent in l(). Looks like l() easily gets called 120 times/page, and that each call to l() costs about 0.9 ms. That is about 2 or 3 times the cost of the /average SQL query/. The total time spent in l() is 115 ms! ------------------------------------------------------------------------ May 9, 2005 - 00:25 : adrian This is a complete aside, and probably off-topic, but I would like to mention that I was actually looking at rewriting url() to be able to handle 'external urls' , because I want to do aliases using the site subdomain, like for instance : http://category.sitename.com/article/title_goes_here -> node/23 Rewriting url to allow this would also allow us to use l() for external links of any kind, getting rid of a bunch of inline html. ------------------------------------------------------------------------ May 9, 2005 - 00:46 : chx adrian, I have written a patch for l to support external links but Ber said that a module like weblink shall handle those. ------------------------------------------------------------------------ May 9, 2005 - 01:03 : mikeryan I've got over 4000 aliases on Fenway Views - another pathauto user reported over 6000. I don't have a profiling tool to give timing data, but adding a quick counter shows that for the Fenway Views calendar [4], drupal_get_path_alias() is called 404 times and drupal_get_normal_path is called 227 times. And trust me, this page loads MUCH faster with my patch than it does with the path map. I think those SQL queries are a lot cheaper than one might expect... [4] http://fenway-views.com/calendar ------------------------------------------------------------------------ May 9, 2005 - 06:24 : mathias Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB) Some benchmarks, with MySQL and Drupal caching disabled. 2 SETS OF TESTS ======================================= 1) 500 nodes and aliases 2) 20,000 nodes and aliases 3 TYPES OF TESTS PER SET ======================================= 1) Baseline unmodified Drupal 2) The following change inside drupal_get_path_map(): - if (is_null($map)) { + if ($map === NULL) { $map = array(); // Make $map non-null in case no aliases are defined. 3) Pull aliases only when needed rather than loading the entire alias table. SET 1 - 500 Nodes and 500 Aliases using: ab -c 10 -n 100 [homepage] ======================================= Baseline Time taken for tests: 13.00 seconds Requests per second: 3.85 [#/sec] (mean) Transfer rate: 56.35 [Kbytes/sec] received is_null() VS NULL Time taken for tests: 12.463 seconds Requests per second: 4.01 [#/sec] (mean) Transfer rate: 57.63 [Kbytes/sec] received Per Instance Alias Lookup (32 additional queries) Time taken for tests: 11.502 seconds Requests per second: 4.35 [#/sec] (mean) Transfer rate: 63.30 [Kbytes/sec] received SET 2 - 20,000 Nodes and 20,000 Aliases using: ab -c 5 -n 50 [homepage] ======================================= Baseline Time taken for tests: 204.583 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received is_null() VS NULL Time taken for tests: 127.629 seconds Requests per second: 0.39 [#/sec] (mean) Transfer rate: 5.35 [Kbytes/sec] received Per Instance Alias Lookup (32 additional queries) Time taken for tests: 28.788 seconds Requests per second: 1.74 [#/sec] (mean) Transfer rate: 23.59 [Kbytes/sec] received ANALYSIS ======================================= Converting 'is_null()' to '=== NULL' is a no brainer and results in a nice performance gain. And while per instance alias lookups also give a huge boost for site with thousands of aliases, they're benefits are entirely dependent on the number of system URLs and menu items visible per request. As noted above I tested the standard homepage which added 32 additional queries. A request for something like the admin interface would presumably show less benefits. I would've tested this, but I didn't know how to invoke an authenticated page request with 'ab'. A positive of this approach is we no longer would be storing all the aliases in memory. What other concerns do we have with this last approach? Am I properly testing the strain on the database? ------------------------------------------------------------------------ May 9, 2005 - 07:08 : Dries Can you try making the following changes? 1. To common.inc: function drupal_rebuild_path_map() { - drupal_get_path_map('rebuild'); + drupal_get_path_map(TRUE); } 2. To bootstrap.inc: -function drupal_get_path_map($action = '') { +function drupal_get_path_map($rebuild = FALSE) { static $map = NULL; - if ($action == 'rebuild') { + if ($rebuild) { $map = NULL; } That is, replace the string comparison with a boolean comparison. Not sure it is going to make a significant difference but it might be another micro-improvement. I'll test your patch shortly. ------------------------------------------------------------------------ May 9, 2005 - 14:21 : mathias Dries. Those changes had no real performance gain. 20,000 Nodes and 20,000 Aliases using: ab -c 5 -n 50 [homepage] ======================================= Baseline Time taken for tests: 204.583 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received String VS Boolean Time taken for tests: 204.190 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received ------------------------------------------------------------------------ May 9, 2005 - 15:01 : Dries Before this patch can be committed, we need to do more testing. I'd like to know how this behaves on sites with few or no path aliases, and on sites like drupal.org, with a modest amount of path aliases. The reason I'm asking is because MySQL is often the bottleneck and not PHP/Apache. This is the case on drupal.org, for example. The proposed patch moves some of the processing costs from PHP to MySQL. On drupal.org, the amount of SQL queries/page would double. Needless to say, this is somewhat scary. ;) More numbers would be appreciated. ------------------------------------------------------------------------ May 10, 2005 - 04:56 : mikeryan I'm curious, why test with MySQL caching disabled? Since much of the issue is the expense of making (potentially many) more queries, this wouldn't seem to reflect the performance gain in practice. The caching (compared to making the query each time) seems like overkill to me - with MySQL caching enabled, I would think this complicates the code for little (if any) performance gain. Did you do any profiling using my original (cacheless) patch? Thanks. ------------------------------------------------------------------------ May 10, 2005 - 07:23 : mathias In an ideal world everyone would be running a query cache but I wanted to see how this would hold up under the worst-case scenario. I tested the original patch which didn't use static variables and the amount of queries doubled. For example, to load the front page, Drupal queried the url_alias table 22 times looking for an alias for 'node'. There's no need to send duplicate queries to the DB since it seems that's where most bottlenecks seem to lie. ------------------------------------------------------------------------ May 11, 2005 - 00:41 : mikeryan re: worst-case scenario - I understand that. re: # queries - I would not want to assume adding to the number of queries is necessarily a significant performance hit (with database caching on, of course). I understand the suspicion - I've been around long enough to remember when you did everything you could to avoid making one single SQL query more than you absolutely had to. But modern databases (including MySQL) are very well optimized for this kind of application (lots and lots of small queries). And, I have seen real-life cases where adding caching of data that's already being cached somewhere upstream actually degrades performance. As long as we're examining this particular area of performance under a microscope, let's make sure we squeeze every millisecond of savings we can out of it - I'd just like to see the numbers for a cached database/no Drupal caching combination for comparison. Thanks. ------------------------------------------------------------------------ May 11, 2005 - 07:12 : mathias Dries asked me to do some tests using the drupal.org database. Once again it appears that plucking aliases out of the database as needed performed better than grabbing the entire alias table at the beginning of the request lifecycle, even if the alias table is small. Here's the numbers. using: ab -c 5 -n 50 [homepage] Drupal.org Baseline ============= Time taken for tests: 18.081 seconds Requests per second: 2.77 [#/sec] (mean) Transfer rate: 52.69 [Kbytes/sec] received 1 page request was 83 queries in 60ms for a cycle execution time of 255ms Drupal.org Per Instance Query ================== Time taken for tests: 16.536 seconds Requests per second: 3.02 [#/sec] (mean) Transfer rate: 56.63 [Kbytes/sec] received 1 page request was 125 queries in 65ms for a cycle execution time of 230ms Notice that the database does work a little harder to retrieve the queries one by one. And it also doesn't make sense to run 40 extra queries on a site with only 50 aliases. I think at this point we have a couple of options to explore: 1. Continue to try and squeeze out any other optimizations we can in the original path aliasing code. Maybe look at output buffering or a mechnism that'll allow us to start working the database resultset as soon data is fed into the pipe rather than waiting for the request to finish. 2. Try to identify the point (e.g., the number aliases) at which it becomes more effecient to fetch aliases and change patterns on the fly. As with most optimizations, the end result will probably be a combination of both. ------------------------------------------------------------------------ May 11, 2005 - 07:59 : Dries Looks like in all cases, performance actually improves. I've run a couple tests myself using the drupal.org database and measured performance improvements up to 15%. Of course, this was done on a machine where the MySQL database wasn't hammered on by 50+ concurrent requests. It would be appreciated if you could extend your patch with a couple lines of documentation to document the behavior (so people understand why we are doing it this way), the code and the API. Maybe add an entry to CHANGELOG.txt? Do we need an update for updates.inc? As for future work, I think we're better off looking at l(). As said, one call to l() takes about 0.9 ms and we easily do 100+ such calls per page. Caching at the level of l() is likely to buy us more but I don't know whether it is feasible. Maybe we can think of other optimizations too. If anything, it might be a good idea to add a TODO/NOTE to the PHPdoc of l(). Or, if you feel like messing with l() first, by all means! Count me in -- it's fun. :-) ------------------------------------------------------------------------ May 12, 2005 - 04:29 : mathias Attachment: http://drupal.org/files/issues/alias-query-on-demand.patch (5.72 KB) I think this patch is now commit-worthy. I did some more profiling using xdebug 2.0 [5] and kcachegrind [6] and sure enough, drupal_get_path_map() was a resource hog on sites with many aliases. This should be quite an improvement. I also found a couple other small optimizations such as replacing array_key_exists() with a NULL check inside the arg() function (before [7] / after [8]) and calling isset() in order to avoid calls to error_handler. [5] http://xdebug.org [6] http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindIndex [7] http://www.asitis.org/tmp/before_arg.png [8] http://www.asitis.org/tmp/after_arg.png ------------------------------------------------------------------------ May 12, 2005 - 10:07 : Dries That last patch doens't seem to work. None of my URLs are being substituted by their path alias. Also, mind to rename the src action to source? ------------------------------------------------------------------------ May 12, 2005 - 21:00 : mathias Attachment: http://drupal.org/files/issues/alias-query-on-demand_0.patch (7.5 KB) Doh! The previous version only worked when the path module was enabled. Here's a new one that works independent of path module. It's also a little faster now. 20,000 node and aliases: without patch: 0.24 requests per second with patch: 1.87 requests per second (was 1.74) The gains on drupal_org and sites with under 400 or so aliases is small. Actually those sites will spend more time in the DB and less time churning through PHP code. Further optimizations could be made here by defaulting to the old method of grabbing all aliases and looking for further PHP optimizations. Should we look into this or is that overkill?

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by nedjo 12 May '05

12 May '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: nedjo Status: patch 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. nedjo Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 06: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 14, 2005 - 21:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 16, 2005 - 20: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 16, 2005 - 21: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 16, 2005 - 22: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 - 00: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 - 03: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 - 17: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 - 17: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 - 17:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 18: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 17, 2005 - 22: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 17, 2005 - 22: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 - 03: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 - 04: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 - 04: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 - 11: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 - 17: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 - 17: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 - 17: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 - 12: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 - 12: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 - 13:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 13: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 - 14: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 - 14: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 - 17: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 - 18: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 - 18: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 - 18: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 - 04: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 - 05: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 - 05:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 13: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 - 14: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 - 12: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 - 16: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 - 16: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 - 16:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 16: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 - 18: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 9, 2005 - 21: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 9, 2005 - 22: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 - 00: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 - 01: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 - 01: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 - 05: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 - 10: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 - 12: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 - 14: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 - 15: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 - 15: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.

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by chx 12 May '05

12 May '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: chx Status: patch 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. chx 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

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by nedjo 12 May '05

12 May '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: nedjo Status: patch 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 nedjo Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 06: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 14, 2005 - 21:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 16, 2005 - 20: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 16, 2005 - 21: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 16, 2005 - 22: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 - 00: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 - 03: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 - 17: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 - 17: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 - 17:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 18: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 17, 2005 - 22: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 17, 2005 - 22: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 - 03: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 - 04: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 - 04: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 - 11: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 - 17: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 - 17: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 - 17: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 - 12: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 - 12: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 - 13:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 13: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 - 14: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 - 14: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 - 17: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 - 18: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 - 18: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 - 18: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 - 04: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 - 05: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 - 05:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 13: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 - 14: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 - 12: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 - 16: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 - 16: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 - 16:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 16: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 - 18: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 9, 2005 - 21: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 9, 2005 - 22: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 - 00: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 - 01: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 - 01: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 - 05: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 - 10: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 - 12: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 - 14: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.

1 0

[drupal-devel] [task] Performance issues with path aliases
by mathias 12 May '05

12 May '05

Issue status update for http://drupal.org/node/22035 Project: Drupal Version: cvs Component: base system Category: tasks Priority: normal Assigned to: mathias Reported by: mikeryan Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/alias-query-on-demand_0.patch (7.5 KB) Doh! The previous version only worked when the path module was enabled. Here's a new one that works independent of path module. It's also a little faster now. 20,000 node and aliases: without patch: 0.24 requests per second with patch: 1.87 requests per second (was 1.74) The gains on drupal_org and sites with under 400 or so aliases is small. Actually those sites will spend more time in the DB and less time churning through PHP code. Further optimizations could be made here by defaulting to the old method of grabbing all aliases and looking for further PHP optimizations. Should we look into this or is that overkill? mathias Previous comments: ------------------------------------------------------------------------ May 4, 2005 - 19:10 : mikeryan See Investigate use of conf_url_rewrite [1] for context... The current core support for translating incoming path aliases to the internal Drupal path (drupal_get_path_alias) and substituting aliases when generating links to internal paths (drupal_get_normal_path) does not scale well with many aliases. The ease with which pathauto enables site administrators to generate large numbers of aliases exposes this issue, but it is inherent in the core implementation, because drupal_get_path_map reads in the entire url_alias table at bootstrap time. I'd like to discuss ideas on how to improve the performance... Most obviously, why not simply query the url_alias table as needed instead of loading the whole table? In the incoming case, only a single simple SELECT is necessary, which will always be more efficient than reading the table. In the outgoing case, there might be some slight performance advantage to caching the table with a small number of aliases, but the disadvantage can become huge as the alias table grows. One note - I've noticed that the src column in url_alias is not indexed, I think adding an index should significantly help the performance in the outgoing case if we were to do individual SELECTs. Any other thoughts? [1] http://drupal.org/node/21938 ------------------------------------------------------------------------ May 4, 2005 - 20:02 : mikeryan Attachment: http://drupal.org/files/issues/bootstrap.inc_2.patch (1.06 KB) What the hell, I went ahead and gave it a shot... On my home system, where I'm testing out 4.6.0, page loads have been taking several seconds, which I attributed to the fact that it's an old computer and I'm multi-tasking like crazy. I implemented my own suggestion, and now pages load in about one second, it makes an incredible difference (FWIW, my url_alias table has over 4000 rows). Patches attached, go give it a try... ------------------------------------------------------------------------ May 4, 2005 - 20:02 : mikeryan Attachment: http://drupal.org/files/issues/common.inc_11.patch (723 bytes) One attachment per note, that's tedious... ------------------------------------------------------------------------ May 4, 2005 - 20:03 : mikeryan Attachment: http://drupal.org/files/issues/path.module_0.patch (1.34 KB) ------------------------------------------------------------------------ May 4, 2005 - 20:03 : mikeryan Attachment: http://drupal.org/files/issues/database.mysql_4.patch (553 bytes) ------------------------------------------------------------------------ May 4, 2005 - 20:04 : mikeryan Attachment: http://drupal.org/files/issues/database.pgsql_2.patch (502 bytes) ------------------------------------------------------------------------ May 4, 2005 - 20:07 : mikeryan Note: I just noticed that the database.*sql patches showed an extra diff (not mine) to the location field in locales_source. I did my diffs against a freshly-updated DRUPAL-4-6, and had made the edits against a release from a few days ago... Those locales_source changes should probably be removed from my patches before applying. ------------------------------------------------------------------------ May 7, 2005 - 17:13 : mikeryan I upgraded Fenway Views [2] to Drupal 4.6.0 today, incorporating these patches. Performance is very noticeably improved. [2] http://fenway-views.com/ ------------------------------------------------------------------------ May 8, 2005 - 07:31 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/pathalias.patch (4.98 KB) I've merged the patch into one. Much more convenient. I also changed it to cvs as only there new features will be added. Upgrade path needs to be added. Mike, can you run some more tests? We are especially interested in "hard" data ie numbers with possibly error bars. it would be interesting to know how this patch affects sites that have only a few path aliases vs those with a lot of them. Also, how pages with a lot of node links (tracker) are affected. It might be worthwhile to add static caching in drupal_get_normal_path if it gets calle dmore than once for a link on one page view. ------------------------------------------------------------------------ May 8, 2005 - 11:21 : mikeryan Thanks for merging the patches, I wasn't aware you could patch multiple files at once. If this is accepted, of course, adding the index on src should be incorporated into updates.inc. In terms of hard data, I've never profiled PHP code - what tool(s) do you use? I couldn't find anything referenced in the PHP manual... re: pages with lots of links - on Fenway Views the big test is the calendar [3], and the performance improvement seems even more dramatic here. I don't know why - the url_alias table is read once per page, so I would expect as you do that preloading the table would tend to look better when you have a hundred internal links on the page. Maybe we're both underestimating exactly how fast a simple MySQL query on an indexed key can be (I'm using MySQL 4.0.20, BTW)... [3] http://fenway-views.com/calendar ------------------------------------------------------------------------ May 8, 2005 - 11:26 : killes(a)www.drop.org As we speak, Mathias is doing some tests. The tool of choice is usually apache bench. If you have a lot of url aliases, the generated array will be huge. Part of the improvement could be due to the fact that you need less memory now. ------------------------------------------------------------------------ May 8, 2005 - 11:28 : mikeryan Great, thanks! ------------------------------------------------------------------------ May 8, 2005 - 11:34 : Dries On drupal.org it takes 800 ms or more to generate a page. Of these 800 ms, only 4 ms is spent building the path alias map (incl. the SQL query time which takes about 1 ms). That is, building the map takes 0.5% of the total time which is neglible. In our url_alias table are only 321 aliases though. How many aliases do you have? What is more, when we build drupal.org's main page, we query this map 215 times. I believe your patch would introduce 215 SQL queries ... I'm afraid that if we'd apply your patch, we'd pay a serious performance penalty (unless we have many more aliases). Can you provide some numbers/measurements? ------------------------------------------------------------------------ May 8, 2005 - 11:37 : Dries Note: my measurements did not take into account the time spent searching the map. On the main page, we search this array 215 times. ------------------------------------------------------------------------ May 8, 2005 - 12:08 : puregin I believe that it's felt that adding path aliases would improve the Drupal documentation. This may well add 400+ paths to the URL aliases table on Drupal.org ------------------------------------------------------------------------ May 8, 2005 - 12:27 : Dries I spent some more time investigating this. The relevant code in bootstrap.inc is this: function drupal_get_path_alias($path) { if (($map = drupal_get_path_map()) && ($newpath = array_search($path, $map))) { return $newpath; } ... Turns out that the time to build the map is neglible (< 5ms, see previous comments), however the total time spent on 'path aliasing' it about 70ms per page! 50ms of these 70ms are spent on $map = drupal_get_path_map(). The remaining 20ms is spent on $newpath = array_search($path, $map). The first call to drupal_get_path_map() takes 3 to 5 ms, each subsequent call takes about 0.3 ms. Searching the array costs 0.1 ms. However, if you have to do this 130+ times, this adds up to a whopping 70 ms. Remind that we have 321 aliases in our map. As drupal_get_path_alias() is typically called from code>url(), which in turn is typically called from l() I set out to investigate the time spent in l(). Looks like l() easily gets called 120 times/page, and that each call to l() costs about 0.9 ms. That is about 2 or 3 times the cost of the /average SQL query/. The total time spent in l() is 115 ms! ------------------------------------------------------------------------ May 8, 2005 - 16:25 : adrian This is a complete aside, and probably off-topic, but I would like to mention that I was actually looking at rewriting url() to be able to handle 'external urls' , because I want to do aliases using the site subdomain, like for instance : http://category.sitename.com/article/title_goes_here -> node/23 Rewriting url to allow this would also allow us to use l() for external links of any kind, getting rid of a bunch of inline html. ------------------------------------------------------------------------ May 8, 2005 - 16:46 : chx adrian, I have written a patch for l to support external links but Ber said that a module like weblink shall handle those. ------------------------------------------------------------------------ May 8, 2005 - 17:03 : mikeryan I've got over 4000 aliases on Fenway Views - another pathauto user reported over 6000. I don't have a profiling tool to give timing data, but adding a quick counter shows that for the Fenway Views calendar [4], drupal_get_path_alias() is called 404 times and drupal_get_normal_path is called 227 times. And trust me, this page loads MUCH faster with my patch than it does with the path map. I think those SQL queries are a lot cheaper than one might expect... [4] http://fenway-views.com/calendar ------------------------------------------------------------------------ May 8, 2005 - 22:24 : mathias Attachment: http://drupal.org/files/issues/pathalias-with-caching.patch (5.62 KB) Some benchmarks, with MySQL and Drupal caching disabled. 2 SETS OF TESTS ======================================= 1) 500 nodes and aliases 2) 20,000 nodes and aliases 3 TYPES OF TESTS PER SET ======================================= 1) Baseline unmodified Drupal 2) The following change inside drupal_get_path_map(): - if (is_null($map)) { + if ($map === NULL) { $map = array(); // Make $map non-null in case no aliases are defined. 3) Pull aliases only when needed rather than loading the entire alias table. SET 1 - 500 Nodes and 500 Aliases using: ab -c 10 -n 100 [homepage] ======================================= Baseline Time taken for tests: 13.00 seconds Requests per second: 3.85 [#/sec] (mean) Transfer rate: 56.35 [Kbytes/sec] received is_null() VS NULL Time taken for tests: 12.463 seconds Requests per second: 4.01 [#/sec] (mean) Transfer rate: 57.63 [Kbytes/sec] received Per Instance Alias Lookup (32 additional queries) Time taken for tests: 11.502 seconds Requests per second: 4.35 [#/sec] (mean) Transfer rate: 63.30 [Kbytes/sec] received SET 2 - 20,000 Nodes and 20,000 Aliases using: ab -c 5 -n 50 [homepage] ======================================= Baseline Time taken for tests: 204.583 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received is_null() VS NULL Time taken for tests: 127.629 seconds Requests per second: 0.39 [#/sec] (mean) Transfer rate: 5.35 [Kbytes/sec] received Per Instance Alias Lookup (32 additional queries) Time taken for tests: 28.788 seconds Requests per second: 1.74 [#/sec] (mean) Transfer rate: 23.59 [Kbytes/sec] received ANALYSIS ======================================= Converting 'is_null()' to '=== NULL' is a no brainer and results in a nice performance gain. And while per instance alias lookups also give a huge boost for site with thousands of aliases, they're benefits are entirely dependent on the number of system URLs and menu items visible per request. As noted above I tested the standard homepage which added 32 additional queries. A request for something like the admin interface would presumably show less benefits. I would've tested this, but I didn't know how to invoke an authenticated page request with 'ab'. A positive of this approach is we no longer would be storing all the aliases in memory. What other concerns do we have with this last approach? Am I properly testing the strain on the database? ------------------------------------------------------------------------ May 8, 2005 - 23:08 : Dries Can you try making the following changes? 1. To common.inc: function drupal_rebuild_path_map() { - drupal_get_path_map('rebuild'); + drupal_get_path_map(TRUE); } 2. To bootstrap.inc: -function drupal_get_path_map($action = '') { +function drupal_get_path_map($rebuild = FALSE) { static $map = NULL; - if ($action == 'rebuild') { + if ($rebuild) { $map = NULL; } That is, replace the string comparison with a boolean comparison. Not sure it is going to make a significant difference but it might be another micro-improvement. I'll test your patch shortly. ------------------------------------------------------------------------ May 9, 2005 - 06:21 : mathias Dries. Those changes had no real performance gain. 20,000 Nodes and 20,000 Aliases using: ab -c 5 -n 50 [homepage] ======================================= Baseline Time taken for tests: 204.583 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received String VS Boolean Time taken for tests: 204.190 seconds Requests per second: 0.24 [#/sec] (mean) Transfer rate: 3.34 [Kbytes/sec] received ------------------------------------------------------------------------ May 9, 2005 - 07:01 : Dries Before this patch can be committed, we need to do more testing. I'd like to know how this behaves on sites with few or no path aliases, and on sites like drupal.org, with a modest amount of path aliases. The reason I'm asking is because MySQL is often the bottleneck and not PHP/Apache. This is the case on drupal.org, for example. The proposed patch moves some of the processing costs from PHP to MySQL. On drupal.org, the amount of SQL queries/page would double. Needless to say, this is somewhat scary. ;) More numbers would be appreciated. ------------------------------------------------------------------------ May 9, 2005 - 20:56 : mikeryan I'm curious, why test with MySQL caching disabled? Since much of the issue is the expense of making (potentially many) more queries, this wouldn't seem to reflect the performance gain in practice. The caching (compared to making the query each time) seems like overkill to me - with MySQL caching enabled, I would think this complicates the code for little (if any) performance gain. Did you do any profiling using my original (cacheless) patch? Thanks. ------------------------------------------------------------------------ May 9, 2005 - 23:23 : mathias In an ideal world everyone would be running a query cache but I wanted to see how this would hold up under the worst-case scenario. I tested the original patch which didn't use static variables and the amount of queries doubled. For example, to load the front page, Drupal queried the url_alias table 22 times looking for an alias for 'node'. There's no need to send duplicate queries to the DB since it seems that's where most bottlenecks seem to lie. ------------------------------------------------------------------------ May 10, 2005 - 16:41 : mikeryan re: worst-case scenario - I understand that. re: # queries - I would not want to assume adding to the number of queries is necessarily a significant performance hit (with database caching on, of course). I understand the suspicion - I've been around long enough to remember when you did everything you could to avoid making one single SQL query more than you absolutely had to. But modern databases (including MySQL) are very well optimized for this kind of application (lots and lots of small queries). And, I have seen real-life cases where adding caching of data that's already being cached somewhere upstream actually degrades performance. As long as we're examining this particular area of performance under a microscope, let's make sure we squeeze every millisecond of savings we can out of it - I'd just like to see the numbers for a cached database/no Drupal caching combination for comparison. Thanks. ------------------------------------------------------------------------ May 10, 2005 - 23:12 : mathias Dries asked me to do some tests using the drupal.org database. Once again it appears that plucking aliases out of the database as needed performed better than grabbing the entire alias table at the beginning of the request lifecycle, even if the alias table is small. Here's the numbers. using: ab -c 5 -n 50 [homepage] Drupal.org Baseline ============= Time taken for tests: 18.081 seconds Requests per second: 2.77 [#/sec] (mean) Transfer rate: 52.69 [Kbytes/sec] received 1 page request was 83 queries in 60ms for a cycle execution time of 255ms Drupal.org Per Instance Query ================== Time taken for tests: 16.536 seconds Requests per second: 3.02 [#/sec] (mean) Transfer rate: 56.63 [Kbytes/sec] received 1 page request was 125 queries in 65ms for a cycle execution time of 230ms Notice that the database does work a little harder to retrieve the queries one by one. And it also doesn't make sense to run 40 extra queries on a site with only 50 aliases. I think at this point we have a couple of options to explore: 1. Continue to try and squeeze out any other optimizations we can in the original path aliasing code. Maybe look at output buffering or a mechnism that'll allow us to start working the database resultset as soon data is fed into the pipe rather than waiting for the request to finish. 2. Try to identify the point (e.g., the number aliases) at which it becomes more effecient to fetch aliases and change patterns on the fly. As with most optimizations, the end result will probably be a combination of both. ------------------------------------------------------------------------ May 10, 2005 - 23:59 : Dries Looks like in all cases, performance actually improves. I've run a couple tests myself using the drupal.org database and measured performance improvements up to 15%. Of course, this was done on a machine where the MySQL database wasn't hammered on by 50+ concurrent requests. It would be appreciated if you could extend your patch with a couple lines of documentation to document the behavior (so people understand why we are doing it this way), the code and the API. Maybe add an entry to CHANGELOG.txt? Do we need an update for updates.inc? As for future work, I think we're better off looking at l(). As said, one call to l() takes about 0.9 ms and we easily do 100+ such calls per page. Caching at the level of l() is likely to buy us more but I don't know whether it is feasible. Maybe we can think of other optimizations too. If anything, it might be a good idea to add a TODO/NOTE to the PHPdoc of l(). Or, if you feel like messing with l() first, by all means! Count me in -- it's fun. :-) ------------------------------------------------------------------------ May 11, 2005 - 20:29 : mathias Attachment: http://drupal.org/files/issues/alias-query-on-demand.patch (5.72 KB) I think this patch is now commit-worthy. I did some more profiling using xdebug 2.0 [5] and kcachegrind [6] and sure enough, drupal_get_path_map() was a resource hog on sites with many aliases. This should be quite an improvement. I also found a couple other small optimizations such as replacing array_key_exists() with a NULL check inside the arg() function (before [7] / after [8]) and calling isset() in order to avoid calls to error_handler. [5] http://xdebug.org [6] http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindIndex [7] http://www.asitis.org/tmp/before_arg.png [8] http://www.asitis.org/tmp/after_arg.png ------------------------------------------------------------------------ May 12, 2005 - 02:07 : Dries That last patch doens't seem to work. None of my URLs are being substituted by their path alias. Also, mind to rename the src action to source?

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by Bèr Kessels 12 May '05

12 May '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: Bèr Kessels Status: patch 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. Bèr Kessels Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 11: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 - 02: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 - 01: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 - 02: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 - 03: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 - 05: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 - 08: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 - 22: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 - 22: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 - 22:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 23: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 - 03: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 - 03: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 - 08: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 - 09: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 - 09: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 - 16: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 - 22: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 - 22: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 - 22: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 - 17: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 - 17: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 - 18:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 18: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 - 19: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 - 19: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 - 22: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 - 23: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 - 23: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 - 23: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 - 09: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 - 10: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 - 10:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 18: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 - 19: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 - 17: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 - 21: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 - 21: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 - 21:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 21: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 - 23: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 - 02: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 - 03: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 - 05: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 - 06: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 - 06: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 - 10: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 - 15: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 - 17: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.

1 0

[drupal-devel] [feature] Enable multiple block regions (not just "left" and "right" sidebars)
by nedjo 12 May '05

12 May '05

Issue status update for http://drupal.org/node/16216 Project: Drupal Version: cvs Component: block.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: paragkenia Updated by: nedjo Status: patch 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. nedjo Previous comments: ------------------------------------------------------------------------ January 26, 2005 - 06: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 14, 2005 - 21:44 : nedjo This issue was apparently partially addressed in issue http://drupal.org/node/19694 [1]. [1] http://drupal.org/node/19694 ------------------------------------------------------------------------ April 16, 2005 - 20: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 16, 2005 - 21: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 16, 2005 - 22: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 - 00: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 - 03: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 - 17: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 - 17: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 - 17:19 : syscrusher s/them_regions/theme_regions/g ------------------------------------------------------------------------ April 17, 2005 - 18: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 17, 2005 - 22: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 17, 2005 - 22: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 - 03: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 - 04: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 - 04: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 - 11: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 - 17: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 - 17: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 - 17: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 - 12: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 - 12: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 - 13:19 : killes(a)www.drop.org I like that approach. +1 ------------------------------------------------------------------------ April 21, 2005 - 13: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 - 14: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 - 14: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 - 17: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 - 18: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 - 18: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 - 18: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 - 04: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 - 05: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 - 05:32 : stefan nagtegaal While I think that 'body_*' is not as self explaining as 'content_*' I vote for using 'content_*'.. ------------------------------------------------------------------------ April 25, 2005 - 13: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 - 14: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 - 12: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 - 16: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 - 16: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 - 16:47 : chx Ber, Dries, do not kill me! Ber chaired the usability meeting in Antwerp, that's all. ------------------------------------------------------------------------ May 9, 2005 - 16: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 - 18: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 9, 2005 - 21: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 9, 2005 - 22: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 - 00: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 - 01: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 - 01: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 - 05: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 - 10: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/

1 0

[drupal-devel] [bug] Failure to respect node status upon editing (reverts to default)
by r11r 12 May '05

12 May '05

Issue status update for http://drupal.org/node/7940 Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: mathias Reported by: mathias Updated by: r11r Status: patch Attachment: http://drupal.org/files/issues/fixoptions.module (1.98 KB) Instead of having to patch, I've made a module that I think accomplishes the same thing as the pathes using nodeapi. The "fixoptions" module. I suppose settings could be added to this module to optionally reset all options or only the comments option as per killes' comment. r11r Previous comments: ------------------------------------------------------------------------ May 20, 2004 - 22:00 : mathias How to recreate: 1. As admin, navigate to: administer » content » settings, and uncheck 'publish' for stories. 2. As admin, create a story and assign it to a user that can create and maintain their own stories, say this user's name is Mark. 3. Login as Mark and edit that story. 4. Instead of staying published, it reverts back to it's unpublished state. I think this behavior is a bug as these content settings are default settings and should only be applied during node creation (not editing). I know Drupal-contrib project owners get bitten with this everytime they edit their project pages. I'll work on a patch within the next day. ------------------------------------------------------------------------ May 21, 2004 - 10:59 : mathias Attachment: http://drupal.org/files/issues/node_defaults.patch (1.05 KB) Proposed solution: If a node is being updated: respect the following existing settings: 1. node status (published/unpublished) 2. node promotion (promoted on front page) 3. node static (static on front page) For any node, force the defaults for: 1. moderation 2. revisions With our current situation, say the admin makes 'promote to front page' and 'static on front page' the default settings for stories. Another user posts a story and bam! it's of course immediately visible. The admin decides he/she doesn't like that story and demotes it. Well as soon as that user edits his story, the default settings are re-assigned and his post is right back on the front page. ------------------------------------------------------------------------ August 3, 2004 - 14:38 : mathias Attachment: http://drupal.org/files/issues/node_defaults_0.patch (1.19 KB) When editing nodes, the following node properties should not be overwritten - node status (published/unpublished) - node promotion (promoted on front page) - node sticky (top of the list) Currently, if the author of a node doesn't have 'administer node' privileges, than the above settings will always revert to the default behavior of their node type group. This makes nodes disappear and node authors very very confused. ------------------------------------------------------------------------ August 3, 2004 - 14:56 : ccourtne Don't forget to take moderation into account. If a node is edited should it go back through moderation? Some sites may want the behavior of going back some sites may not. This is probably best as a toggle option on workflow default config screen. ------------------------------------------------------------------------ August 3, 2004 - 16:21 : mathias I don't think my patch interferes with the moderation features. If the default workflow for a type of nodes is set to 'moderate', than the moderation flag will always reset itself to 'moderation' upon editing. I did not alter this functionality. ------------------------------------------------------------------------ September 29, 2004 - 17:00 : mathias Attachment: http://drupal.org/files/issues/node_defaults_1.patch (1.64 KB) I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [1]' has been rolled into this as well. I'll take it out if need be. [1] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 29, 2004 - 17:00 : mathias I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [2]' has been rolled into this as well. I'll take it out if need be. [2] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 30, 2004 - 14:08 : Dries When someone edits a node that has been promoted, I do want to demote it from the main page. If not, the system is open for abuse. IMO, this is 'by design'. ------------------------------------------------------------------------ September 30, 2004 - 15:00 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administratr promotes it, next thing i can do is open it up and add loads of ugly spam to it. Buth are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:01 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:02 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:11 : Dries The first problem can be solved by blocking the user account, or by revoking the user's permissions. The second problem can probably be solved using the node-level permissions. Whenever I promote a post to the front page, I could revoke the user's edit rights. It would only work, if the modules don't by-pass the access rights, of course (I believe some do). ------------------------------------------------------------------------ October 3, 2004 - 16:28 : mathias Attachment: http://drupal.org/files/issues/node_defaults_2.patch (4.22 KB) Dries is right about using the power of node-level permissions for community editing. I think this patch would assist that goal. As it stands, node-level permissions don't work with community editing, at least in the sense we're used to. For one node_validate transfers ownership of the node to the current editing user which may not always be the author. This causes many problems since original authorship usually implies special privileges (e.g. 'edit own foo', delete). Second, sites have different trust levels for users. On some sites there's just a handful of trusted users that edit and maintain all the content. The current approach for community editing is to create a new role and give it the 'administer nodes' permission, which in my opinion makes the node form interface much more cluttered and gives users in that role full access to node properties. Full access is not always desired. Using a combination of node-level permissions and allowing a node to retain some or all of its options makes a clean, easy to use approach to maintainance. This new patch lets the admin control how node_validate handles node options during editing. It splits the default workflow screen into two parts: Creation settings, and Editing options. The creation settings is the default workflow we're all used to. The editing options allow the admin to say what happens to those node options when they are edited. I've created a node-level permissions module [3] based on JonBob's work that allows a user to choose which roles can view and/or edit their post. Unfortunately it needs this patch to allow node_validate to be a little less controlling. I'd like to contribute this module if it didn't need a patch. [3] http://www.asitis.org/tmp/ ------------------------------------------------------------------------ October 3, 2004 - 16:30 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content.png (22.39 KB) Screenshot of the new default 'node editing options' interface. ------------------------------------------------------------------------ October 4, 2004 - 10:16 : Bèr Kessels Mathias, First: using radio's for a Boolean is bad UI design IMO. It would be much better if you use checkboxes. Second: If you use radio's you can make the same matrix as above, for each node-type a reset foo flag. This will not only make the UI more consistent, but also improve usability by allowing per-node-type reset flag. Ber ------------------------------------------------------------------------ October 4, 2004 - 13:08 : Dries The settings GUI's help text is rather hard-core and will scare many user away. It will even frighten most Drupal developers. Also, I'm not sure I understood the screenshot correctly. The functionality introduced is much needed but the GUI and configuration parts needs work IMO. Keep working on it. ------------------------------------------------------------------------ October 14, 2004 - 16:55 : mathias Attachment: http://drupal.org/files/issues/node_defaults_3.patch (4.74 KB) As per Ber's feedback, I changed the interface to use checkboxes and allowed the reset flags to be set for each node-type. The result is a much more familiar and consistent experience. Dries: I revamped the help text, removing the scary bits and sticking to the bare essentials. The dialog concerning this patch has been excellent, and the result of which I feel is a sweet slice of code ready for core :) ------------------------------------------------------------------------ October 14, 2004 - 16:56 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content_0.png (18.68 KB) Latest screenshot of patch. ------------------------------------------------------------------------ October 28, 2004 - 15:08 : mathias Attachment: http://drupal.org/files/issues/node_defaults_4.patch (4.81 KB) Updated the help text to be slightly more descriptive, informing the reader that: Users with "administer nodes" permission can override the editing options. ------------------------------------------------------------------------ October 28, 2004 - 18:51 : Steven I'm not sure I like that admin interface. My brain tries to correlate the two tables, but the meanings are different (what is the value, keep the value?). Maybe it would be better just to have one checkbox per node type to allow you to either revert the published/frontpage/moderate/sticky fields on editing, or not. This should cover 99% of all use cases with an admin interface that is much easier to understand. ------------------------------------------------------------------------ October 30, 2004 - 14:29 : mathias Attachment: http://drupal.org/files/issues/node_defaults_5.patch (5.06 KB) It provides a consistant look and feel if the creation settings are the same as the editing settings since they both manipulate the same components of a node and you're just toggling states based on different actions. I think it is a bad idea to only give site admins an 'all or none' approach to override node options upon editing. Here are some examples why: - You want nodes to remember their 'sticky' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember their 'promote to front page' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember all their settings except moderation. The node is still published, but it goes into the queue to be rated again since the content has changed. - By default nodes are unpublished. Once it's been tagged as published it stays that way. Perhaps the moderation tag is reset. I've updated the code to hopefully make things even more clearer. Here's the latest screenshot [4]. [4] http://asitis.org/tmp/node_defaults_admin_content_1.png ------------------------------------------------------------------------ January 24, 2005 - 11:41 : moshe weitzman this patch fixes a fairly undesirable problem with our workflow. lets consider it along with other proposed changes to default workflow. ------------------------------------------------------------------------ March 13, 2005 - 17:04 : killes(a)www.drop.org Does not apply anymore. ------------------------------------------------------------------------ April 12, 2005 - 14:07 : r11r I'm still experiencing this problem with latest CVS (head and drupal-4-6) and in addition to the publishing options (Published, Promoted to front page, etc), it also affects the settings for comments. When a user edits the page, the settings revert to the default value for that content type, instead of what is currently set for the specific node. Example of this problem with respect to Comments: ( Create a user with permissions to edit own pages, but not administer comments. ) 1. user creates page (comments default to read/write) 2. admin edits page and turns off comments 3. user edits page and saves 4. comments are reset to read/write Help :) (Am willing to assist in fixing this if necessary) ------------------------------------------------------------------------ April 12, 2005 - 14:31 : killes(a)www.drop.org Ok, just some remarks from irc: 21:23 < killes> r11r: After looking a bit more at the code I think it is more of a feature request than a bug. 21:23 < killes> Not that I would mind some more flexibility, of course. 21:24 < r11r> killes: well, node settings magically resetting themselves could be considered a bug.. hehe 21:25 < killes> Well, it is not magically, it is "by design". ;) 21:25 < killes> i don't think we will get that into 4.6. But I woul dwork with you to get it into 4.7. 21:27 < killes> This needs to be part of a more general improved workflow thingie. 21:27 < killes> Did you try clousseau's workflow module? it is amazing. ------------------------------------------------------------------------ April 13, 2005 - 08:59 : r11r Haven't yet looked at workflow, but this issue can be fixed by simply unsetting the node properties for which the user doing the edit does not have permissions. i.e. in node.module (around line 1255) if (!$node->nid): -- load defaults from database settings else: -- unset node->status, moderate, promote, sticky, revision, created also in comment.module (around line 247, the nodeapi hooks) if (!user_access('administer nodes')): -- unset node->comment Because any properties that are not set in the node object do not get passed into the update sql statement, the node will retain its previous values after being edited by a user instead of reverting to the default values for the content-type. Can anyone think of problems with this approach for the time being? ------------------------------------------------------------------------ April 13, 2005 - 11:52 : r11r Change in comment.module, line 257 for head and 4.6, line 254 for 4.5. case 'validate': if (!user_access('administer nodes')) { if (!$node->nid) { // Force default for normal users: $node->comment = variable_get("comment_$node->type", 2); } else { // If the node is being updated, respect its previous settings unset($node->comment); } } break; ------------------------------------------------------------------------ April 13, 2005 - 12:02 : r11r Didn't really mean to change the title! ------------------------------------------------------------------------ April 13, 2005 - 12:05 : r11r Change in node.module, for head and 4.6, around line 1258 $node_options = variable_get('node_options_'. $node->type, array('status', 'promote')); if (!$node->nid) { // Force defaults in case people modify the form: $node->status = in_array('status', $node_options); $node->moderate = in_array('moderate', $node_options); $node->promote = in_array('promote', $node_options); $node->sticky = in_array('sticky', $node_options); } else { // If the node is being updated, respect is previous settings unset($node->status); unset($node->moderate); unset($node->promote); unset($node->sticky); } $node->revision = in_array('revision', $node_options); unset($node->created); For 4.5, the code is slightly different in node.module, around line 1095... if (!$node->nid) { // Force defaults in case people modify the form: $node->status = variable_get("node_status_$node->type", 1); $node->promote = variable_get("node_promote_$node->type", 1); $node->moderate = variable_get("node_moderate_$node->type", 0); $node->sticky = variable_get("node_sticky_$node->type", 0); } else { // If the node is being updated, respect is previous settings unset($node->status); unset($node->moderate); unset($node->promote); unset($node->sticky); } ------------------------------------------------------------------------ April 13, 2005 - 12:06 : r11r Attachment: http://drupal.org/files/issues/node.module_head.patch (1.38 KB) Patch for node.module in HEAD ------------------------------------------------------------------------ April 13, 2005 - 12:06 : r11r Attachment: http://drupal.org/files/issues/comment_head.module (76.29 KB) Patch for comment.module in HEAD ------------------------------------------------------------------------ April 13, 2005 - 12:07 : r11r Attachment: http://drupal.org/files/issues/comment.module_head.patch (976 bytes) Err, sorry too many files to pick from in the directory . :) Here's the patch again. (for comment.module, in HEAD) ------------------------------------------------------------------------ April 13, 2005 - 12:09 : r11r Attachment: http://drupal.org/files/issues/node.module_drupal-4-6.patch (1.39 KB) Patch for node.module in DRUPAL-4-6 ------------------------------------------------------------------------ April 13, 2005 - 12:09 : r11r Attachment: http://drupal.org/files/issues/comment.module_drupal-4-6.patch (988 bytes) Patch for comment.module in DRUPAL-4-6 ------------------------------------------------------------------------ April 13, 2005 - 12:10 : r11r Attachment: http://drupal.org/files/issues/node.module_drupal-4-5.patch (1.38 KB) Patch for node.module in DRUPAL-4-5 ------------------------------------------------------------------------ April 13, 2005 - 12:10 : r11r Attachment: http://drupal.org/files/issues/comment.module_drupal-4-5.patch (1010 bytes) Patch for comment.module in DRUPAL-4-5 ------------------------------------------------------------------------ April 14, 2005 - 09:45 : killes(a)www.drop.org Some people think, that the node settings _should_ be reset after editing. There are good reasons for some of the settings to be reset, for exampel in case of the "promote" bit. I cannot see such reasons in case of the "comment" bit and would like to see that part of the patch included.

1 0

← Newer
1
...
27
28
29
30
31
32
33
...
51
Older →

Jump to page: