April 2007 - Development - lists.drupal.org

Interesting interpretation of Drupal table relationships
by Andre Molnar 01 May '07

01 May '07

http://webdevgeeks.com/schemaspy/tables/file_revisions.html I mean I guess humans are good and figuring out the context of vid but it looks like software isn't that smart. andre

2 1

aggregator2 update path complete!
by John Bransford 01 May '07

01 May '07

Ashraff wrote this I've taken a look at the proposed API, what exactly is it helping us do? I > > saw the groups, but the only thing that I understood is that contributing to > them would be advocating a need for an aggregation API, which frankly, I > don't think is needed at all (I'm open to other opinions though if they're > > valid and convincing). Would the current 3 or 4 aggregation modules have > been justified if they utilized an aggregation API? > > There is, however, one thing that I did see as very wrong. A module > developer can't just throw away his work, create an alternative module, and > > leave things behind as if they've never been. Creating a module that > everyone depends on is an ethical responsibility that needs to be > transferred to someone who can manage it when the original author can't work > > on it anymore. What has been achieved with leech could have also been > achieved by updating aggregator2 to become leech (albeit retaining its > aggregator2 name) without neglecting its users. > > I wanted to put in my two cents. Ashraf is exactly right here. I sponsored the development of Aggregator2 for a reason. The purpose was to create a publishing platform that could consume and display RSS content and had nothing to do with an API. I full well understand the difference so please save your lectures for someone else. None of the modules other than Ashraf's Aggregation module come close to providing the Aggregator2 intended functionality for 4.7x or 5.xx. He's done the exact right thing here. I'm sort of curious what the actual offense to the development process is supposed to be. I guess I'm missing the issue totally as it seems to be that he added to the confusion by creating another option. So what? I suppose its a matter of your place in the food chain. His Aggregation module works and incorporates the best aspects of Aggregator2 and extends it in ways that are excellent. Api work has little to now end user or immediate application for working sites. It is a different concern. If even one user has some need that is met by a solution like his Aggregation module then the effort was well worth it. But when the functionality is there and because he's already shown willingness to support the work an make instant and useful changes then I can see zero reason for even a murmur of complaint. The freedom of open source development is exemplifed by his ability to ignore the noise from the by the book crowd. (whatever the book de jour might be) and just get it done. In fact it is the best answer to all the other aggregation for contented modules in my estimation and is likely to be the basis for any API extension. The testing and knowledge gained from putting it to use has been invaluable. Thanks Ashraf -- Binserver http://Binserver.com http://NashvillesNews.net (615) 349-8841

2 1

Drupal db and transactions
by Gabriele Turchi 30 Apr '07

30 Apr '07

Hi all. During my experimental Oracle port, I've found a little problem, and I'm asking some comment (or even help). Apparently, the drupal db architecture is not designed to use db transactions. The only way of doing something similar appear to do an explicit lock on the needed table (function db_lock_table). This functionality appear (at least to me) linked to mysql, and compatible with postgres (ehm). Under postgres, a query is executed by default in "auto-commit" mode, but emitting a "BEGIN" command the following commands will be in the same transaction, until "COMMIT" or "ROLLBACK" command is sent. Under Oracle I can choose the auto-commit mode, but I have not the same flexibility I have under postgres. Even worse, I need the transaction control to bind large variables (LOB). For now, I can solve the problem with some "dirty trick" (like saving some sort of embedded status doing db_lock_table), but, for the future, I think that problem (clean transaction/lock support) should be addressed... Ok, anyway: next week I hope to be able to publish the first batch of patches for the Oracle support in drupal 5.1. I'll publish them via this mailing list as a request for comments/tests. If there is a better way, please notify me. Best Regards, Gabriele Turchi P.S.: I'm sorry, my English is alpha version...

3 2

Re: [development] aggregator2 update path complete!
by Ken Rickard 30 Apr '07

30 Apr '07

> IMHO, we should make it [compulsory] that every module developer post to the > mailing list before setting on a new module. This may prevent the > catastrophe of so much repeated modules and repeated code. I would agree with this, and we're all guilty of not doing it. Especially the aggregator clones. I had no idea you were trying to upgrade Aggregator2. That aside, the Aggregator API addresses two fundamental problems: 1) Too many people duplicating work without coordinating. That's a recipe for two things: extra effort and security holes. More code to review means more code that doesn't get reviewed properly. 2) A core Aggregator module that doesn't let other modules call or extend its functions. Take a look at the 3 or 4 functions that I had to copy out of Aggregator module to get user-submitted feeds working for MySite. That's what started all this discussion. As to this point, I think you are definitely in the minority here, since most of the other module authors have weighed in on the proposal. > I've taken a look at the proposed API, what exactly is it helping us do? I > saw the groups, but the only thing that I understood is that contributing to > them would be advocating a need for an aggregation API, which frankly, I > don't think is needed at all (I'm open to other opinions though if they're > valid and convincing). Would the current 3 or 4 aggregation modules have > been justified if they utilized an aggregation API? It will be much better for all Drupal users and developers if there is a common library of feed handler functions. Even better, that library would allow for the replacement / extension of those functions by other modules. >From a security perspective, it is infinitely better to have a single library for feed acquisition and validation, just like we have with file uploads. In fact, that's the perfect comparison -- all the file security pieces are hanbdled by file.inc, not contrib module developers. (We might even deprecate aggregator.module for aggregator.inc, but that's a separate issue.) There will still be room for those 3 or 4 contributed modules to add features, but their code weight will be much lower, since common functions will be handled in Aggregator. The proposed work is moving towards fixing core Aggregator because that's where the best, most stable benefit is for the largest user base. Providing upgrade paths for folks using dead modules is noble, and best addressed, I think, by some simple data conversion scripts. We can possibly include those in Aron's project.... - Ken Rickard agentrickard

2 1

aggregator2 update path complete!
by Ashraf Amayreh 29 Apr '07

29 Apr '07

Hello all, I'm following up on a thread that was started before which recommended that I (the aggregation module developer) provide an update path for the abandoned aggregator2 users. This is now complete :-) I don't think there's any need for me to remind developers to BACKUP everything (site + database) before attempting such a jump. You will find the details at the project's page and more details in the README file accompanying the module. http://drupal.org/project/aggregation With Regards, Ashraf Amayreh

3 3

The big locale cleanup
by Gabor Hojtsy 28 Apr '07

28 Apr '07

Hi, The following patch removes lots of cruft from locale.module and cleans up locale.inc a great deal. Let's open the door for more locale module improvements and functionality now that the batch API is close to hitting core and advancements on user defined string translation are made: http://drupal.org/node/139970 "This big update eases (at least my) maintenance work on locale module, so I would be very happy to get this in. A cleanup such as this was very due for locale module now, especially that we are adding more stuff in there very soon (think automated PO import, language block, user specified string translation, etc). Time is tight, so reviews of this patch are very much appreciated! Apply the patch, try out the forms, report problems. Let's get this in!" Gabor

1 0

Fwd: [drupal:unconed] /modules/taxonomy taxonomy.module
by Karthik 28 Apr '07

28 Apr '07

Issue nid? ---------- Forwarded message ---------- From: drupal-cvs(a)drupal.org <drupal-cvs(a)drupal.org> Date: 11-Apr-2007 14:47 Subject: [drupal:unconed] /modules/taxonomy taxonomy.module To: drupal-cvs(a)drupal.org User: unconed Branch: HEAD Date: Wed, 11 Apr 2007 09:17:53 +0000 Modified files: /modules/taxonomy taxonomy.module Log message: - Fix bad code in taxonomy.module (variable naming) Links: http://cvs.drupal.org/diff.php?path=drupal/modules/taxonomy/taxonomy.module…

6 11

Theme patches
by Dries Buytaert 28 Apr '07

28 Apr '07

Hello world, I'd like to invite/encourage you to help test and review the following issues: http://drupal.org/node/137211 http://drupal.org/node/137236 It would be great to get them in shape before Earl goes (or might go) absent for a while! So, could we give them some prime quality attention? If would be great to get this of our plate, so we can start focusing on other parts of Drupal. What's needed are some careful reviews and testing reports. Thanks! -- Dries Buytaert :: http://www.buytaert.net/

4 4

Scaling menu -- call to category module users
by Karoly Negyesi 27 Apr '07

27 Apr '07

Hi, If you have at least ten thousand menu items, please dump and (g)zip the menu table and mail me the URL (not the table itself). I have some changes which would allow the new menu system to handle such monsters quickly. However, I would like to test on real world test tables. Regards, NK

3 2

Re-entrant theme(), module theme functions
by Barry Jaspan 27 Apr '07

27 Apr '07

Gordon's message about theme('table') motivates me to post an idea I've been toying with. I'm sure someone will tell me that the latest theme patches include this already and if I'd reviewed them like Dries asked I would know that already... :-) Part 1. It has always seemed odd to me that modules cannot override theme functions. Why shouldn't I be able to write (e.g.) "stripe your table rows and columns with a wide variety of number and color choices".module? I can, but the install docs have to say "now copy this function into template.php unless you aren't using PHPTemplate in which case..." I'm sure others have raised this issue before. Here's my $.02 suggestion: function hook_theme_<funcname>($a1, ...) { return 'html'; } This would have a lower priority than mytheme_<funcname> and <themeengine>_<funcname> but higher priority than theme_<funcname>, and all modules implementing it would run in normal weight/name order. Part 2. If we have something like Part 1, we will end up with multiple modules implementing the same theme function. If any one of them ends with "return 'html'", that's the end. But I might want to just modify the args slightly and "pass it on" to the next function: function mymodule_theme_table($hdrs, $rows) { $rows[0][0]['#attributes']['class'] .= ' first; return theme('table', $hdrs, $rows); } Of course, this will result in a stack overflow... unless theme() is smart enough to remember where it is in the list of theme functions to call. Or maybe we could use return theme_continue('table', $hdrs, $rows); for this. Making theme() or theme_continue() smart enough for this can be easy and efficient. Comments? Barry

1 0