Hello developers,
I would like to join with quiz module developers, here a brief introduction
about me and my new ideas for quiz module
http://groups.drupal.org/node/19141.
I could see a new issues being created everyday by its users here
http://drupal.org/project/issues/quiz?states=all. I would like to know the
current development work regarding this module and the possible ways to get
started to contribute.
If you have any suggestions please post it here
http://groups.drupal.org/node/19141 will be a good reference for future.
--
Thanks a lot
-----------------------------------------
http://ubuntuslave.blogspot.com/
Helllooooo, devel list!
It's that time of the month again! (No, not THAT time of the month,
silly... the time when we roll an interim unstable release of Drupal 7
to keep people abreast of what's happening!)
Below are some of highlights from UNSTABLE-4 => UNSTABLE-5. For those
who like way too much information, I've also attached a copy of the
full output from cvs-release-notes.tpl.php showing all commits. http://drupal.org/node/224333#UNSTABLE-5
has the details of contributed module developer-facing changes.
Note: Patch Spotlight has once again been "upgraded" and is now part
of the "Community Initiatives" handbook. I think I'm finally done
moving it around now. :P~ Please check out http://drupal.org/community-initiatives/drupal-core
for important places to jump in, or to add your own itch that you're
interested in helping to scratch!
So, without further ado, here's a summary of what's been going on the
last month:
For developers:
===============
* The biggest news of course is we now have a fabulous Field API in
core! HOORAY! While there is still work to do, the initial patch and
several follow-ups went in, which allows fields to be attached to both
users and nodes. If you're interested in helping with this, please see http://drupal.org/node/361849
for a "jump off" point.
* Another big, exciting development is hook_page_alter(). Page
callbacks now return drupal_render()able arrays, which modules can
then modify before they are output. Some crazy, exciting stuff can be
done here.
* Lots of documentation fixes/improvements: Thanks to the inclusion of
API documentation in core, and thanks in part to our new "Novice" tag (http://drupal.org/patch/novice
), we've had lots of undocumented hooks documented, unclear comments
clarified, and incorrect docs corrected. Please keep those patches
(and issues) coming!
* Comment and Taxonomy modules are now truly optional and can be
uninstalled. In more radical news, *Block* module has also been made
optional. OoOoOOo, scandalous. ;)
* Performance improvements, including adding the ability to disable
anonymous sessions to help with the Digg/Slashdot effect, mammoth
hook_form_alter()s have been broken up to use
hook_form_FORM_ID_alter() instead, and stopping
filter_xss_bad_protocol from being called hundreds of time on each
page. There is definitely still some work to do, but we're getting
there!
* Error handling has been improved. Core now uses E_ALL error
reporting by default (which helps ensure squeaky-clean code), and
changing its sensitivity can be done from a settings page instead of
by hacking common.inc. ;)
* Nedjo organized a great virtual internationalization sprint, which
resulted in fixing of several annoying bugs (locale uninstall being
broken, all languages being active in language switcher block) and
made important in-roads to more complex features that will hopefully
be part of a future unstable release.
For users:
==========
* Locale interface has been **dramatically** improved. It now behaves
a lot more like the watchdog or node content administration screens do.
* The vocabulary edit form has been also visually simplified by
removing a bunch of needless fieldsets and the "weight" field. Ahhh...
* Lots of textual improvements, too. For example, "Input formats" are
now "Text formats" which help better describe what they are for.
* There are snazzy new forum icons! Hooray!
* Administration theme has been moved from under site configuration
where NO ONE ever finds it, to the bottom of the themes page where
people actually might. ;)
Catch you next month, Drupalistas!
-Angie
Hello Development,
I've been working on a patch that incrementally filters the permission
page - patch at http://drupal.org/node/229193 and demo at http://dmitrizone.com/229193.mov
.
The patch is pretty much ready to be reviewed, except for the fact
that webchick has an issue with how it degrades.
Currently, without JavaScript, the textfield for searching simply
isn't there, and you can't use the incremental filter.
Webchick would like it to be degradable. The issue with this is that
we already have a 100-line search algorithm for searching in HTML, and
we'd need another 150 or so search algorithm to do it server side,
which would actually be quite different.
CHX has an argument against needing a degradable version at http://drupal.org/node/229193#comment-1260194
:
"I think this is fine with working only if JavaScript is there. Drupal
works without JavaScript but with reduced functionality already. You
can not resize a textarea without JS for example. Autocomplete does
not work. This piece is similar."
What do you guys think?
Dmitri
Okay, I know that altering the structure of a core table is bad news. I do
not want to do that.
I have a module that keeps a copy of a file path in its own table. This is
de-normalizing the db. What I want to do is to change my table to just
carry the file ID and change the queries to JOINS. ThatÂ’s no biggie.
However, someone wants me to also be able to link to an external image. It
would not be hard for me to put that URL into the files table and get it
back with my normal query.
Would this be a legitimate use of the files table?
Nancy E. Wichmann, PMP
Injustice anywhere is a threat to justice everywhere. - Martin L. King, Jr.
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.176 / Virus Database: 270.10.24/1954 - Release Date: 2/15/2009 6:09 PM
Hello,
A while ago, someone (not me!) brought down our collocation server with a home
made script which had many queries like this:
SELECT * FROM ...
I.e. the script was indiscriminately selecting everything from the table even
though he might have needed only a few fields.
This created heavy traffic between the SQL server and the web server which
overwhelmed the platform. To be honest, I don't know the details (he might
have been needlessly transferring whole images stored in the DB or something
like this!)
In Drupal 6.9, I count 120 occurrences of SELECT * FROM ... , not including
SELECT COUNT(*) but including variations of SELECT n.*, pi.* FROM ... .
Wouldn't it be a good idea to explicitly tell which fields are needed, in
order to minimize traffic between SQL server and web server?
The SQL coding standards say nothing about this:
http://drupal.org/node/2497
Should SELECT * FROM be considered a kind of bug?
Should this whole discussion be a 'won't fix' ? (why?)
Or is this something worth considering in the issue queue?
Blessings,
Augustin.
Hello all,
in participation of the new project pages and navigation as envisioned
by Mark Boulton (see [1] and [2]), we added two new vocabularies to
the project pages on drupal.org.
We decided to add these in preparation of the new design so that we'd
have enough data by the time we launch the new drupal.org (and so we
can do proper performance testing of the Solr integration).
If you edit your project(s), you'll see the two new vocabularies that
I'm talking about, and how they relate to the designs in [1] and [2].
[1] http://drupal.markboultondesign.com/iteration11/download.html
[2] http://drupal.markboultondesign.com/iteration11/modules.html
Thanks!
--
Dries Buytaert :: http://buytaert.net/
Today i need a user reference on profile but cck solution dont attend
me so a build a patch to do it with profile module.
If some one have interesting on it i can port to drupal 6 too.
http://drupal.org/node/374098
thanks
Now that Field API is in core it is time to start using it. I have
an initial suggestion: change node body and teaser from special cases
to normal fields. I suspect this is going to be quite controversial
so I thought I'd get some feedback here before evening bothering to
start looking at the code.
This message is not about the details of the implementation; I'm sure
there will be subtleties and complexities to work. I'm just asking
about the concept.
Concept:
Remove all special processing for $node->body and
$node->teaser. Create two fields, body and teaser, both text
fields. Assign both fields to every existing content type with a
"body field" using the textarea widget. For existing nodes, as part
of the upgrade path, initialize the teaser field value with whatever
teaser would normally be generated automatically from the body.
Random thoughts:
- We will get to remove a bunch of code, much of it quite ugly, from
node.module.
- Sites that really want an auto-generated teaser can remove the
teaser field from a content type and use the text field's teaser
Display Formatter in the teaser context.
- This will mean removing the body field from the node and
node_revision tables, and creating a field_data_body table for it
instead. Don't worry about database query efficiency; that is a
solved problem (see http://drupal.org/node/368674)
- With $node->body and $node->teaser being normal fields, they will
not be available for overloaded use as the complete rendered output
of the node. Hurray! We can use $node->content =
drupal_render($node) or something like that.
- We might want to think about adding other fields to our default
content types. Perhaps Article should have a Subtitle field,
etc. This is a whole topic in itself.
Comments?
Thanks,
Barry
