At Bryght we have been using distributions (nee install profiles) for a
while now.
One of the things we found very necessary was to alter the defaults provided
by the install profile,
instead of just setting the variables during the initial install.
A lot of the time, we found it nicer to have programmatic defaults (ie: it
defaults to the site name provided
in the hosting database), but also it fixes the issue whereby hitting the
'reset to defaults' button resets
to the drupal defaults, not the defaults provided by the install profile.
The patch for this is here : http://drupal.org/node/25745
This also introduces the loading of a profiles/$profile/$profile.inc file,
which I feel is very important
for the install profile to be able to add code into the running
distribution.
I think we should also considering using a 'distribution' namespace, and
inserting the 'distribution' into
the module_list. This would allow distributions to do things like providing
custom _help hooks, and a
couple of other things.
I'm considering writing a simple input filter module to handle
internal links [1]. It would take paths like node/99 and prefix them
with the appropriate base_path. I have two questions:
1. Is there an official master list of input filter syntax somewhere
that I can consult to make sure I don't use syntax that tromps on
somebody else's existing filters? I was thinking of using something
like [ilink:<internal_path>] (for internal link).
2. Can anyone suggest an alternate solution to the problem I'm trying
to solve [1]? On a related note, I believe ideally, the Links package
[2] should handle internal links as well as external ... not sure if
that's the intention ... Scott?
Thanks,
Ray
[1] There seems to be no supported solution for including robust
internal links in your content (please educate me if I'm wrong here).
The problem is to find a way to create an internal link in my content
that will continue to work correctly without modification (e.g. like
menu paths do) when I move the site to a new path. See this thread on
the support list for a bit more background: http://lists.drupal.org/
archives/support/2006-07/msg00058.html
[2] http://drupal.org/node/72459
[drup-infrastructure seems to be bouncing me, hence cross-posting here]
http://www.clickdensity.com/ :
"clickdensity records the position of every click on a page, building
up a virtual heat map of visitor activity. But that's just the start.
It also provides user behaviour analysis, segmentation and tracking."
I think this is a wonderful opportunity to get some free usability
testing done : if we install it on drupal.org, the data generated can
be used in improving not just Drupal.org, but also the Drupal
interface, since we use most of the popular modules for Drupal.org
anyway. The only downside might be a few microseconds of loadtime per
user, but I think it's definitely worth that much.
--
http://www.arnab.org
http://drupal.org/node/77549
I am not going to re-hash everything I said there, but I need to say that
install profiles as they are now are not really adequate
for many of the things we hope to accomplish with them.
I have been building install profiles in one manner or another for 2 years
now, and that patch is part of what I found were the base
requirements of making install profiles work for us, and very likely anybody
who runs more than 1 site on an install.
>http://drupal.org/node/78164
+1 from me. I agree that 'profile' causes confusion and I also agree that
the term 'distribution'
fits exactly with what is being achieved.
Adam
-----------------------------------------------------------------
This message may contain confidential or privileged information,
and is intended only for the addressee or other persons entitled
to access the information. If you are not the intended or
authorised recipient of this message please notify the sender by
return and then delete it from your mailbox. Any dissemination,
distribution, copying or use of this communication without prior
permission is prohibited. Internet communications are not secure
and may be susceptible to data corruption, interception and
unauthorised amendment for which Pall Europe Limited does not
accept liability. Whilst we have taken all reasonable
precautions to ensure that this e-mail and any attachments have
been swept for viruses, Pall Europe Limited does not accept
liability for losses sustained as a result of software viruses.
Any views or opinions expressed are solely those of the author
and do not necessarily represent those of Pall Europe Limited
unless otherwise specifically stated.
Registered Office and Corporate Headquarters: Pall Europe
Limited, Europa House, Havant Street, Portsmouth, PO1
-----------------------------------------------------------------
I am adding a markup field to a Profile form but only want the field to show after a certain textarea. The idea is to use the links in the markup field to enter text in the textarea above it. I have set in the working code and have no problem with it but am questioning the fact that hardcoding this in seems to be the only way.
Is there a way of doing this using the FormsAPI? a grouping syntax? Something like show this field only if a related field is present?
Is there a hook for FormsAPI that would help?
TIA
Carl Mc Dade
____________________________
Web Developer for Hire
http://www.heroforhire.net
info(a)heroforhire.net
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
with all the excitement around $node->body (which i share -- way to
go, everyone!), and looking over http://drupal.org/node/64279
("Converting 4.7 modules to 4.8/HEAD") i stumbled into a question
that i don't have a good answer for, and no one in #drupal seemed to
know at the time, either:
in 4.8, i added a new function to the db_* API, db_table_exists(),
which is a portable way to find out if a given table exists in your
DB (i wrote mysql and pgsql versions). it's a potentially handy
method, especially for certain hook_update_N() operations if you have
to deal with some special/weird cases (what i wrote it for in the
first place), but i'm not sure it's relevant to document it in
#64279, since it's not really specific to "converting 4.7 modules to
4.8". nothing is potentially broken by this addition, no one *has*
to know the new function exists, etc. it's *certainly* not
CHANGELOG.txt worthy. however, if not in #64279, how are developers
supposed to know about new functions in the API like this?
1) assume they follow all the core cvs commits closely? ;)
2) spam this mailing list about it and hope everyone who might like
to know is subscribed?
3) ignore it completely -- if folks need a function like this,
they'll pour through the source or the doxygen and find it (assuming
it's named something intelligent).
do we have a place to document additions to the API like this?
do we need a sub-page off of #64279 for additions that aren't
specific to updating?
am i being crazy, and this should just go directly into #64279, after
all? ;)
thanks,
-derek (dww)
