Front page module - The way it should be.[tm]
Hey peeps, Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list. Currently, when you install the front page module, you have to go and change: admin > settings > "node" to "front_page" if you want your stuff to show up. To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says: [x] Enable this option site wide. Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option. --- This would then actually go set node to be front_page -- ... What do you guys(gals) think? Trae PS. See you guys at DrupalCon! You can beat me up (or attempt to) there! -- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
Trae McCombs wrote:
Hey peeps,
Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list.
Currently, when you install the front page module, you have to go and change:
admin > settings > "node" to "front_page" if you want your stuff to show up.
To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says:
[x] Enable this option site wide.
Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option.
--- This would then actually go set node to be front_page -- ...
What do you guys(gals) think?
Easy to do, the option is just set via variable. You can even be smart on the form and look at the variable, and put up text saying "front_page isn't currently set as your default front page" like web browsers do, and not show the checkbox at all (or even a nice happy "front_page is set as your front page!") message.
http://drupal.org/node/47164 Sorry, I'm a bad boy... I created an issue. Thanks, Trae Earl Miles wrote:
Trae McCombs wrote:
Hey peeps,
Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list.
Currently, when you install the front page module, you have to go and change:
admin > settings > "node" to "front_page" if you want your stuff to show up.
To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says:
[x] Enable this option site wide.
Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option.
--- This would then actually go set node to be front_page -- ...
What do you guys(gals) think?
Easy to do, the option is just set via variable. You can even be smart on the form and look at the variable, and put up text saying "front_page isn't currently set as your default front page" like web browsers do, and not show the checkbox at all (or even a nice happy "front_page is set as your front page!") message.
-- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
Actually, I do not want to spoil your day, but dashboard module is the future. Let frontpage module die. It has served its time, we now have something FAR better. :) Br Op dinsdag 31 januari 2006 02:45, schreef Trae McCombs:
Sorry, I'm a bad boy... I created an issue. Thanks, Trae
Earl Miles wrote:
Trae McCombs wrote:
Hey peeps,
Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list.
Currently, when you install the front page module, you have to go and change:
admin > settings > "node" to "front_page" if you want your stuff to show up.
To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says:
[x] Enable this option site wide.
Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option.
--- This would then actually go set node to be front_page -- ...
What do you guys(gals) think?
Easy to do, the option is just set via variable. You can even be smart on the form and look at the variable, and put up text saying "front_page isn't currently set as your default front page" like web browsers do, and not show the checkbox at all (or even a nice happy "front_page is set as your front page!") message.
-- | Bèr Kessels | webschuur.com | website development | | Jabber & Google Talk: ber@jabber.webschuur.com | http://bler.webschuur.com | http://www.webschuur.com |
No worries to me what you call the module. As long as the functionality is there. Trae Bèr Kessels wrote:
Actually, I do not want to spoil your day, but dashboard module is the future. Let frontpage module die. It has served its time, we now have something FAR better. :)
Br
Op dinsdag 31 januari 2006 02:45, schreef Trae McCombs:
Sorry, I'm a bad boy... I created an issue. Thanks, Trae
Earl Miles wrote:
Trae McCombs wrote:
Hey peeps,
Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list.
Currently, when you install the front page module, you have to go and change:
admin > settings > "node" to "front_page" if you want your stuff to show up.
To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says:
[x] Enable this option site wide.
Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option.
--- This would then actually go set node to be front_page -- ...
What do you guys(gals) think?
Easy to do, the option is just set via variable. You can even be smart on the form and look at the variable, and put up text saying "front_page isn't currently set as your default front page" like web browsers do, and not show the checkbox at all (or even a nice happy "front_page is set as your front page!") message.
-- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com CivicSpaceLabs - http://civicspacelabs.org/
Bèr Kessels wrote:
Actually, I do not want to spoil your day, but dashboard module is the future. Let frontpage module die. It has served its time, we now have something FAR better. :)
Br
Roger that. Dashboard+Views+Insert Views+Node Queue = Greatest acheivement in all of human history. Er, actually that's an exaggeration, but at the very least try the combo on 4.7 and you'll end up saying to yourself "my god, what a kick ass alternative the frontpage module, or custom coding!" Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and-evolve modules, than attempt to create a bloateriffic one-shot-5-kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module. Best, Nick Lewis http://nicklewis.smartcampaigns.com
Op dinsdag 31 januari 2006 02:45, schreef Trae McCombs:
Sorry, I'm a bad boy... I created an issue. Thanks, Trae
Earl Miles wrote:
Trae McCombs wrote:
Hey peeps,
Since Gerhard was thinking the module isn't maintained, I thought I'd stick a comment here on the list.
Currently, when you install the front page module, you have to go and change:
admin > settings > "node" to "front_page" if you want your stuff to show up.
To us "dorky end users", this is quite confusing. I would suggest that there is something inside the: admin > settings > front_page area that says:
[x] Enable this option site wide.
Help text: *** Warning, if you enable this, when people visit: your_drupal_site.com they will see what you have put here on this front page form. To change this action back, simply disable this option.
--- This would then actually go set node to be front_page -- ...
What do you guys(gals) think?
Easy to do, the option is just set via variable. You can even be smart on the form and look at the variable, and put up text saying "front_page isn't currently set as your default front page" like web browsers do, and not show the checkbox at all (or even a nice happy "front_page is set as your front page!") message.
Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and-evolve modules, than attempt to create a bloateriffic one-shot-5-kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module.
Bèr, by the end of the year you will eat your words regarding enewsletter module's modularisation, here's a good beer to wash them down with, and clear any thoughts of socialism from your head - well any thoughts period .... http://en.wikipedia.org/wiki/Imperial_stout Also good for coughs ;-) Best regards, Robert
It wasn't Ber who said that. It was Nick Lewis. On 1/31/06, Robert Castelo <robert.castelo@cortextcommunications.com> wrote:
Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and-evolve modules, than attempt to create a bloateriffic one-shot-5-kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module.
Bèr, by the end of the year you will eat your words regarding enewsletter
Heh, sorry Ber, beer goes to Nick next time I see him ;-) On 31 Jan 2006, at 16:19, Khalid B wrote:
It wasn't Ber who said that. It was Nick Lewis.
On 1/31/06, Robert Castelo <robert.castelo@cortextcommunications.com> wrote:
Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and-evolve modules, than attempt to create a bloateriffic one-shot-5-kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module.
Bèr, by the end of the year you will eat your words regarding enewsletter
Op dinsdag 31 januari 2006 17:34, schreef Robert Castelo:
Heh, sorry Ber, beer goes to Nick next time I see him In fact, I chatted with you about that modularisation a while ago. And told you that I beleived it to be the Right Thing To Do. I still think so.
-- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
Nick Lewis wrote:
Bèr Kessels wrote:
Actually, I do not want to spoil your day, but dashboard module is the future. Let frontpage module die. It has served its time, we now have something FAR better. :)
Br
Roger that. Dashboard+Views+Insert Views+Node Queue = Greatest acheivement in all of human history. Er, actually that's an exaggeration, but at the very least try the combo on 4.7 and you'll end up saying to yourself "my god, what a kick ass alternative the frontpage module, or custom coding!"
Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and-evolve modules, than attempt to create a bloateriffic one-shot-5-kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module.
The one thing that this combination doesn't really address is the 'choose a front page based upon criteria' which is what the front_page module should be retained to do.
On 31 Jan 2006, at 6:03 PM, Earl Miles wrote:
The one thing that this combination doesn't really address is the 'choose a front page based upon criteria' which is what the front_page module should be retained to do. I want that to be integrated into core.
'layout' support. To replace the tiered theme settings, and multiple completely incoherent visibility pages. It's part one of the things that prompted me to post about changing to a layered variable system actually, and it would allow us to finally put this entire admin theme thing behind us, by giving an (optional) interface to change the triggers for the specific layout. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Besides, I think a frontpage is too complex and diverse of a requirement to effectively tackle with one standalone module. Better to combine lots of simple THEREFORE easy to maintain-and- evolve modules, than attempt to create a bloateriffic one-shot-5- kills module. Of course, like socialism, that's a good idea that shouldn't be taken to ridiculous extremes as observed with one ::cough:: enewsletter module.
Finally, someone who agrees on the fact that the enewsletter.module is _way_ too extreme. -- Dries Buytaert :: http://www.buytaert.net/
On Jan 31, 2006, at 11:31 AM, Dries Buytaert wrote:
Finally, someone who agrees on the fact that the enewsletter.module is _way_ too extreme.
I guess now's as good a time as any to point folks to my send and news module work. In effect, it's "competing" with what enewsletter is trying to do, but we needed the functionality so there it is. Modularity is good, but the thing that makes Drupal strong is modularity with vertical integration. Each module performs only one major function, but through the hook system it can perform parts of that function at every required stage. It's functional modularity, not component modularity, and it's a good to meet real-world requirements while building a foundation for later. I've taken this approach with the cvs version of send ( http:// drupal.org/node/37480 ), which covers the functional requirement of sending 1 or more nodes to 1 or more recipients. The first application was to send a node to a friend, but we quickly realized that there are many reasons and ways of doing this (petitions, guest passes, newsletters, upcoming events, etc.), each with the same basic functionality but slightly modified UI's and supplemental functionality. Thanks to the Forms API, it's easy to modify send's appearance and behavior. I've written a news module that modifies send's composition form by replacing the recipient with a mailing list selector. Because it's using send's functionality, you get message logging, CiviCRM integration and additional hooks "for free". This is accomplished in about 90 lines of code. Other send sub-modules can take advantage of its functionality without adding new code or overhead. And I'm working in send hooks for modules that don't send anything, such as clickthru and open-rate tracking, filters, message trailers, etc. that will affect every current and future send activity. You end up with a single source of information about which nodes got sent to whom, and for what purpose. I also implemented a cascading variable system so that subject, message and other settings can be set on a per-module, per-nodetype and per-node level, with default from the next item up the tree. Not relevant to this conversation, but interesting and probably worth a look. So what I'm getting at is that modularity is good, but we shouldn't lose sight of Drupal's strength: functional modularity through the hook system. For efficiency and extensibility, we should seek to develop modules that work in harmony, not just modules that can be cobbled together. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
On Tue, 2006-01-31 at 12:10 -0600, Allie Micka wrote:
I also implemented a cascading variable system so that subject, message and other settings can be set on a per-module, per-nodetype and per-node level, with default from the next item up the tree. Not relevant to this conversation, but interesting and probably worth a look.
Allie Micka pajunas interactive, inc. http://www.pajunas.com
And where could I look to see this cascading goodness... I'm using something similar in a modified thumbnail module I'm working on... I would like to compare implementation... function _thumbnail_get_var($var, $node) { global $thumb_defs; $node = (array) $node; if (isset($node['thumb_'.$var])) { $value = $node['thumb_'.$var]; } else { $value = variable_get('thumb_' . $node['type'] . '_' . $var , variable_get('thumb_' . $var, $thumb_defs[$var])); } return $value; } is what I was playing with for this particular use case.
On Jan 31, 2006, at 5:51 PM, Darrel O'Pry wrote:
And where could I look to see this cascading goodness... I'm using something similar in a modified thumbnail module I'm working on... I would like to compare implementation...
It's in _send_value() at http://cvs.drupal.org/viewcvs/drupal/ contributions/modules/send/send.module?sortby=log&view=markup , and I'm storing the value within _send_nodetype_settings() in http:// cvs.drupal.org/viewcvs/drupal/contributions/modules/send/send.inc? sortby=log&view=markup by hijacking them from the variables table, saving them to my own handler, and deleting them. The key difference between your implementation and mine is that I wanted to be able to store it on a per-node level, so I wrote my own storage and skipped the variable table for all but a few settings. It's specific to my use, which overrides in order of default, module, nodetype, node. I suppose that's pretty generic, but not universal. Mine is a neat approach because it minimizes storage requirements by refusing to store a value if it's the same as the value it's overriding. There's some cost on retrieval because you're running a moderately-complex query for each setting. I coded the module to retrieve settings ONLY on the send or admin pages, so it doesn't affect the site at large. You'd have to do some fancy efficiency footwork if you wanted to reuse this concept more globally. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
participants (10)
-
Adrian Rossouw -
Allie Micka -
Bèr Kessels -
Darrel O'Pry -
Dries Buytaert -
Earl Miles -
Khalid B -
Nick Lewis -
Robert Castelo -
Trae McCombs