Development
Threads by month
- ----- 2026 -----
- June
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- 9354 discussions
[drupal-devel] [feature] Improve functionality of block generation for book module
by Dries 20 Jan '05
by Dries 20 Jan '05
20 Jan '05
Project: Drupal
Version: cvs
Component: book.module
Category: feature requests
Priority: normal
Assigned to: nysus
Reported by: nysus
Updated by: Dries
Status: patch
The menu is recreated every time a book page is updated. I believe this
is unwanted behavior because it requires the book block to be
reconfigured upon every update.
Dries
Previous comments:
------------------------------------------------------------------------
December 9, 2004 - 08:12 : nysus
Attachment: http://drupal.org/files/issues/book_19.patch (4.85 KB)
Attached is a patch for the book module that does the following:
1) Allows book blocks to appear on any page at any time, not just when
a node from the book is being viewed.
2) Allows multiple book blocks to appear on the same page.
This functionality is achieved by the automatic creation of individual
blocks for each book when the book is created. Simply enable the
book's block to enjoy the benefits of 1 & 2 above. If the blocks are
not enabled, the blocks will appear only when a node from that block is
being viewed (the same way it works now).
------------------------------------------------------------------------
December 9, 2004 - 14:35 : andremolnar
Attachment: http://drupal.org/files/issues/book_19_1.patch (4.84 KB)
+1 This is great. A good many people have asked for something like
this, and I think its a nice solution. But in the end this isn't up to
me.
One minor error in the patch...
+ $result = db_query('SELECT n.title, b.block, b.nid FROM {book} b
INNER JOIN {node} n on n.nid = b.nid WHERE b.parent = 0');
b.block is not a valid field in this query. this updated patch removes
reference to it.
andre
------------------------------------------------------------------------
December 9, 2004 - 15:54 : nysus
Glad you like it and thanks for fixing that up. It was left over from
an older version of my patch.
------------------------------------------------------------------------
December 9, 2004 - 15:54 : andremolnar
Steve,
If I apply this patch, and I attempt to configure one of the newly
created blocks. I noticed that for some reason the block.module is
returning "true" at line 249 (of the block module)- and is creating a
form for module-specific configuration. But all that shows up on the
screen is the word "array".
Can you trace this back to see why - and maybe update the patch.
I can continue to test your changes - anything to help this patch make
it into core.
andre
------------------------------------------------------------------------
December 9, 2004 - 17:29 : nysus
Hmmm...probably because I tested my patch on my version of Drupal,
version 4.5.1. I'm having no problems. Are you using a cvs version of
Drupal to test. If so, I'll set up cvs on my site and track this down.
------------------------------------------------------------------------
December 9, 2004 - 20:53 : drumm
See http://drupal.org/node/12347 for information on how the block system
has been updated. When I saw that the elseif ($op == 'view') was taken
out I knew immedaitely that there was something weird about this patch.
------------------------------------------------------------------------
December 9, 2004 - 20:58 : nysus
OK, thanks for the tip. Sorry for the confusion. Still kind of new to
making open source contributions and it's easy for me to overlook some
obvious stuff like this. I'll fix this up when I get a chance.
------------------------------------------------------------------------
December 9, 2004 - 21:06 : Dries
Please do, because this being a new feature, it has no chance getting
committed to the DRUPAL-4-5 branch. The DRUPAL-4-5 branch is in
bugfix-mode. New features go into CVS HEAD.
------------------------------------------------------------------------
December 10, 2004 - 00:32 : Dries
There is quite a bit of duplicated code in the patch. Maybe it can be
simplified (using a function)? Either way, it is a little weird. I
haven't tried the path, and I'm not sure I understood the description.
It's somewhat vague. Is the book module exporting multiple blocks that
are nearly identical, yet have different display behavior? If so, why
not add a simple block configuration setting to the original book
block?
------------------------------------------------------------------------
December 10, 2004 - 04:51 : nysus
Dries,
Yes, there is some code that can be factored out and some general
cleaning up that can be done. It was a little tricky to write so I
left it kind of ragged around the edges until I'm sure there are no
bugs. It has worked very well on 4.5.1 but I obviously need to update
it to work with cvs. I'll be on that soon.
As far as what it does:
1) For every new book that a user creates, a new block is associated
with it. So if you create "Book A", "Book B", "Book C", you will get
three new blocks visible on the block administration page called "Book
A", "Book B", "Book C". The original "Book Navigation" block is still
there, too. The functionality of the "Book Navigation" block is not
affected at all by this patch.
2) If Book A's block is enabled, the block containing its menu will
appear not only when a node within Book A is viewed, but at all times
(unless the user suppresses it on certain pages with the "path"
feature). When any node is that is NOT in Book A is viewed, Book A's
menu still appears but it is fully collapsed. When a node that DOES
belong to Book A is viewed, Book A's Book menu expands accordingly.
3) The user can also enable Book B & C's block, and have their menus
appear in a block at all times as well.
4) If none of the book's blocks are enabled by the user, the module
will behave just as it did without the patch. That is, when the "Book
Navigation" block is enabled, the only time any book menu will appear
is when a book node is being viewed.
5) It's important to note (and this was the tricky part to write) that
if both the "Book Navigation" block is enabled and "Book A" is enabled,
they will play nice with each other and not do nasty things like create
the same book menu twice.
------------------------------------------------------------------------
December 10, 2004 - 07:51 : nysus
Attachment: http://drupal.org/files/issues/book_20.patch (5.37 KB)
Andre,
Attached is a new patch that will resolve the problem of the
block-specific stuff showing on the block configuration form.
Let me know if you spot any other bugs. If it looks good to you, I'll
go to work making the code look leaner and prettier.
------------------------------------------------------------------------
December 10, 2004 - 09:26 : nysus
Attachment: http://drupal.org/files/issues/book_21.patch (4 KB)
Dries, Andre:
Here is a new and improved streamlined version of the patch. Have a
look if you get a chance.
------------------------------------------------------------------------
December 10, 2004 - 10:11 : nysus
Attachment: http://drupal.org/files/issues/book_22.patch (4.15 KB)
Found a bug in the last version that would cause the block to jump to a
different location. I think this should do it. Everything appear to
work well (famous last words).
------------------------------------------------------------------------
December 10, 2004 - 16:49 : andremolnar
Steve: bugs appear to be gone, and I didn't run across any other
errors. This is functioning exactly as described.
everyone: I personally would encourage support for this functionality.
Book is a powerful navigation building tool in a site, not only with
its ability to move next and back through a hierarchy of pages - but
also its ability to build the appropriate navigation block without
further user intervention (unlike the admin features in the menu module
or taxonomy).
The most frequently cited complaint about the book module is its
inflexibility when it comes to when and where the block shows up. I
also frequently hear requests for the ability to show multiple book
blocks at the same time. Up until now the best alternatives suggested
required users to do a hack (e.g. build a custom block that calls such
and such a hook). Most abandon their request at that point because its
over their heads.
With this patch all those requests are covered and more. Now all books
can automatically have their own block and admins can easily decide when
and where each of those individual blocks show up (left right, up down)
and coupled with the new configuration features of the block module -
its very easy for admins to decide on which individual pages a block
will show up.
I would be interested what other have to say about this feature.
My only reservation (which is minor compared to the benefits of the
functionality offered) is that there is no way to turn this
functionality off. i.e. The default behaviour is to build individual
blocks for each book. If there could be a way to toggle this feature
on and off somewhere - it would be perfect. Still, AS IS - this is a
major improvement and offers great flexibility to admins and site
creators.
andre
------------------------------------------------------------------------
December 10, 2004 - 17:04 : Anonymous
Andre,
Thanks for the feedback on the usefulness of this module. Glad I could
pitch in and help.
I agree about the inability to turn the feature on/off and I was
thinking about that myself. I think it could easily be accomplished
by creating a checkbox in the "book navigation" block individual
configuration's settings. Call it "Enable individual book blocks."
When enabled, the individual book blocks will appear on the block
administration menu.
One question: Where would the state of this checkbox get saved? Has
Drupal moved away from serializing data in the data base?
------------------------------------------------------------------------
December 10, 2004 - 20:36 : Dries
I'm afraid that 'Enable individual book blocks.' is not
descriptive/clear at all. Are you suggesting a setting to toggle
between 'show block on all pages' and 'show block on book pages only'?
------------------------------------------------------------------------
December 10, 2004 - 21:45 : nysus
Dries,
No. Andre and I suggest a setting within the "Book Navigation"
cofiguration page, that would toggle whether or not individual books
appear on the list of all blocks on the block administration page.
Hence the name 'Enable individual book navigation blocks.' The help
text for this checkbox might read something like: "By default, a book's
navigation block is visible only when a page from that book is being
viewed. Check this box if you want more control over where and when an
book's navigation block is visible. You will then be able to control
the book's navigation block location and visibility settings on the
"admin/block" page."
Hope this makes it pretty clear.
------------------------------------------------------------------------
December 10, 2004 - 22:08 : Dries
I understand what you are trying to do, but not how you are trying to do
it, or how the setting is supposed to work. I guess I'll have to try it
when a new patch lands.
------------------------------------------------------------------------
December 11, 2004 - 11:52 : nysus
Attachment: http://drupal.org/files/issues/book_23.patch (5.02 KB)
Alright, fellas, I'm proud to unveil my crowning achievement in the open
source development world (no big deal to most of you guys but pretty
good for a hack like me).
Thanks for all the input so far. It's been helpful. I've streamlined
the heck out of it per Dries suggestion and I've created an option to
turn this functionality on an off per Andre's suggestion. Does this
look good to you guys? Anything else I have to fix or improve?
Thanks.
------------------------------------------------------------------------
December 11, 2004 - 15:02 : Dries
I tried the patch.
It works great but to me, the 'Give books their own block' settings
seems to be redundant. Why not export the current book navigation
block, along with an additional block for each book? Looks a lot
simpler to me.
I think I spotted a bug: orphaned book pages (or possibly book pages
that are unpublished) appear to be getting book navigation blocks.
------------------------------------------------------------------------
December 11, 2004 - 19:34 : nysus
I'll see if I can fix the bug. Might be tricky.
But I don't understand your recommendation to "export the current book
navigation block, along with an additional block for each book". Can
you expand on this thought?
------------------------------------------------------------------------
December 11, 2004 - 20:06 : nysus
Dries,
I am unable to duplicate the bug. I have three orphaned pages. I also
tried unpublishing some pages. But as far as I can tell, the patch
works as expected.
------------------------------------------------------------------------
December 11, 2004 - 21:00 : Dries
If you can't reproduce the problem, chances are my node/book table is
somewhat fubar.
As for the configuration option. I suggest removing it and to always
make these new blocks available on the /admin/block configuration
screen.
------------------------------------------------------------------------
December 11, 2004 - 21:52 : moshe weitzman
I am hoping that we maintain the option to keep the behavior where the
appropriate book block only shows up when its book page viewed. this is
a nice, tidy arrangement.
------------------------------------------------------------------------
December 11, 2004 - 22:03 : nysus
Yes, if you don't enable any of the individual book blocks, the a book's
block (i.e. navigation menu) will only appear when a page in a book is
viewed. In other words, you have the option to have the book block act
like this patch isn't even installed.
------------------------------------------------------------------------
December 11, 2004 - 22:54 : Dries
I guess I'll have to try the patch again, because I don't understand why
it works like this -- or at least, why it can't be made simpler.
------------------------------------------------------------------------
December 11, 2004 - 23:13 : nysus
Can you be more specific? Why it works like what?
------------------------------------------------------------------------
December 11, 2004 - 23:24 : nysus
Attachment: http://drupal.org/files/issues/book_24.patch (4.1 KB)
This patch reverses a change made in the last patch which required a
user to enable individual book block before they could enable any
individual book blocks.
------------------------------------------------------------------------
December 11, 2004 - 23:41 : andremolnar
As I mentioned earlier I am *fine* with either version of this patch as
long as it makes it to core.
But, as I said earlier, I clearly think the preference for admins would
be to have the option to enable or disable this functionality.
BTW - if this does make it in, I would be happy to create a Handbook
page that describes the new features - something like "how to build
robust site navigation using the book module". (on or after December
17th).
andre
------------------------------------------------------------------------
December 12, 2004 - 14:11 : Anonymous
I am not at all happy with these features. They are incosistant,
confusing and should use exising methods and UIs.
May main concern is the incosistancy: it is confusing, will require
extra attention with each core code change, adds extra logic to the
core, and is not re-useable.
so here are my questions:
1) why do we not use the menu system and apis to build and adminster
the trees? Saves code, does not add extra UIs, and gives users more
power.
2) why do we need that extra showing logic? a book block should not get
exeptional if clauses, it should use the existing path setting methods
on block admin. extra logic is confusing for administrators (hey, i set
the path so that the book-block should show up here, but it does not,
why?) we should really not provide extra logic in the block hook, but
should rather use default settings in block admin (the book could fill
the bookblock sql cells with custom paths, for example)
3) we should avoid extra UIs. We already have far too much, and far too
much different ones. Please rather improve the block admin, than add new
separate interfaces.
4) why do book blocks need al these expeptions in the first place? If
they are so exeptional, we could consider not using blocks, but
something else, like in-line book layout (pages with the index etc)
5) why did you not choose for a general, standard, block gerneation
API? that way modules, such as taxonomy, image gallery, weblinks,
article, etc can reuse it and introduce block gernation.
All that sayd, i like the idea of this functionality, but i fear for a
great useability downfall if we start introducing all sorts of
exeptions for all sorts of modules. Because now chances are very big
that taxonomy, image gallery etc will need to introduce other UIs,
other code, new methods and new documentation, if they too want some
sort of better block handling.
so a -1 from me.
------------------------------------------------------------------------
December 12, 2004 - 14:12 : Bèr Kessels
^^--- That was me (bèr kessels) forgot to log in.....
------------------------------------------------------------------------
December 12, 2004 - 14:34 : nysus
I'm not going to pretend I can argue if my patch does or does not fit
well into Drupal's larger architecture. My motivation for writing it
is that I had an immediate need to create an easy way to make it easy
for users to create menus.
I'll let others decide whether or not the patch has merit from the big
picture perspective. But if it doesn't, why not just use it for its
immediate benefits and then throw it away when something better comes
along?
------------------------------------------------------------------------
December 12, 2004 - 15:01 : Dries
My summary is this: +1 on the functionality, -1 on the implementation.
The code itself is good, but the usability/integration is not.
------------------------------------------------------------------------
December 12, 2004 - 15:13 : nysus
When you say "usability" is that from the user's perspective or the code
maintainers? I'm guessing it's the latter but I'm unsure.
What about the idea of using the patch until a more permanent solution
comes along? Yes, it's much better to live in a home with indoor
plumbing but why not use the outhouse while you wait for a toilet to
get installed? Or are there other considerations I'm overlooking that
would make this a bad idea?
------------------------------------------------------------------------
December 12, 2004 - 15:20 : Goba
nysus it is just generally against the Drupal philosophy to add
improperly implemented functionality until something better comes
along. There even used to be ocassions in Drupal releases, when some
functionality was removed (not fixed) for a release, because its
implementation was not adequate.
------------------------------------------------------------------------
December 12, 2004 - 15:55 : Dries
Usability for the user. The extra setting on the block configuration
page is both confusing and awkward. I don't understand why things must
be configured/enabled that way (see my and Ber's previous comments on
this issue).
------------------------------------------------------------------------
December 12, 2004 - 16:03 : nysus
Well, just for the record, I reversed that functionality per your
suggestion and uploaded the patch. The indiviudal book blocks now
appear automatically.
------------------------------------------------------------------------
December 13, 2004 - 15:56 : Bèr Kessels
Hi,
I am sure you can make not only simpler, but better usefull for admins
and users.
All you need to do is use the menus for this. i.e. make a menu entry
for each book page.
For each book make a menu on level 0, without a parent. that way they
become a seoprate menu, each with an own block.
it saves code, makes things more consistent, and most important, uses
drupal functionality where it should.
------------------------------------------------------------------------
December 13, 2004 - 16:50 : nysus
Ber,
Are you suggesting that for every single book page that a menu item be
created? That's really not practical. That was my main motivation
for writing this patch: to make it easy to put links, not necessarily
related to one another, into a block. Any more pages than 10 and the
sheer tedium of the job would prevent anyone from ever doing that. The
menu.module is great, but adding new menu items is far from quick and
painless. I just added about 10 to my menu for different taxonomies on
my site and it wasn't fun.
Plus, if you do as you suggest, there is also the problem of the book
showing up twice. It will be generated by the menu and then it will be
generated again by the book module which is programmed to design a
block. You'd have to put some logic in the book.module _block hook to
try to anticipate if a user has enabled a book in the menu. That
wouldn't be pretty code.
I'm all for putting automatic generation of book navigation blocks as
part of the menu module. It does make more sense to have it there.
But it forces me to ask the question: "Then why do we currently have
code in the book module that generates a menu? Shouldn't that belong
in the menu.module, too?"
------------------------------------------------------------------------
December 14, 2004 - 00:31 : killes(a)www.drop.org
I think what Ber is trying to say is that you can write a contrib module
that monitors the changes to the book table and creates menu items
automatically. nodeapi is your friend. I would also prefer this
solution.
------------------------------------------------------------------------
December 15, 2004 - 18:39 : Anonymous
"Then why do we currently have code in the book module that generates a
menu? Shouldn't that belong in the menu.module, too?"
Because it's old code. It would be nice if book.module generated this
block using its _menu hook, so that the admin would have a few options
in terms of configuration.
Plus, if you do as you suggest, there is also the problem of the book
showing up twice. It will be generated by the menu and then it will be
generated again by the book module which is programmed to design a
block.
No. The old code which manually builds a block in book.module would be
removed. Book blocks would only be generated by the menu.
This would also have the added benefit of allow the administrator to
easily place a book in an appropriate spot in the menu tree, while
still allowing the possibility of displaying it in a separate block.
Because of menu caching, I don't expect a large performance hit for
creating the menu items.
That was my main motivation for writing this patch: to make it easy to
put links, not necessarily related to one another, into a block.
It sounds like instead of (mis)using book.module, your time would be
better spent in a usability improvement to menu.module so it's easier
to do this.
------------------------------------------------------------------------
December 16, 2004 - 08:55 : nysus
Thanks for the feedback and input. I appreciate it. However, I would
also appreciate if you took more care to avoid the condescending tone
in your post:
It sounds like instead of (mis)using book.module, your time would be
better spent in a usability improvement to menu.module so it's easier
to do this.
It's really quite unnecessary and off-putting. Though it won't stop me
from contributing to Drupal in the future, I'm sure others would be
really turned off by such a patronizing comment and it could dissuade
them. I'd like the Drupal community to be a welcoming and friendly
place that will inspire people to contribute, not discourage them.
Thanks.
------------------------------------------------------------------------
December 16, 2004 - 12:07 : Bèr Kessels
nyesus,
Please do not start /that/ discussion here. :) Drupal community is
known fo being direct, maybe because of the big number of
western-Europeans attending, maybe because of other reasons.
No-one commented that you are wasting your time. But the commentor was
telling you somthing likethis:
"If you would follow the previous sugeestions, your added feature would
be much better appreciated, and will probably work much better for you
too".
He/she was by no means telling you to stop your silly coding, or
anything in that line. He/She only wanted to show you the obvious and
better direction.
We often deal with issues that add some feature, and a complete new UI,
because the author does not like, or cannot use the existing UIs and
features. This is nogt good, because if that same author would have
spend his/her time on improving that existing functionality or UI
(improving is not neccesarily the same as extending!!) that code and
time would benefit all much better.
Thats what the commentor tried to say. And so is it here: If you
dislike the way the books handle the blocks, and if you do not want to
use the menu, because you do not like its UI, then do not add another
UI and more features, but rather merge these, and improve the parts (in
the menu) you dislike.
------------------------------------------------------------------------
December 16, 2004 - 12:35 : Dries
We can worry about the menu integration later. Let's focus on the new
option's usability/interaction design first.
------------------------------------------------------------------------
December 16, 2004 - 16:51 : nysus
I understand what the commenter was saying and like I said, I appreciate
and understand it. I'm not upset and I'm not looking for an argument, I
was just being direct as well. :) As part of the Drupal community
(albeit a minor player), all I'm saying is that I would like to see
folks not have a tin ear to the humanity in all of us. It will help
make Drupal an even stronger community and attract even more talented
developers.
Human interaction is part of the development process. Whether we like
it or not, we must cope and deal with it.
------------------------------------------------------------------------
December 18, 2004 - 11:54 : Dries
I thought some more about this and am starting to believe that
integration with the menu system should take priority. Here are common
cool scenario's:
I want to create a separate navigation block for the 'Drupal
handbook'.
I want to add a menu item called 'handbook' to the user block. That
is, I want the book navigation to be part of the existing user
navigation block.
I want to add a menu item called 'handbook' to the top-level
navigation menu.
How would that work from a user's point of view? What do I have to
click and where to configure this?
------------------------------------------------------------------------
December 21, 2004 - 20:47 : andremolnar
I was actually thinking about the same thing last night (must have been
something in the arctic air).
2. I want to add a menu item called 'handbook' to the user block. That
is, I want the book navigation to be part of the existing user
navigation block.
3. I want to add a menu item called 'handbook' to the top-level
navigation menu.
This is already possible (to a certain extent) with the current
Book.module and Menu.module - A 'Books' menu item is created in the
user navigation by having the Book.module enabled. Menu.module allows
you to enable/disable this menu item. Menu.module also allows you to
re-name this menu item. But, this only helps if you only intend to
have 1 book (or else the name 'Handbook' is misleading if the user
finds more than 1 book listed). - so this isn't good enough (or is
it).
1. I want to create a separate navigation block for the 'Drupal
handbook'.
This is what I was trying to figure out. Not just this, but a
different way to do what Nysus was attempting. i.e. create a menu
block for each and every book that is created. There is a way to write
code that would (re)build a 'custom menu' on every add/edit/update to a
book page - or book outline update. Custom menu's automatically have a
block created for them. But, this I think would be a misleading use of
the 'custom' menu - as the menu would not be custom if they are a part
of core.
So, I would think that two new constants could be added to the menu.inc
file - MENU_BOOK_MENU - and MENU_BOOK_ITEM - each would behave as custom
menu's, but would be reserved for books. These menu types should NOT
show up in the Menu.module administration - because the administration
of the book_menu items would be done by administering the book itself
(adding an item, removing an item, moving an item up/down in the
hierarchy, assigning parents etc.).
However, the blocks that the book_menus would create would show up in
the block administration (so users could enable/disable each block -
and decide where on the site they show up). The existing book block
logic would be removed.
So the logic would be:
If a creates a book in the book administration page - the Book.module
automatically creates a new MENU_BOOK_MENU
Any time a user adds to or updates or delets a book page - the entire
book menu is deleted and recreated based on the hierarchy defined by
the book itself.
The blocks for each book would show up in block administration.
Any thoughts - I know that this doesn't exactly address points 1 and 2
- but it could act as a first step.
Is this approach a bad idea? It would add special conditions for the
proposed book menu's - but books would be a special case.
Even if people don't like this solution, maybe it will give someone a
better idea. I'd love to hear them.
andre
------------------------------------------------------------------------
December 22, 2004 - 00:55 : Boris Mann
+1 to this andre
I had promised to put down my thoughts on this matter, as it relates to
1) primary and secondary links and how they are managed and 2)
auto-generation of primary/secondary navigation based on book outlines
So, for 1), we currently have functional-but-not-very-usable plain
textfields to manage primary and secondary links. I would like to see
menu.module used to control all navigation links, whether it is the
navigation block or primary/secondary links. What is needed:
a) default system menus labelled "primary" and "secondary" which would
store; this is where modules could insert navigation
b) support for full URLs (e.g. http://myexternaldomain.com) instead of
just path
2) if we got 1 working, and andre does his book menus, this could get
taken care of automatically. Basically, for brochureware/business/etc.
sites that have static content, you could have a root book as one of
the primary navigation links, and then the secondary links are
generated automatically.
------------------------------------------------------------------------
December 22, 2004 - 23:02 : Dries
I agree with Andre that the book module's integration with the menu
system needs to be worked on. I support any effort that makes it
easier to structure pages and that makes it easy to link pages/nodes
from within a menu.
However, I'm opposed to putting book module specific names in the menu
system (eg. MENU_BOOK_MENU and MENU_BOOK_ITEM). I can imagine a
handful of modules that want to maintain a menu tree (or part thereof)
so I'm in favor of generic names.
I'd have to read up on the menu system code, but last time I checked
there was a MENU_MODIFIABLE_BY_ADMIN flag. You could choose not to set
this flag for the menu items generated by the book module. Maybe it's
already possible to implement to implement Andre's suggestion without
having to modify/extend the menu system.
Are you exploring this path?
------------------------------------------------------------------------
December 24, 2004 - 12:01 : andremolnar
I've had a few spare hours to work on this.
I've started to cobble together a solution - but in doing so I
discovered a bug in the menu module (for which I will submit a seperate
issue - if one doesn't already exist).
The principal I suggested works. I added some code to the book module
that creates custom menu's (MENU_CUSTOM_MENU with MENU_CUSTOM_ITEMs)
for each Book that exists in a site. This is just as a proof of
concept - I chose this menu type to start with because they
automatically have a block created for them in admin/block (which is
ultimatly the functionality we want).
I ran a test and the menus are created as expected - the blocks are
also created. But when I tested the menu blocks by enabling them I ran
into a problem.
It seems as though the menu system does not expand/explode sub menu
items if the node type is book. I'm not sure why this is, and I
haven't traced the source code yet - I thought I would ask if anyone
has intimate knowledge of the menu system if they can point me in the
right direction.
No patch attached because until that problem is fixed this proposed
change won't fly :(
andre
------------------------------------------------------------------------
December 24, 2004 - 13:11 : Dries
Just a wild guess: maybe it doesn't work because the book module's URI
scheme is not hierarchical?
------------------------------------------------------------------------
January 7, 2005 - 12:45 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_1.patch (5.1 KB)
I finally took some time out to do some work on this. As mentioned in a
post to dev the problem I was having with menus not
expanding/contracting properly was some crud in my database. Once that
was cleared up my changes worked fine.
I am attaching a patch for comments and for the brave willing to give
it a test drive.
History: This thread and http://drupal.org/node/15198 and
http://drupal.org/node/15153
node/15198 has a patch that is required for this patch to work.
What this does:
Pretty straight forward.
Any time a user adds/updates/deletes book or book pages (including via
outline) - a function is called to create a new menu for each book.
Any existing book menus are wiped out and then the new book menus are
inserted - and the system menu is rebuilt to reflect the changes.
The menus created consist of type MENU_MODULE_MENU and
MENU_MODULE_ITEM. These menus show up in the menu/admin page so that
admins can be aware of them, but the menu types are not editable via
menu/admin (all changes are handled by the book module).
Since the menus are in the menu table, the menu_block() hook handles
the creation of the blocks for each of them. The blocks can then be
administered in the usual ways via the block/admin interface.
KNOWN ISSUE: (suggested solutions welcome)
Since the menu table is updated on every change to books - the blocks
associated with the menus are also recreated with default settings
(i.e. disabled, and with no path or throttle settings) requiring a user
to take an extra step and re-configure the book blocks for viewing on
their site. I think this is unacceptable. For the casual user of the
book module that only has a single book that doesn't change often, this
would not be a big deal. But, if anyone wanted to make use of book
module to handle dynamic site navigation this would create more work
than it saves.
Looking forward:
If the block generation issue can be solved in a tidy way, this patch
could allow users to use book to handle all their site navigation
generation needs.
Also, this patch could allow for the removal of a large chunk of code
in the book module dedicated to building its own block via the block
system. I left it there for now because I suppose there may be those
out there that want to have book.module work the way book.module always
worked (only show the book block when viewing a book page). Even so,
since each book would have its own block, an admin could specify when
and where the block shows via admin/block.
I would appreciate feedback. If nothing else I hope this gives someone
some new ideas.
I'll continue to work on the block regeneration issue.
andre
------------------------------------------------------------------------
January 7, 2005 - 12:47 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_2.patch (4.98 KB)
sorry - here's a patch with prefered line breaks.
andre
------------------------------------------------------------------------
January 7, 2005 - 18:47 : nysus
Andre,
I've been meaning to give this a throrough look when I get a chance.
Hopefully this weekend.
---Steve
------------------------------------------------------------------------
January 20, 2005 - 04:02 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_3.patch (6.66 KB)
Here is an updated patch.
Same comments as followup 51 - except that the known issue has been
resolved.
This changes book module so that any action taken on a book, including
adding new books or book pages will create a menu in the menu system
for that book - and thus create blocks for those menus that can be
administered in the usual ways.
This is my first attempt at a major patch to core - comments are
welcome
I will be happy to update documentation once revisions to the code have
been taken care of.
andre
------------------------------------------------------------------------
January 20, 2005 - 04:53 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_4.patch (6.17 KB)
Sorry - would be nice if I removed some debugging code - ;-)
also previous patch also would have introduced a need for a change to
the menu table that isn't required yet.
This patch is a correct version
andre
--
View: http://drupal.org/node/14120
Edit: http://drupal.org/project/comments/add/14120
1
0
File: /modules/album/album.module 1.2
/modules/og/og.module 1.28
Date: January 20, 2005 - 19:14
User: weitzman
fix buggy links and many otherl improvements.
----------------------------------------------------------------------
File: /modules/devel/generate/README 1.3
/modules/devel/README 1.6
Date: January 20, 2005 - 15:53
User: ber
----------------------------------------------------------------------
File: /translations/da/aggregator-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/archive-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/block-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/blog-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/blogapi-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/book-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/comment-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/common-inc.po 1.1.2.1 DRUPAL-4-5
/translations/da/drupal-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/file-inc.po 1.1.2.1 DRUPAL-4-5
/translations/da/filter-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/forum-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/general.po 1.1.2.1 DRUPAL-4-5
/translations/da/languages.po 1.1.2.1 DRUPAL-4-5
/translations/da/locale-inc.po 1.1.2.1 DRUPAL-4-5
/translations/da/locale-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/menu-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/node-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/path-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/ping-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/poll-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/profile-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/queue-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/README 1.1.2.1 DRUPAL-4-5
/translations/da/search-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/statistics-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/story-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/system-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/taxonomy-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/throttle-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/upload-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/user-module.po 1.1.2.1 DRUPAL-4-5
/translations/da/watchdog-module.po 1.1.2.1 DRUPAL-4-5
Date: January 20, 2005 - 14:50
User: wulff
Initial release
----------------------------------------------------------------------
File: /modules/massmailer/engines/phplist/bin/phplist 1.1.2.2 DRUPAL-4-5
/modules/massmailer/engines/phplist/phplist.module 1.1.2.3 DRUPAL-4-5
Date: January 20, 2005 - 14:50
User: crunchywelch
fix php shell script environment bug that causes recursive page requests when processing the message queue
----------------------------------------------------------------------
File: /modules/massmailer/engines/phplist/bin/phplist 1.2
/modules/massmailer/engines/phplist/phplist.module 1.3
Date: January 20, 2005 - 14:47
User: crunchywelch
fix php shell script environment bug that causes recursive page requests when processing the message queue
----------------------------------------------------------------------
File: /modules/filestore2/filestore2.module 1.26
Date: January 20, 2005 - 12:17
User: gordon
- fixed up some validation problems and a couple of typo's
----------------------------------------------------------------------
File: /modules/fscache/fscache.module 1.12
Date: January 20, 2005 - 12:16
User: gordon
- fix a bug the was causing problems in pgsql.
- plus other minor bugs
----------------------------------------------------------------------
File: /modules/bloggerauth/bloggerauth.module 1.1
/modules/bloggerauth/INSTALL.txt 1.1
/modules/bloggerauth/README.txt 1.1
Date: January 20, 2005 - 08:21
User: themike
Initial import of untested code.
Docs are tested tho ;-)
----------------------------------------------------------------------
File: /modules/banner/banner.module 1.41.2.3 DRUPAL-4-5
/modules/banner/CHANGELOG 1.21.2.4 DRUPAL-4-5
Date: January 20, 2005 - 03:56
User: jeremy
sync with head, fixing issue #15873
----------------------------------------------------------------------
File: /modules/banner/banner.module 1.45
/modules/banner/CHANGELOG 1.25
Date: January 20, 2005 - 03:55
User: jeremy
- banner.module
o fix issue #15873: fix link to user account, remove []'s around options,
----------------------------------------------------------------------
File: /modules/legal/legal.module 1.4
Date: January 20, 2005 - 03:40
User: killes
admin edit bugfix
----------------------------------------------------------------------
File: /modules/legal/legal.module 1.3
Date: January 20, 2005 - 02:17
User: killes
Upgrade to 4.5 , patch by Mark Ryan and myself.
----------------------------------------------------------------------
File: /modules/over_text/over_text.module 1.10.2.1 DRUPAL-4-5
Date: January 20, 2005 - 01:59
User: nedjo
Fix to issue #14162 as reported by drupal.org user skorch.
----------------------------------------------------------------------
File: /sandbox/walkah/image/bu/bu.module NONE
/sandbox/walkah/image/bu/readme.txt NONE
Date: January 20, 2005 - 01:51
User: weitzman
deprecated in favor of album.module
----------------------------------------------------------------------
File: /modules/jsdomenu/jsdomenu.module 1.13.2.2 DRUPAL-4-5
Date: January 20, 2005 - 01:44
User: nedjo
Applied fix to bug report #11418 as supplied by drupal.org user joel_guesclin. Converted line endings to unix.
----------------------------------------------------------------------
File: /translations/it/locale-module.po 1.10
Date: January 20, 2005 - 00:15
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /translations/it/search-module.po 1.6
Date: January 20, 2005 - 00:12
User: michelef
Drupal 4.5.2 translation; ongoing.
----------------------------------------------------------------------
File: /translations/it/menu-module.po 1.6
Date: January 20, 2005 - 00:12
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /translations/it/book-module.po 1.8
Date: January 20, 2005 - 00:11
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /translations/it/blog-module.po 1.8
Date: January 20, 2005 - 00:11
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /translations/it/block-module.po 1.8
Date: January 20, 2005 - 00:09
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /translations/it/aggregator-module.po 1.10
Date: January 20, 2005 - 00:09
User: michelef
Drupal 4.5.2 translation; complete.
----------------------------------------------------------------------
File: /modules/copyright/copyright.mysql 1.2
Date: January 19, 2005 - 23:42
User: veridicus
Removed column COMMENTs because they're causing problems for MySQL 3.23
----------------------------------------------------------------------
File: /modules/copyright/copyright.mysql 1.1.2.1 DRUPAL-4-5
Date: January 19, 2005 - 23:23
User: veridicus
Removed column COMMENTs because it appears to be breaking in MySQL 3.23
----------------------------------------------------------------------
File: /modules/album/album.module 1.1
/modules/album/readme.txt 1.1
Date: January 19, 2005 - 22:51
User: weitzman
Personal image galleries. Users may create as many galleries as they wish
----------------------------------------------------------------------
File: /modules/og/og.module 1.1.2.23 DRUPAL-4-5
/modules/og/readme.txt 1.1.2.9 DRUPAL-4-5
Date: January 19, 2005 - 22:42
User: weitzman
reworked image galleries. the bulk upload (bu.module) is no longer needed.
----------------------------------------------------------------------
File: /modules/og/og.module 1.27
/modules/og/readme.txt 1.10
Date: January 19, 2005 - 22:42
User: weitzman
reworked image galleries. the bulk upload (bu.module) is no longer needed.
----------------------------------------------------------------------
File: /modules/book.module 1.280
Date: January 19, 2005 - 22:13
User: dries
- Patch #15843 by Ber: in book-pages node forms we use a delta of fifteen (-15 to +15) but in the book-outline admin we dont dewfine this, resulting in a default delta of ten. This should be consistent and thus both 15.
----------------------------------------------------------------------
File: /modules/massmailer/po/massmailer-module.pot 1.1.2.1 DRUPAL-4-5
Date: January 19, 2005 - 22:08
User: goba
adding translation template as gsuveg asked for it
----------------------------------------------------------------------
File: /includes/menu.inc 1.74
Date: January 19, 2005 - 21:57
User: dries
- Patch #9477 by JonBob: improved handling of user-specified paths.
----------------------------------------------------------------------
File: /modules/ldap_addressbook/README.txt 1.1
Date: January 19, 2005 - 21:11
User: olen
First commit. Read README.txt
----------------------------------------------------------------------
File: /modules/ldap_addressbook/ldap_addressbook.module 1.1
Date: January 19, 2005 - 21:10
User: olen
First commit to CVS, read README.txt and the comments in the code.
----------------------------------------------------------------------
File: /modules/contact_dir/contact_dir.module 1.2
/modules/contact_dir/fields.inc 1.2
Date: January 19, 2005 - 20:37
User: latpro
Applyed coding conventions
----------------------------------------------------------------------
File: /modules/taxonomy.module 1.152.2.6 DRUPAL-4-5
Date: January 19, 2005 - 20:35
User: dries
- Patch #15690 by Goba: the vocabulary node types checks in taxonomy.module are very vulnerable to having node types names as prefixes of other node type names %%%s%% as it is there with %%blog%% will match a lot more, then just this simple node type. Since the node types are stored in a comma separated list, the solution is to search for 'blog' or '%%,blog,%%' or 'blog,%%' or '%%,blog', that is matching only for that node type, or matching that node type in a list, or at the beginning of a list, or at the end of a list. It does not look elegant, but this is the solution for the format used.
----------------------------------------------------------------------
File: /modules/livejournal/INSTALL.txt 1.1
/modules/livejournal/livejournal.module 1.1
/modules/livejournal/README.txt 1.1
Date: January 19, 2005 - 19:46
User: themike
Created the livejournal auth module.
----------------------------------------------------------------------
File: /modules/filter.module 1.51
Date: January 19, 2005 - 19:30
User: dries
- Refinements by Walkah, based on suggestions of Steven and myself.
----------------------------------------------------------------------
File: /modules/spam/CHANGELOG 1.32
/modules/spam/spam.module 1.34
/modules/spam/spam.pgsql 1.1
Date: January 19, 2005 - 19:27
User: jeremy
- spam.module
o converted " to ' within db_queries containing strings to properly
support postgresql (see http://drupal.org/node/15684)
- spam.pgsql
o postgresql script provided thanks to Zed Pobre (issue #15684)
----------------------------------------------------------------------
File: /modules/taxonomy_menu/CHANGELOG 1.7.2.1 DRUPAL-4-5
/modules/taxonomy_menu/taxonomy_menu.module 1.11.2.1 DRUPAL-4-5
Date: January 19, 2005 - 19:25
User: JonBob
Correcting "no posts in category" behavior.
----------------------------------------------------------------------
File: /modules/taxonomy_menu/CHANGELOG 1.8
/modules/taxonomy_menu/taxonomy_menu.module 1.13
Date: January 19, 2005 - 19:24
User: JonBob
Correcting "no posts in category" behavior.
----------------------------------------------------------------------
1
0
It appears that WordPress has a pretty killer spam killer plugin (ha!)
that we might take some hints (code?) from... Frankly, I think that us
open source CMS/blog apps should put our heads together and root this
problem out collectively. Why duplicate effort when we all need the
same tools?
>From http://unknowngenius.com/blog/wordpress/spam-karma/
*Spam Karma*
Layman's Explanation
Spam Karma works by running every new comment through a battery of
filters and checks. Each of which increase or decrease the comment's
'Karma' value. Depending on the final score, the comment is either:
* Approved
* Discarded silently as spam (no email is sent to you, unless you
specifically require it, but a digest is sent to you every X spams
deleted).
* Placed in Moderation mode. With the possibility for the
commenter to auto-moderate his own comment by proving he's not a
spammer (by filling a Captcha or checking a confirmation email).
This whole process insures (by order of priority):
* No deleted false positive (bad bad bad).
* Extremely few moderated false positives (annoying): uses Captcha
and email auto-moderation to keep these at a minimum.
* No published spam.
* very little spam held in moderation (must be destroyed directly:
really annoying to have to moderate it).
Further more, Spam Karma works in an intelligent way to automatically
update its filtering database and grow stronger with each spam it
catches…
In short: blocks spam with no unnecessary annoyance, for you or your
visitors. The way it should be.
The Detailed Explanation
For our more tech oriented friends, here are a few more insights on
the rather complex process used by Spam Karma to decide what's spam
and what's not. Each of the following filter is given a weight varying
on many factors, ranking from user-controlled values (e.g.: after how
many days is a post "old"?) to the credibility that can be given to a
test (e.g.: a missing header is less important than a blacklisted IP).
Mostly, Spam Karma looks at the following things:
* If the poster is logged in the current blog, and what his user
level is (e.g. automatically approve Admin posts).
* Presence of HTML entities (e.g. {, ʚ etc).
* Presence of a HTTP_VIA header.
* Proper use of the posting form (hash value must be present).
* Time taken to fill the comment (e.g.: if it's less than a few
seconds, most likely spam).
* Posting granularity. First time posters posting many comments at
once vs. old-timers (with comments previously approved by the admin).
* Previous diagnostic from WP's built in comment check (set on the
'Discussion' panel).
* IP and regex match for URLs contained inside the comment (small
weight only for non-URL text matching a URL regex).
* Realtime Blacklist (RBL) Server check for IP and URLs.
* Comment's age (e.g. penalize comments on very old post).
In addition to these filters, Spam Karma uses different treatments and
backup checks to insure it becomes better at stopping further spam and
that it never deletes mistakenly a legit comment:
* Ambiguous comments (that can neither be deleted or approved) are
given a second check: commenter is asked to solve a Captcha or use the
email auto-moderation (an email containing a hash to unlock the
comment is sent to the commenter's email address). If confirmed, the
comment's Karma is bumped up and the comment is either published or
held for further review, if not confirmed within a certain period, its
Karma is lowered and it is either deleted or kept into moderation (if
it was sufficiently high to begin with).
* When a comment is struck as spam, its IP and URL(s) are
harvested and submitted to the Admin for inclusion in the blacklist.
In the meantime, they are used as "auto-added" values, with a lesser
weight than permanent blacklist entries.
* When destroying a spam comment, it checks for recently posted
comments that match similar values and retroactively moderate them
(e.g.: a spammer could manage to slip X numbers of spams onto a blog,
but upon reaching a certain suspicious threshold, all the comments
would get retroactively moderated, then deleted).
* Spam Karma uses a central DB to retrieve IP and URL updates. By
default, it will query the DB automatically every 2 days (can be
disabled). Central DB can be configured. Each install of Spam Karma
can work as a sort of P2P relay in the update process (both fetching
updates and publishing its own updated list for others to grab).
8
18
20 Jan '05
Project: Drupal
Version: cvs
Component: file system
Category: bug reports
Priority: normal
Assigned to: Morbus Iff
Reported by: Anonymous
Updated by: Morbus Iff
Status: patch
In chatting about this with #drupal, I'm thinking that something more
than just "sane defaults" needs to be enabled. The patch I just
submitted still has one "fatal" flaw: it doesn't allow write
permissions for the FTP user. This was ultimately deliberate (more
chance of accepting the patch with less dangerous permission, and the
assumption that a Drupal-controlled upload also offered a
Drupal-controlled deletion), but still isn't ideal.
Unfortunately, with SuEXEC servers and various configurations, there is
no SAFE default: on one hand you're giving 666 to everyone because you
have to (wwwrun:nogroup) and on the other, 666 is too much (if you're
running under SuEXEC, then gangrene:users/640 is right, and 666 is
wrong).
I think the only way this will be truly solved is with user
intervention, which means umask settings for file/directory in the
"Files" section of admin/setting. This is also the same solution that
Movable Type uses, which allows two special settings in its mt.cfg:
# When creating files and directories, Movable Type uses umask settings
to
# control the permissions set on the files. The default settings for
file
# creation (HTMLUmask, DBUmask, and UploadUmask) are 0111; for
directory
# creation (DirUmask), the default is 0000. You should not change
these
# settings unless you are running MT under cgiwrap or suexec, or some
other
# scenario where the MT application runs as you; in addition, you
should not
# change these settings unless you know what they mean, and what they
do.
#
# DBUmask 0022
# HTMLUmask 0022
# UploadUmask 0022
# DirUmask 0022
#
# In addition to controlling permissions via umask settings, you can
also
# use the HTMLPerms and UploadPerms settings to control the default
# permissions for files created by the system (either as output files
or
# uploaded files). The only real use of this is to turn on the
executable bit
# of files created by the system--for example, if MT is generating PHP
files
# that need to have the executable bit turned on, you could set
HTMLPerms
# to 0777. The default is 0666. You should not change these settings
unless
# you know what they mean, and what they do.
#
# HTMLPerms 0777
# UploadPerms 0777
For our needs, we'd really only need a DirectoryUmask and a FileUmask
option. Is this an amicable solution to anyone? If I get you a patch,
will this be implemented in Drupal 4.6?
Morbus Iff
Previous comments:
------------------------------------------------------------------------
September 8, 2004 - 13:04 : Anonymous
Hi,-
> [rreading@tribal html]$ ls -l www/files
> total 12
> drwxr----- 2 nobody nobody 4096 Sep 8 12:22 pictures
> drwxrwxrwx 2 rreading users 4096 Sep 8 12:33 tmp
> drwxr----- 3 nobody nobody 4096 Sep 8 12:33 upload
the problem is very strange, and might even be a nasty drupal bug: As
of the CVS version we decided to let drupal generate the folders
itself, so that Joe User needs not to use ssh or ftp to make /configure
various folders.
So these were generated by PHP and thus have the wrong permission. The
user PHP is a differnet user in this case, and something that PHP
created is inacessible to us.
I am aware that this is sierverspecific, but its annoying enought for
me (and probably others) not to ignore.
Regards, Ber
------------------------------------------------------------------------
November 18, 2004 - 21:46 : dtan
Any update on this. . ?? I recently installed the 4.5 Head and the
problem still exists. Recommendations on how to actually change the
permission on the folder?
dtan
------------------------------------------------------------------------
November 28, 2004 - 10:53 : killes(a)www.drop.org
The apache user did create this directories. So it is natural that they
have the apache user "nobody" as owner. Drupal should be able to handle
this just file. Can we close this report?
------------------------------------------------------------------------
November 28, 2004 - 10:58 : Bèr Kessels
No, please do not close. Its a bug IMO.
Because a lot of (v)hosts do not put apache in the same group as the
FTP user. It will work, file uplaods etc will work for Drupal, but you,
as user, cannot access the files anymore by FTP.
But even worse, you cannot remove your drupal installation, without
intervention of root (or the server maintainer). I had two "empty"
domains with 30 MB of files taking up space for 3 months.
Another domain will not let me mirror (backup) anything because of
this.
------------------------------------------------------------------------
November 29, 2004 - 22:55 : svemir
If PHP/apache can create these folders, it should be able to remove them
as well. Perhaps an option somewhere to remove folders created by
Drupal? Maybe a button next to the place in administration where the
folder is specified. And also maybe the creation of the folders should
be optional in the first place...
------------------------------------------------------------------------
January 19, 2005 - 20:52 : Morbus Iff
This just bit me today too. Installed the banner.module, and ensured
that my files/ directory was 777, with the owner as gangrene:user.
Uploaded a new banner, and for various reasons, it didn't work. As I
started to investigate, I found that the files/banner directory, which
was "successfully" created (success determined by "I can access files
uploaded in that folder via a URL) was not visible to my FTP server (at
this point, proFTPd, though I've not yet tested on vsftpd).
One of ProFTPds feature is to hide folders that do not have the
executable bit set. The default permissions of Drupal is not to set
these, per file_check_directory in includes/file.inc. So, my newly
Drupal-created files/banners folder was given the permissions of (where
wwwrun and nogroup are the Apache user/group).
drwxrw---- 2 wwwrun nogroup 88 Jan 19 20:03 banners
Since there's no execute for everyone, and since the "gangrene" user is
not part of "nogroup", I was not able to see, access, or modify the
newly created folder. I had to manually issue chmod('files/banners',
0761) to even look at the blasted thing.
My recommendation is to change the file_check_directory chmod to 0771,
which should create drwxrwx--x permissions. The extra execute
permission on the "nogroup" is harmless, and allows ProFTPd to display
it (in this case to "nogroup", but also perhaps to the "users" group on
other systems), and the execute permission for everyone is absolutely
required for me to see it in under ProFTPD. These permissions are
giving any extra (or damaging) permissions to anyone, but merely
following the expectations of various FTP servers concerning "what a
directory is".
There's a similar bug related to uploaded files, but I've not yet found
the code for that one.
------------------------------------------------------------------------
January 19, 2005 - 20:55 : Morbus Iff
Grrrr... "these permissions are NOT giving any extra (or damaging)
permissions".
------------------------------------------------------------------------
January 19, 2005 - 21:12 : Morbus Iff
To revise my previous statement, it would be best to use perms 0765,
which adds "read" access to the "everyone" group. The correction is
simple: if we want to /see/ the folder in FTP, then we also want to see
/inside/ the folder via FTP. Again, I don't believe this change really
gives extra dangerous permissions to anyone, merely grants the same
permission to an authenticated FTP user (if a file upload can be seen
on the web by people who know its there, then the same access should be
applied to FTP users with the right knowledge [ie., un/pw]).
------------------------------------------------------------------------
January 19, 2005 - 21:29 : Morbus Iff
Alrighty, hunted down the file (not directory) related problem. Unlike
directories, which require us to enter a mode, file uploads are not
specified, thus they take on the default umask of the web server's user
(in my case, wwwgroup:nogroup, 640). This further causes problems with
FTP viewing because "everyone" has no permission (in my case, since I'm
a part of the "users" group, I can not view, modify, delete, mirror,
etc. files that have been uploaded through Drupal).
This has been tracked down to file_copy() (includes/file.inc) and the
following lines, which copy the uploaded file from the temp directory
($source) to the final destination ($dest).
if (!@copy($source, $dest)) {
drupal_set_message(t('File copy failed.'), 'error');
return 0;
}
My proposal is to add an explicit chmod after the copy, granting read
permission to "everyone", something to the effect of the following,
which will give read and write to the webserver process, read to the
webserver group, and read to everyone (ie., little old me, not of the
webserver group).
if (!@copy($source, $dest)) {
drupal_set_message(t('File copy failed.'), 'error');
return 0;
}
chmod($dest, 0644).
------------------------------------------------------------------------
January 19, 2005 - 21:40 : Morbus Iff
Attachment: http://drupal.org/files/issues/fileperm.patch (606 bytes)
Attached is a patch for Drupal 4.5.1 that implements these changes
(directory is set for 764, not 765 - the mode in my previous comment
was [another] error). Last time I contributed a patch, I created a bug
so please review extra carefully.
--
View: http://drupal.org/node/10658
Edit: http://drupal.org/project/comments/add/10658
1
0
20 Jan '05
>First of all it should be shared over a closed XML feed.
>We can use drupalIds and a special role to secure the ahraing (we dont
want
>spammers to learn from our tokens).
Why closed?
As previously mentioned, I'm in the process of migrating from geeklog.
Geeklog's solution is the SpamX plugin. I've used this from my HTTP_REFERER
stats plugin to filter HTTP_REFERER spam, and it's used by the comments
system to filter spam plugins.
Their approach is to use the Moveable Type system:
http://www.jayallen.org/comment_spam/
Which is an open text file listing blacklisted regexps. SpamX also allows
you to maintain your own individual blacklist, which is shared out to an
open xml file for other geeklog sites/MT to harvest.
Using a closed system working around drupal ids means you close the loop to
other systems. Why not make your block list public to all, import and merge
from other existing blacklists (including moveabletype, other drupal
personal lists etc) and allow people to harvest your entire merged list.
Keep the list big, public and contributed back to all sources.
What benefit to spammers get from seeing the list? They know their site is
blacklisted and buy a new domain? It'll soon be blacklisted again, plus
baysean (sp) filtering in Drupal may keep the new one off anyway.
Cheers,
Mike
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
3
2
On Wed, 19 Jan 2005 21:28:55 -0000, Michael Jervis <mike(a)fuckingbrit.com>
wrote:
> Tim:
>
>> You can find my current work in my sandbox.
>
> Hmm, well, you may be known enough in drupal for others to find your sand
> box, but I'm drawing a blank here. No taltman, tim or altman or other
> obviously named sandbox sub-dir.
Sorry, it's at
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/junyor/import/.
>> If at all possible, we should use the same framework for importation
>> scripts, so it's easy to make a new importer plug-in.
>
> If you have a framework, I'd like to take a look, so if you could point
> me
> the right way.
Constructive criticism is welcome.
--
Tim Altman
1
0
[drupal-devel] [feature] Improve functionality of block generation for book module
by andremolnar 20 Jan '05
by andremolnar 20 Jan '05
20 Jan '05
Project: Drupal
Version: cvs
Component: book.module
Category: feature requests
Priority: normal
Assigned to: nysus
Reported by: nysus
Updated by: andremolnar
Status: patch
Attachment: http://drupal.org/files/issues/book_module_4.patch (6.17 KB)
Sorry - would be nice if I removed some debugging code - ;-)
also previous patch also would have introduced a need for a change to
the menu table that isn't required yet.
This patch is a correct version
andre
andremolnar
Previous comments:
------------------------------------------------------------------------
December 9, 2004 - 06:12 : nysus
Attachment: http://drupal.org/files/issues/book_19.patch (4.85 KB)
Attached is a patch for the book module that does the following:
1) Allows book blocks to appear on any page at any time, not just when
a node from the book is being viewed.
2) Allows multiple book blocks to appear on the same page.
This functionality is achieved by the automatic creation of individual
blocks for each book when the book is created. Simply enable the
book's block to enjoy the benefits of 1 & 2 above. If the blocks are
not enabled, the blocks will appear only when a node from that block is
being viewed (the same way it works now).
------------------------------------------------------------------------
December 9, 2004 - 12:35 : andremolnar
Attachment: http://drupal.org/files/issues/book_19_1.patch (4.84 KB)
+1 This is great. A good many people have asked for something like
this, and I think its a nice solution. But in the end this isn't up to
me.
One minor error in the patch...
+ $result = db_query('SELECT n.title, b.block, b.nid FROM {book} b
INNER JOIN {node} n on n.nid = b.nid WHERE b.parent = 0');
b.block is not a valid field in this query. this updated patch removes
reference to it.
andre
------------------------------------------------------------------------
December 9, 2004 - 13:54 : nysus
Glad you like it and thanks for fixing that up. It was left over from
an older version of my patch.
------------------------------------------------------------------------
December 9, 2004 - 13:54 : andremolnar
Steve,
If I apply this patch, and I attempt to configure one of the newly
created blocks. I noticed that for some reason the block.module is
returning "true" at line 249 (of the block module)- and is creating a
form for module-specific configuration. But all that shows up on the
screen is the word "array".
Can you trace this back to see why - and maybe update the patch.
I can continue to test your changes - anything to help this patch make
it into core.
andre
------------------------------------------------------------------------
December 9, 2004 - 15:29 : nysus
Hmmm...probably because I tested my patch on my version of Drupal,
version 4.5.1. I'm having no problems. Are you using a cvs version of
Drupal to test. If so, I'll set up cvs on my site and track this down.
------------------------------------------------------------------------
December 9, 2004 - 18:53 : drumm
See http://drupal.org/node/12347 for information on how the block system
has been updated. When I saw that the elseif ($op == 'view') was taken
out I knew immedaitely that there was something weird about this patch.
------------------------------------------------------------------------
December 9, 2004 - 18:58 : nysus
OK, thanks for the tip. Sorry for the confusion. Still kind of new to
making open source contributions and it's easy for me to overlook some
obvious stuff like this. I'll fix this up when I get a chance.
------------------------------------------------------------------------
December 9, 2004 - 19:06 : Dries
Please do, because this being a new feature, it has no chance getting
committed to the DRUPAL-4-5 branch. The DRUPAL-4-5 branch is in
bugfix-mode. New features go into CVS HEAD.
------------------------------------------------------------------------
December 9, 2004 - 22:32 : Dries
There is quite a bit of duplicated code in the patch. Maybe it can be
simplified (using a function)? Either way, it is a little weird. I
haven't tried the path, and I'm not sure I understood the description.
It's somewhat vague. Is the book module exporting multiple blocks that
are nearly identical, yet have different display behavior? If so, why
not add a simple block configuration setting to the original book
block?
------------------------------------------------------------------------
December 10, 2004 - 02:51 : nysus
Dries,
Yes, there is some code that can be factored out and some general
cleaning up that can be done. It was a little tricky to write so I
left it kind of ragged around the edges until I'm sure there are no
bugs. It has worked very well on 4.5.1 but I obviously need to update
it to work with cvs. I'll be on that soon.
As far as what it does:
1) For every new book that a user creates, a new block is associated
with it. So if you create "Book A", "Book B", "Book C", you will get
three new blocks visible on the block administration page called "Book
A", "Book B", "Book C". The original "Book Navigation" block is still
there, too. The functionality of the "Book Navigation" block is not
affected at all by this patch.
2) If Book A's block is enabled, the block containing its menu will
appear not only when a node within Book A is viewed, but at all times
(unless the user suppresses it on certain pages with the "path"
feature). When any node is that is NOT in Book A is viewed, Book A's
menu still appears but it is fully collapsed. When a node that DOES
belong to Book A is viewed, Book A's Book menu expands accordingly.
3) The user can also enable Book B & C's block, and have their menus
appear in a block at all times as well.
4) If none of the book's blocks are enabled by the user, the module
will behave just as it did without the patch. That is, when the "Book
Navigation" block is enabled, the only time any book menu will appear
is when a book node is being viewed.
5) It's important to note (and this was the tricky part to write) that
if both the "Book Navigation" block is enabled and "Book A" is enabled,
they will play nice with each other and not do nasty things like create
the same book menu twice.
------------------------------------------------------------------------
December 10, 2004 - 05:51 : nysus
Attachment: http://drupal.org/files/issues/book_20.patch (5.37 KB)
Andre,
Attached is a new patch that will resolve the problem of the
block-specific stuff showing on the block configuration form.
Let me know if you spot any other bugs. If it looks good to you, I'll
go to work making the code look leaner and prettier.
------------------------------------------------------------------------
December 10, 2004 - 07:26 : nysus
Attachment: http://drupal.org/files/issues/book_21.patch (4 KB)
Dries, Andre:
Here is a new and improved streamlined version of the patch. Have a
look if you get a chance.
------------------------------------------------------------------------
December 10, 2004 - 08:11 : nysus
Attachment: http://drupal.org/files/issues/book_22.patch (4.15 KB)
Found a bug in the last version that would cause the block to jump to a
different location. I think this should do it. Everything appear to
work well (famous last words).
------------------------------------------------------------------------
December 10, 2004 - 14:49 : andremolnar
Steve: bugs appear to be gone, and I didn't run across any other
errors. This is functioning exactly as described.
everyone: I personally would encourage support for this functionality.
Book is a powerful navigation building tool in a site, not only with
its ability to move next and back through a hierarchy of pages - but
also its ability to build the appropriate navigation block without
further user intervention (unlike the admin features in the menu module
or taxonomy).
The most frequently cited complaint about the book module is its
inflexibility when it comes to when and where the block shows up. I
also frequently hear requests for the ability to show multiple book
blocks at the same time. Up until now the best alternatives suggested
required users to do a hack (e.g. build a custom block that calls such
and such a hook). Most abandon their request at that point because its
over their heads.
With this patch all those requests are covered and more. Now all books
can automatically have their own block and admins can easily decide when
and where each of those individual blocks show up (left right, up down)
and coupled with the new configuration features of the block module -
its very easy for admins to decide on which individual pages a block
will show up.
I would be interested what other have to say about this feature.
My only reservation (which is minor compared to the benefits of the
functionality offered) is that there is no way to turn this
functionality off. i.e. The default behaviour is to build individual
blocks for each book. If there could be a way to toggle this feature
on and off somewhere - it would be perfect. Still, AS IS - this is a
major improvement and offers great flexibility to admins and site
creators.
andre
------------------------------------------------------------------------
December 10, 2004 - 15:04 : Anonymous
Andre,
Thanks for the feedback on the usefulness of this module. Glad I could
pitch in and help.
I agree about the inability to turn the feature on/off and I was
thinking about that myself. I think it could easily be accomplished
by creating a checkbox in the "book navigation" block individual
configuration's settings. Call it "Enable individual book blocks."
When enabled, the individual book blocks will appear on the block
administration menu.
One question: Where would the state of this checkbox get saved? Has
Drupal moved away from serializing data in the data base?
------------------------------------------------------------------------
December 10, 2004 - 18:36 : Dries
I'm afraid that 'Enable individual book blocks.' is not
descriptive/clear at all. Are you suggesting a setting to toggle
between 'show block on all pages' and 'show block on book pages only'?
------------------------------------------------------------------------
December 10, 2004 - 19:45 : nysus
Dries,
No. Andre and I suggest a setting within the "Book Navigation"
cofiguration page, that would toggle whether or not individual books
appear on the list of all blocks on the block administration page.
Hence the name 'Enable individual book navigation blocks.' The help
text for this checkbox might read something like: "By default, a book's
navigation block is visible only when a page from that book is being
viewed. Check this box if you want more control over where and when an
book's navigation block is visible. You will then be able to control
the book's navigation block location and visibility settings on the
"admin/block" page."
Hope this makes it pretty clear.
------------------------------------------------------------------------
December 10, 2004 - 20:08 : Dries
I understand what you are trying to do, but not how you are trying to do
it, or how the setting is supposed to work. I guess I'll have to try it
when a new patch lands.
------------------------------------------------------------------------
December 11, 2004 - 09:52 : nysus
Attachment: http://drupal.org/files/issues/book_23.patch (5.02 KB)
Alright, fellas, I'm proud to unveil my crowning achievement in the open
source development world (no big deal to most of you guys but pretty
good for a hack like me).
Thanks for all the input so far. It's been helpful. I've streamlined
the heck out of it per Dries suggestion and I've created an option to
turn this functionality on an off per Andre's suggestion. Does this
look good to you guys? Anything else I have to fix or improve?
Thanks.
------------------------------------------------------------------------
December 11, 2004 - 13:02 : Dries
I tried the patch.
It works great but to me, the 'Give books their own block' settings
seems to be redundant. Why not export the current book navigation
block, along with an additional block for each book? Looks a lot
simpler to me.
I think I spotted a bug: orphaned book pages (or possibly book pages
that are unpublished) appear to be getting book navigation blocks.
------------------------------------------------------------------------
December 11, 2004 - 17:34 : nysus
I'll see if I can fix the bug. Might be tricky.
But I don't understand your recommendation to "export the current book
navigation block, along with an additional block for each book". Can
you expand on this thought?
------------------------------------------------------------------------
December 11, 2004 - 18:06 : nysus
Dries,
I am unable to duplicate the bug. I have three orphaned pages. I also
tried unpublishing some pages. But as far as I can tell, the patch
works as expected.
------------------------------------------------------------------------
December 11, 2004 - 19:00 : Dries
If you can't reproduce the problem, chances are my node/book table is
somewhat fubar.
As for the configuration option. I suggest removing it and to always
make these new blocks available on the /admin/block configuration
screen.
------------------------------------------------------------------------
December 11, 2004 - 19:52 : moshe weitzman
I am hoping that we maintain the option to keep the behavior where the
appropriate book block only shows up when its book page viewed. this is
a nice, tidy arrangement.
------------------------------------------------------------------------
December 11, 2004 - 20:03 : nysus
Yes, if you don't enable any of the individual book blocks, the a book's
block (i.e. navigation menu) will only appear when a page in a book is
viewed. In other words, you have the option to have the book block act
like this patch isn't even installed.
------------------------------------------------------------------------
December 11, 2004 - 20:54 : Dries
I guess I'll have to try the patch again, because I don't understand why
it works like this -- or at least, why it can't be made simpler.
------------------------------------------------------------------------
December 11, 2004 - 21:13 : nysus
Can you be more specific? Why it works like what?
------------------------------------------------------------------------
December 11, 2004 - 21:24 : nysus
Attachment: http://drupal.org/files/issues/book_24.patch (4.1 KB)
This patch reverses a change made in the last patch which required a
user to enable individual book block before they could enable any
individual book blocks.
------------------------------------------------------------------------
December 11, 2004 - 21:41 : andremolnar
As I mentioned earlier I am *fine* with either version of this patch as
long as it makes it to core.
But, as I said earlier, I clearly think the preference for admins would
be to have the option to enable or disable this functionality.
BTW - if this does make it in, I would be happy to create a Handbook
page that describes the new features - something like "how to build
robust site navigation using the book module". (on or after December
17th).
andre
------------------------------------------------------------------------
December 12, 2004 - 12:11 : Anonymous
I am not at all happy with these features. They are incosistant,
confusing and should use exising methods and UIs.
May main concern is the incosistancy: it is confusing, will require
extra attention with each core code change, adds extra logic to the
core, and is not re-useable.
so here are my questions:
1) why do we not use the menu system and apis to build and adminster
the trees? Saves code, does not add extra UIs, and gives users more
power.
2) why do we need that extra showing logic? a book block should not get
exeptional if clauses, it should use the existing path setting methods
on block admin. extra logic is confusing for administrators (hey, i set
the path so that the book-block should show up here, but it does not,
why?) we should really not provide extra logic in the block hook, but
should rather use default settings in block admin (the book could fill
the bookblock sql cells with custom paths, for example)
3) we should avoid extra UIs. We already have far too much, and far too
much different ones. Please rather improve the block admin, than add new
separate interfaces.
4) why do book blocks need al these expeptions in the first place? If
they are so exeptional, we could consider not using blocks, but
something else, like in-line book layout (pages with the index etc)
5) why did you not choose for a general, standard, block gerneation
API? that way modules, such as taxonomy, image gallery, weblinks,
article, etc can reuse it and introduce block gernation.
All that sayd, i like the idea of this functionality, but i fear for a
great useability downfall if we start introducing all sorts of
exeptions for all sorts of modules. Because now chances are very big
that taxonomy, image gallery etc will need to introduce other UIs,
other code, new methods and new documentation, if they too want some
sort of better block handling.
so a -1 from me.
------------------------------------------------------------------------
December 12, 2004 - 12:12 : Bèr Kessels
^^--- That was me (bèr kessels) forgot to log in.....
------------------------------------------------------------------------
December 12, 2004 - 12:34 : nysus
I'm not going to pretend I can argue if my patch does or does not fit
well into Drupal's larger architecture. My motivation for writing it
is that I had an immediate need to create an easy way to make it easy
for users to create menus.
I'll let others decide whether or not the patch has merit from the big
picture perspective. But if it doesn't, why not just use it for its
immediate benefits and then throw it away when something better comes
along?
------------------------------------------------------------------------
December 12, 2004 - 13:01 : Dries
My summary is this: +1 on the functionality, -1 on the implementation.
The code itself is good, but the usability/integration is not.
------------------------------------------------------------------------
December 12, 2004 - 13:13 : nysus
When you say "usability" is that from the user's perspective or the code
maintainers? I'm guessing it's the latter but I'm unsure.
What about the idea of using the patch until a more permanent solution
comes along? Yes, it's much better to live in a home with indoor
plumbing but why not use the outhouse while you wait for a toilet to
get installed? Or are there other considerations I'm overlooking that
would make this a bad idea?
------------------------------------------------------------------------
December 12, 2004 - 13:20 : Goba
nysus it is just generally against the Drupal philosophy to add
improperly implemented functionality until something better comes
along. There even used to be ocassions in Drupal releases, when some
functionality was removed (not fixed) for a release, because its
implementation was not adequate.
------------------------------------------------------------------------
December 12, 2004 - 13:55 : Dries
Usability for the user. The extra setting on the block configuration
page is both confusing and awkward. I don't understand why things must
be configured/enabled that way (see my and Ber's previous comments on
this issue).
------------------------------------------------------------------------
December 12, 2004 - 14:03 : nysus
Well, just for the record, I reversed that functionality per your
suggestion and uploaded the patch. The indiviudal book blocks now
appear automatically.
------------------------------------------------------------------------
December 13, 2004 - 13:56 : Bèr Kessels
Hi,
I am sure you can make not only simpler, but better usefull for admins
and users.
All you need to do is use the menus for this. i.e. make a menu entry
for each book page.
For each book make a menu on level 0, without a parent. that way they
become a seoprate menu, each with an own block.
it saves code, makes things more consistent, and most important, uses
drupal functionality where it should.
------------------------------------------------------------------------
December 13, 2004 - 14:50 : nysus
Ber,
Are you suggesting that for every single book page that a menu item be
created? That's really not practical. That was my main motivation
for writing this patch: to make it easy to put links, not necessarily
related to one another, into a block. Any more pages than 10 and the
sheer tedium of the job would prevent anyone from ever doing that. The
menu.module is great, but adding new menu items is far from quick and
painless. I just added about 10 to my menu for different taxonomies on
my site and it wasn't fun.
Plus, if you do as you suggest, there is also the problem of the book
showing up twice. It will be generated by the menu and then it will be
generated again by the book module which is programmed to design a
block. You'd have to put some logic in the book.module _block hook to
try to anticipate if a user has enabled a book in the menu. That
wouldn't be pretty code.
I'm all for putting automatic generation of book navigation blocks as
part of the menu module. It does make more sense to have it there.
But it forces me to ask the question: "Then why do we currently have
code in the book module that generates a menu? Shouldn't that belong
in the menu.module, too?"
------------------------------------------------------------------------
December 13, 2004 - 22:31 : killes(a)www.drop.org
I think what Ber is trying to say is that you can write a contrib module
that monitors the changes to the book table and creates menu items
automatically. nodeapi is your friend. I would also prefer this
solution.
------------------------------------------------------------------------
December 15, 2004 - 16:39 : Anonymous
"Then why do we currently have code in the book module that generates a
menu? Shouldn't that belong in the menu.module, too?"
Because it's old code. It would be nice if book.module generated this
block using its _menu hook, so that the admin would have a few options
in terms of configuration.
Plus, if you do as you suggest, there is also the problem of the book
showing up twice. It will be generated by the menu and then it will be
generated again by the book module which is programmed to design a
block.
No. The old code which manually builds a block in book.module would be
removed. Book blocks would only be generated by the menu.
This would also have the added benefit of allow the administrator to
easily place a book in an appropriate spot in the menu tree, while
still allowing the possibility of displaying it in a separate block.
Because of menu caching, I don't expect a large performance hit for
creating the menu items.
That was my main motivation for writing this patch: to make it easy to
put links, not necessarily related to one another, into a block.
It sounds like instead of (mis)using book.module, your time would be
better spent in a usability improvement to menu.module so it's easier
to do this.
------------------------------------------------------------------------
December 16, 2004 - 06:55 : nysus
Thanks for the feedback and input. I appreciate it. However, I would
also appreciate if you took more care to avoid the condescending tone
in your post:
It sounds like instead of (mis)using book.module, your time would be
better spent in a usability improvement to menu.module so it's easier
to do this.
It's really quite unnecessary and off-putting. Though it won't stop me
from contributing to Drupal in the future, I'm sure others would be
really turned off by such a patronizing comment and it could dissuade
them. I'd like the Drupal community to be a welcoming and friendly
place that will inspire people to contribute, not discourage them.
Thanks.
------------------------------------------------------------------------
December 16, 2004 - 10:07 : Bèr Kessels
nyesus,
Please do not start /that/ discussion here. :) Drupal community is
known fo being direct, maybe because of the big number of
western-Europeans attending, maybe because of other reasons.
No-one commented that you are wasting your time. But the commentor was
telling you somthing likethis:
"If you would follow the previous sugeestions, your added feature would
be much better appreciated, and will probably work much better for you
too".
He/she was by no means telling you to stop your silly coding, or
anything in that line. He/She only wanted to show you the obvious and
better direction.
We often deal with issues that add some feature, and a complete new UI,
because the author does not like, or cannot use the existing UIs and
features. This is nogt good, because if that same author would have
spend his/her time on improving that existing functionality or UI
(improving is not neccesarily the same as extending!!) that code and
time would benefit all much better.
Thats what the commentor tried to say. And so is it here: If you
dislike the way the books handle the blocks, and if you do not want to
use the menu, because you do not like its UI, then do not add another
UI and more features, but rather merge these, and improve the parts (in
the menu) you dislike.
------------------------------------------------------------------------
December 16, 2004 - 10:35 : Dries
We can worry about the menu integration later. Let's focus on the new
option's usability/interaction design first.
------------------------------------------------------------------------
December 16, 2004 - 14:51 : nysus
I understand what the commenter was saying and like I said, I appreciate
and understand it. I'm not upset and I'm not looking for an argument, I
was just being direct as well. :) As part of the Drupal community
(albeit a minor player), all I'm saying is that I would like to see
folks not have a tin ear to the humanity in all of us. It will help
make Drupal an even stronger community and attract even more talented
developers.
Human interaction is part of the development process. Whether we like
it or not, we must cope and deal with it.
------------------------------------------------------------------------
December 18, 2004 - 09:54 : Dries
I thought some more about this and am starting to believe that
integration with the menu system should take priority. Here are common
cool scenario's:
I want to create a separate navigation block for the 'Drupal
handbook'.
I want to add a menu item called 'handbook' to the user block. That
is, I want the book navigation to be part of the existing user
navigation block.
I want to add a menu item called 'handbook' to the top-level
navigation menu.
How would that work from a user's point of view? What do I have to
click and where to configure this?
------------------------------------------------------------------------
December 21, 2004 - 18:47 : andremolnar
I was actually thinking about the same thing last night (must have been
something in the arctic air).
2. I want to add a menu item called 'handbook' to the user block. That
is, I want the book navigation to be part of the existing user
navigation block.
3. I want to add a menu item called 'handbook' to the top-level
navigation menu.
This is already possible (to a certain extent) with the current
Book.module and Menu.module - A 'Books' menu item is created in the
user navigation by having the Book.module enabled. Menu.module allows
you to enable/disable this menu item. Menu.module also allows you to
re-name this menu item. But, this only helps if you only intend to
have 1 book (or else the name 'Handbook' is misleading if the user
finds more than 1 book listed). - so this isn't good enough (or is
it).
1. I want to create a separate navigation block for the 'Drupal
handbook'.
This is what I was trying to figure out. Not just this, but a
different way to do what Nysus was attempting. i.e. create a menu
block for each and every book that is created. There is a way to write
code that would (re)build a 'custom menu' on every add/edit/update to a
book page - or book outline update. Custom menu's automatically have a
block created for them. But, this I think would be a misleading use of
the 'custom' menu - as the menu would not be custom if they are a part
of core.
So, I would think that two new constants could be added to the menu.inc
file - MENU_BOOK_MENU - and MENU_BOOK_ITEM - each would behave as custom
menu's, but would be reserved for books. These menu types should NOT
show up in the Menu.module administration - because the administration
of the book_menu items would be done by administering the book itself
(adding an item, removing an item, moving an item up/down in the
hierarchy, assigning parents etc.).
However, the blocks that the book_menus would create would show up in
the block administration (so users could enable/disable each block -
and decide where on the site they show up). The existing book block
logic would be removed.
So the logic would be:
If a creates a book in the book administration page - the Book.module
automatically creates a new MENU_BOOK_MENU
Any time a user adds to or updates or delets a book page - the entire
book menu is deleted and recreated based on the hierarchy defined by
the book itself.
The blocks for each book would show up in block administration.
Any thoughts - I know that this doesn't exactly address points 1 and 2
- but it could act as a first step.
Is this approach a bad idea? It would add special conditions for the
proposed book menu's - but books would be a special case.
Even if people don't like this solution, maybe it will give someone a
better idea. I'd love to hear them.
andre
------------------------------------------------------------------------
December 21, 2004 - 22:55 : Boris Mann
+1 to this andre
I had promised to put down my thoughts on this matter, as it relates to
1) primary and secondary links and how they are managed and 2)
auto-generation of primary/secondary navigation based on book outlines
So, for 1), we currently have functional-but-not-very-usable plain
textfields to manage primary and secondary links. I would like to see
menu.module used to control all navigation links, whether it is the
navigation block or primary/secondary links. What is needed:
a) default system menus labelled "primary" and "secondary" which would
store; this is where modules could insert navigation
b) support for full URLs (e.g. http://myexternaldomain.com) instead of
just path
2) if we got 1 working, and andre does his book menus, this could get
taken care of automatically. Basically, for brochureware/business/etc.
sites that have static content, you could have a root book as one of
the primary navigation links, and then the secondary links are
generated automatically.
------------------------------------------------------------------------
December 22, 2004 - 21:02 : Dries
I agree with Andre that the book module's integration with the menu
system needs to be worked on. I support any effort that makes it
easier to structure pages and that makes it easy to link pages/nodes
from within a menu.
However, I'm opposed to putting book module specific names in the menu
system (eg. MENU_BOOK_MENU and MENU_BOOK_ITEM). I can imagine a
handful of modules that want to maintain a menu tree (or part thereof)
so I'm in favor of generic names.
I'd have to read up on the menu system code, but last time I checked
there was a MENU_MODIFIABLE_BY_ADMIN flag. You could choose not to set
this flag for the menu items generated by the book module. Maybe it's
already possible to implement to implement Andre's suggestion without
having to modify/extend the menu system.
Are you exploring this path?
------------------------------------------------------------------------
December 24, 2004 - 10:01 : andremolnar
I've had a few spare hours to work on this.
I've started to cobble together a solution - but in doing so I
discovered a bug in the menu module (for which I will submit a seperate
issue - if one doesn't already exist).
The principal I suggested works. I added some code to the book module
that creates custom menu's (MENU_CUSTOM_MENU with MENU_CUSTOM_ITEMs)
for each Book that exists in a site. This is just as a proof of
concept - I chose this menu type to start with because they
automatically have a block created for them in admin/block (which is
ultimatly the functionality we want).
I ran a test and the menus are created as expected - the blocks are
also created. But when I tested the menu blocks by enabling them I ran
into a problem.
It seems as though the menu system does not expand/explode sub menu
items if the node type is book. I'm not sure why this is, and I
haven't traced the source code yet - I thought I would ask if anyone
has intimate knowledge of the menu system if they can point me in the
right direction.
No patch attached because until that problem is fixed this proposed
change won't fly :(
andre
------------------------------------------------------------------------
December 24, 2004 - 11:11 : Dries
Just a wild guess: maybe it doesn't work because the book module's URI
scheme is not hierarchical?
------------------------------------------------------------------------
January 7, 2005 - 10:45 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_1.patch (5.1 KB)
I finally took some time out to do some work on this. As mentioned in a
post to dev the problem I was having with menus not
expanding/contracting properly was some crud in my database. Once that
was cleared up my changes worked fine.
I am attaching a patch for comments and for the brave willing to give
it a test drive.
History: This thread and http://drupal.org/node/15198 and
http://drupal.org/node/15153
node/15198 has a patch that is required for this patch to work.
What this does:
Pretty straight forward.
Any time a user adds/updates/deletes book or book pages (including via
outline) - a function is called to create a new menu for each book.
Any existing book menus are wiped out and then the new book menus are
inserted - and the system menu is rebuilt to reflect the changes.
The menus created consist of type MENU_MODULE_MENU and
MENU_MODULE_ITEM. These menus show up in the menu/admin page so that
admins can be aware of them, but the menu types are not editable via
menu/admin (all changes are handled by the book module).
Since the menus are in the menu table, the menu_block() hook handles
the creation of the blocks for each of them. The blocks can then be
administered in the usual ways via the block/admin interface.
KNOWN ISSUE: (suggested solutions welcome)
Since the menu table is updated on every change to books - the blocks
associated with the menus are also recreated with default settings
(i.e. disabled, and with no path or throttle settings) requiring a user
to take an extra step and re-configure the book blocks for viewing on
their site. I think this is unacceptable. For the casual user of the
book module that only has a single book that doesn't change often, this
would not be a big deal. But, if anyone wanted to make use of book
module to handle dynamic site navigation this would create more work
than it saves.
Looking forward:
If the block generation issue can be solved in a tidy way, this patch
could allow users to use book to handle all their site navigation
generation needs.
Also, this patch could allow for the removal of a large chunk of code
in the book module dedicated to building its own block via the block
system. I left it there for now because I suppose there may be those
out there that want to have book.module work the way book.module always
worked (only show the book block when viewing a book page). Even so,
since each book would have its own block, an admin could specify when
and where the block shows via admin/block.
I would appreciate feedback. If nothing else I hope this gives someone
some new ideas.
I'll continue to work on the block regeneration issue.
andre
------------------------------------------------------------------------
January 7, 2005 - 10:47 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_2.patch (4.98 KB)
sorry - here's a patch with prefered line breaks.
andre
------------------------------------------------------------------------
January 7, 2005 - 16:47 : nysus
Andre,
I've been meaning to give this a throrough look when I get a chance.
Hopefully this weekend.
---Steve
------------------------------------------------------------------------
January 20, 2005 - 02:02 : andremolnar
Attachment: http://drupal.org/files/issues/book_module_3.patch (6.66 KB)
Here is an updated patch.
Same comments as followup 51 - except that the known issue has been
resolved.
This changes book module so that any action taken on a book, including
adding new books or book pages will create a menu in the menu system
for that book - and thus create blocks for those menus that can be
administered in the usual ways.
This is my first attempt at a major patch to core - comments are
welcome
I will be happy to update documentation once revisions to the code have
been taken care of.
andre
--
View: http://drupal.org/node/14120
Edit: http://drupal.org/project/comments/add/14120
1
0
>See, that's why my module is so small. I'm learning the process rather than
>coding anything important ;-)
>
>
My comment about your module being small was in no was a negative thing.
We like small, efficient code. I was merely saying that there wasn't
much to comment on.
Steven Wittens
1
0
Hello,
I'm trying to create a simple "blog it" menu option in one of my
modules, but I'm unclear on the proper way to do this. So far, the best
I've come up with is something ugly like:
$_GET['edit']['body'] = "this is a 'blog it' test.";
print theme('page', node_add('blog'));
Is there a proper way to do this, utilizing drupal_goto to fix the URI?
Perhaps the problem is that I'm not using a form button to get there...?
(Using a submit button is not an option)
Thanks,
-Jeremy
2
1
[drupal-devel] [feature] Proposed change to menu.inc that would allow modules to create custom menus
by andremolnar 20 Jan '05
by andremolnar 20 Jan '05
20 Jan '05
Project: Drupal
Version: cvs
Component: menu system
Category: feature requests
Priority: normal
Assigned to: andremolnar
Reported by: andremolnar
Updated by: andremolnar
Status: patch
I've uploaded the latest version of the patch to book.
http://drupal.org/node/14120
andre
andremolnar
Previous comments:
------------------------------------------------------------------------
January 6, 2005 - 07:13 : andremolnar
Attachment: http://drupal.org/files/issues/menu_inc_2.patch (2.65 KB)
See http://drupal.org/node/15153 and http://drupal.org/node/14120 for
discussion on this proposed change.
Patch is included here for further discussion (with the changes
suggested by Dries). A patch is forthcoming for topics discussed in
http://drupal.org/node/14120 which would make use of this patch.
Status to be changed to patch later if there are no objections
following discussion.
andre
------------------------------------------------------------------------
January 8, 2005 - 21:16 : andremolnar
Patch making use of this is now added to http://drupal.org/node/14120.
andre
------------------------------------------------------------------------
January 10, 2005 - 07:29 : andremolnar
Just realising that the rules for setting status to patch would allow
this to be patch since its technically ready to go. (and it might
actually get noticed if its on the dev list and patch queue).
andre
------------------------------------------------------------------------
January 11, 2005 - 06:47 : Dries
I'm OK with this patch but won't commit it yet until the book module
patch is ready.
--
View: http://drupal.org/node/15198
Edit: http://drupal.org/project/comments/add/15198
1
0