August 2007 - Development - lists.drupal.org

Block PHP code returns true
by Tony Guntharp 31 Aug '07

31 Aug '07

All, I'm trying to show a block only if a particular cookie has been set. Is there any reason why this statement isn't working? <?php if($_COOKIE['FONALITYreseller']) { return TRUE; } else { return FALSE; } ?> thanks -t Tony Guntharp Co-Founder SourceForge.net fusion94(a)damagestudios.net 1-415-692-5507 1-415-680-5361

6 7

Advice Needed
by Mike Bishop 31 Aug '07

31 Aug '07

Hello all, Have a page that has a grid of information that needs to be easily editable and looking for suggestions on how to accomplish it in a drupal-esque way. There is no complex logic. Here is an example of what the page will emulate. http://skimadriver.com/snowreport.php Thanks! -- Mike Bishop

7 10

API module namespace reservation
by Daniel F. Kudwien 31 Aug '07

31 Aug '07

add1sun suggested me in IRC to post this question in the development list: I have an idea for a new module/project that would merge the functionality of approx. six different modules into one API-like module. There's no code yet, just the idea. Would it be too rude to already create the project on d.o, primarily to invite others to join and contribute to the project? I was thinking of this to protect the generic project namespace, because it is not yet occupied and IMHO it should be reserved for such an API module. Personally I don't like project registrations for modules that do not yet exist. However, there has been a similar case in the past with the "file" module/project/namespace. IIRC, it was used by an E-Commerce contrib module, which was useful for specific use-cases, but was not an API-like module for integration with other modules. Today I'm getting an Access Denied error on http://drupal.org/project/file, but that is *not* the point - I think you get the idea. The amount of contrib modules is constantly increasing. IMHO it is important for Drupal to reserve certain generic names for API extensions or even Drupal core extensions. On the other side, it obviously makes no sense to reserve any generic namespace, if there is neither an idea nor code existent. However, in this case there is an idea and most of the code could be merged from existing modules. Of course, the idea is not top-secret and I could have boiled this issue down to that particular case description. However, I would like to hear the basical opinion of the developer community, which might be added to the handbook pages, too. sun

7 7

Re: [development] (no subject)
by Shelby Lockwood 31 Aug '07

31 Aug '07

New pharmacy shop: http://qfpexu.thoughpose.com/?626095362779

1 0

MySQL query cache
by Hans Wolters 30 Aug '07

30 Aug '07

Hi all, With all the talking about caching I would like to ask some things. Currently I am using MyISAM tables. I have a small moodle site and was puzzled about the amount of memory being used. Tinkered with apache and enabled the mysql query_cache. The last tweak, the cache, is a MySQL only thing, PostgreSQL does not use it. Running the site a few days I kept wondering why it still does not really speed up. I think I now found part of the problem. There are some tables that are unfit to be used with the query cache. This is not due to drupal but more to the specifics the query cache is using. MySQL will optimize queries and will store select queries, when possible, in the cache. There for it does not need to recompile/optimize the query the next time it is called. Whenever a value is updated or inserted in a table the queries that are questioning these tables will be invalidated. For a few Drupal tables this will only generate extra cpu cycles without any benefit. Both the session and cache tables are updated when enabled in the config on almost every page view. A solution would be to add SQL_NO_CACHE after the selects on these queries. This however would break the queries for PostgreSQL. What would be the best way to submit a patch for this? Best regards, Hans

3 3

Re: [development] Modules that integrate non-GPL PHP apps violate theGPL.
by FGM 30 Aug '07

30 Aug '07

A commonly held view is that this is possible if, and only if, - they integrate using web services, and not direct invocations: it's commonly known as the "web services loophole". I don't agree with the FSF's interpretation that invoking independent PHP scripts constitutes linking, but that appears to be their stance. - the GPL is version 2, not 3 (to be clarified for GPL3: there was discussion about closing that loophole during the GPL3 design) ---- Original Message ---- From: jeff(a)viapositiva.net To: development(a)drupal.org Subject: RE: [development] Modules that integrate non-GPL PHP apps violate theGPL. Date: Thu, 30 Aug 2007 02:08:56 -0500 >For quite some time, it has been commonly understood in the Drupal >community that non-GPL software (like a third-party PHP message board > >system) can be integrated into Drupal legally by using an >intermediary 'bridge' module. After some in-depth emails with the >Free Software foundation's license gurus, it's become clear that this > >is NOT the case. > >Before going any further, I want to make clear that I'm not >expressing approval or disapproval of this: I'm just relaying the >conclusions that were reached after several days of discussion and >questioning with the FSF. > >Why do these modules violate the GPL? > >1) Under the FSF's accepted interpretation of the GPL, if a module is > >integrating Drupal and another PHP script, by calling one's APIs when > >triggered by the other for example, its purpose is to make a single >unit of software out of those parts. > >2) If multiple programs are operating together and functioning as one > >unit, all the pieces must be GPL'd. > >There are a lot of angles to approach the question from, but that's >what it boils down to. From a developer's perspective, if >debug_backtrace() can ever include functions from both Drupal and an > >external program, you've turned them into a single program. > >There are some potential solutions, though none of them are ideal. > >1) Add a notice to Drupal's license that clarifies that writing such > >modules IS explicitly allowed. This is problematic, however, because > >that would make Drupal non-GPL'd itself, a GPL variant, and we would > >require explicit relicensing permission by the authors of any GPL >code we wish to include. > >2) Remove modules that integrate with third-party non-GPL code from >the CVS repository, even if they do not *include* the aforementioned > >non-GPL code. > >3) Continue on as we are, and don't try to police these issues as >there are NOT likely to be any real complaints. (No one that I know >of is trying to SELL modules that integrate with non-GPL resources, >for example.) > >This is an important question for us, and other GPL'd projects, to >work through. Many GPL CMS's rely on integration components for >critical functionality (message boards and mass mailing are two >common examples). I can provide some detailed snippets from the >correspondence to those who want them, but I'm not sure it would be >useful for me to spend any more time corresponding. I exhausted my >list of questions, and I'm just summarizing what I found out. > >--Jeff

3 4

Re: [development] Modules that integrate non-GPL PHP apps violate theGPL.
by Eric Tucker 30 Aug '07

30 Aug '07

Going high level ... There are commercial enterprises now and probably more so in the future who want to build sophisticated sites with proprietary features and would love to use Drupal as their base platform. Also, there are existing products/services that people want to integrate with Drupal. Modifications and improvements to the Drupal core, core modules, or contrib modules under GPL can be necessary and will be thus be contributed to the community. However, it is unreasonable to expect companies who have proprietary algorithms in custom modules or even want to integrate with a third party API (or perhaps Google's nifty search-in-a-box) to let a CMS licensing constraint hold them back. Thus, these companies will turn away from Drupal if licensing does not permit it. Not that many years ago, companies like IBM contributed massive resources to move Linux into an enterprise-ready product and subsequently built a big consulting business around it. Linux was already very good. These companies helped make it fantastic. The world got a solid, very scalable, very versatile operating system. What's more, IBM actively promotes the use of all kinds of open source software. Solutions they sell to their customers run a mix of open source and proprietary and/or custom developed systems. And of course the end motivation is profit, but the benefit to the community is immense. I don't think it's a big leap to say that a CMS is not merely a single software product but will increasingly become more akin to an operating system. Ideally, every piece of code for a site somehow sits somewhere in that CMS. The CMS ties everything together. It's the kernel and the glue. The database is like the hard drive. The web server is like the CPU. If Oracle could never install their database product on Linux, would they use Linux? If a hot new site wants to build or integrate a proprietary map API, would they use Drupal? I am all for a GPL-like license for the core, but I believe the long term interest of the Drupal project is best served by ensuring that third party modules can be developed with their authors choosing the license that is best for them much like developing an app that happens to run on an operating system. Let's make sure that the ability to build third party modules under any license stays that way. Eric ----- Original Message ----- From: "FGM" <fgm(a)osinet.fr> To: development(a)drupal.org Sent: Thursday, August 30, 2007 4:06:06 AM (GMT-0600) America/Chicago Subject: Re: [development] Modules that integrate non-GPL PHP apps violate theGPL. A commonly held view is that this is possible if, and only if, - they integrate using web services, and not direct invocations: it's commonly known as the "web services loophole". I don't agree with the FSF's interpretation that invoking independent PHP scripts constitutes linking, but that appears to be their stance. - the GPL is version 2, not 3 (to be clarified for GPL3: there was discussion about closing that loophole during the GPL3 design) ---- Original Message ---- From: jeff(a)viapositiva.net To: development(a)drupal.org Subject: RE: [development] Modules that integrate non-GPL PHP apps violate theGPL. Date: Thu, 30 Aug 2007 02:08:56 -0500 >For quite some time, it has been commonly understood in the Drupal >community that non-GPL software (like a third-party PHP message board > >system) can be integrated into Drupal legally by using an >intermediary 'bridge' module. After some in-depth emails with the >Free Software foundation's license gurus, it's become clear that this > >is NOT the case. > >Before going any further, I want to make clear that I'm not >expressing approval or disapproval of this: I'm just relaying the >conclusions that were reached after several days of discussion and >questioning with the FSF. > >Why do these modules violate the GPL? > >1) Under the FSF's accepted interpretation of the GPL, if a module is > >integrating Drupal and another PHP script, by calling one's APIs when > >triggered by the other for example, its purpose is to make a single >unit of software out of those parts. > >2) If multiple programs are operating together and functioning as one > >unit, all the pieces must be GPL'd. > >There are a lot of angles to approach the question from, but that's >what it boils down to. From a developer's perspective, if >debug_backtrace() can ever include functions from both Drupal and an > >external program, you've turned them into a single program. > >There are some potential solutions, though none of them are ideal. > >1) Add a notice to Drupal's license that clarifies that writing such > >modules IS explicitly allowed. This is problematic, however, because > >that would make Drupal non-GPL'd itself, a GPL variant, and we would > >require explicit relicensing permission by the authors of any GPL >code we wish to include. > >2) Remove modules that integrate with third-party non-GPL code from >the CVS repository, even if they do not *include* the aforementioned > >non-GPL code. > >3) Continue on as we are, and don't try to police these issues as >there are NOT likely to be any real complaints. (No one that I know >of is trying to SELL modules that integrate with non-GPL resources, >for example.) > >This is an important question for us, and other GPL'd projects, to >work through. Many GPL CMS's rely on integration components for >critical functionality (message boards and mass mailing are two >common examples). I can provide some detailed snippets from the >correspondence to those who want them, but I'm not sure it would be >useful for me to spend any more time corresponding. I exhausted my >list of questions, and I'm just summarizing what I found out. > >--Jeff

3 2

Final recall: standardize LOBs handling for D6
by Edison Wong 30 Aug '07

30 Aug '07

After an indeed studying about differences between ADOdb, PDO and Drupal 6.x database abstract layer, it show that we are still missing a complete and standardized LOBs handling API, based on cross database compatibility concern (besides MySQL/PgSQL). Drupal 6.x existing database abstract layer provide db_encode_blob() and db_encode_blob() for BLOB handling only, as PgSQL require special API for BLOB encode/decode (In case of MySQL, it is a dummy abstraction, as MySQL seems BLOB data as like as normal string). BTW, this is not the complete picture of LOBs handling and its difficulties: besides BLOB, it is also a critical concern about limitation on CHAR/VARCHAR/CLOB (Character Large OBject) among most database; moreover, method of LOBs INSERT/UPDATE is also database specific. LOBs patch for Drupal 6.x (http://drupal.org/node/147947) will able to fill in this missing section, extent and complete our LOBs API functionality, with handy procedures. It should be the most common and strict forward solution when dueling with LOBs related difficulties. On the other hand, it shouldn't be a confusion for normal MySQL users, as it is very closed to the case of existing db_encode_blob() and db_decode_blob() implementation. We shouldn't miss the chances, but our chances are waiting for this patch :) (To view the thread, please navigate to http://edin.no-ip.com/html/?q=node/302)

2 1

Advice Needed
by Caleb Gilbert 30 Aug '07

30 Aug '07

The other argument for cck/views integration, as opposed to 15 lines of code or whatever, is that once you get plugged into cck/views you have the added benefits of extensibility. That view/field/whatever can be extend by any number of modules, and when updates happen your data/functionality will just get swept along with the rest of the update (as opposed to having to revisit your code to make changes there to keep up with api's and such).

2 1

Why is Block table delta field only 32 chars?
by Jacob Singh 29 Aug '07

29 Aug '07

I spent a good long while trying to figure out why my 38 char delta block would show up in the admin_display but would not get assigned to a region. I realized that UPDATE ... WHERE delta= "full 38 chars" was not going to find my truncated entry created by _block_rehash :( Is there a reason to limit the length of this field? Should I submit a patch to check for this in _block_rehash and alert the user? Best, Jacob

5 5