- Development - lists.drupal.org

Non-GPLed Icons in our CVS repo
by Gerhard Killesreiter 07 Oct '06

07 Oct '06

Hi there, there doesn't seem to have been any move to replace CC licensed icons by GPLed ones. I find this a bit disturbing and I think it shows much disregard towards the creators of the icons, the terms of our repository, the maintainer of said repository and/or all of the above. Since the maintainers of the contrib modules (I dont list the modules since I am not sure I'd get all of them) are not willing or able to act, I'll simply remove the icons some time next week. I hope the maintainers of the modules will see this as an opportunity to go and look for GPLed icons. Cheers, Gerhard Contrib CVS maintainer P.S.: Don't start another "can't we use another license for icons" thread.

2 1

Module retirement?
by AjK 07 Oct '06

07 Oct '06

Hi All, Quick(ish) question. I've recently taken over the Paypal_Framework (PPF) module from Jeff. Having looked over it, it's apparent it needs some hefty updating in the database schema department, mainly due to the fact the Paypal IPN specification has moved on a lot and the module hasn't. Anyway, cut to the chase. Lee McLoughlin (http://drupal.org/user/36398) has been working on an alternate Paypal system that clearly supersedes the current PPF module in terms of both functionality and compliance with the Paypal IPN specification. Lee recently got contrib CVS access and will be putting this module up for all to use (currently published on his own site at http://lmmrtech.com/lm_paypal_module_for_drupal) As Gerhard so often tries, with granting CVS access, to avoid duplication I too also take this view. But what's the developers community view on suggesting that such a long standing module advertises "Retiring, see .... module" on it's project page? It's hard to gauge a modules popularity but I can imagine that this particular module may be widely used (esp. given two other module, both lacking in TLC themselves). On a related note, I also maintain Janode, a "knock together" for something I needed at the time. Given CCK is on it's way to Core and it has a weblinks type, this is another class of module that really ought to retire and my time spent providing feature patches to the later if I want some functionality. Again, how wide spread is your module? The only real way I can consider finding out is putting a notice on the project page and asking the user community to place issues on an intended module retirement for their feedback/comments (now is a good time to do this to catch users coming to get Drupal 5 versions of a module). All my modules are Drupal 5 ready (except PPF) but should they continue given serious duplication exists? Right now I'm spending my free time reviewing patches and providing patches for Core to help move along the Drupal 5 release process. But, as time starts to free up somewhat, I'd rather be spending my time doing feature work on other stuff (or brand new work for things that just don't exist) than competing with them (esp. Core related things like CCK/weblinks). I don't want to ditch/retire a module on a whim but to sum up: what's a responsible position, as a module maintainer, to take where obvious (big) duplication is starting given you can see a better route (but may not be so good a route for the user community)? regards, --AjK (sorry, it wasn't so "quickish" at all and if replying please <snip> it where appropriate)

3 2

PHP tips n tricks
by Johan Forngren 06 Oct '06

06 Oct '06

Hi! I dare to consider myself a php developer, but I don't know about many of the small tricks one could use in the language. Eg: $bar = &$foo. Where can I learn more about this? Thanks, Johan Forngren

5 8

Re: [development] Controlling whether WYSIWYG editors are viewed - Forms feature request.
by Metzler, David 06 Oct '06

06 Oct '06

>Isn't this the exact reason that FAPI supports extensible element types via hook_elements()? Possibly, but I'm pointing out that there are different data types in Drupal core. These form elements don't have different element types, because by default they don't behave differently. That's one of the reason that modules like TinyMCE have to encorperate all these features to suppress their invocation in some forms. Not every textarea in core is meant for html data, so you have to get TincyMCE to turn itself off whenever there is data in a form that it could mess up. Custom element types imply different behavior. We could expect module developers to form alter every form in core, but that's a lot of work for module developers to be expected to go to, when their trying to extend existing functionality with form elements. I could see writing a form_alter hook that redefined all form element types with a particualar #datatype attribute to another and then implementing the new functionality in hook_element. Sounds like a recipe for flexibilty. In short I guess I don't think of hook elements as solving the same problem. Ultimately I think some of us are asking for some discernable difference between the "Sepecific Pages" textbox in Admin/Block and the "Footer Message" in admin/settings general settings. We want to turn tincymce on for one, but off for the other in some systemic way that doesn't require insane form_alter hooks, or other programming intesnive work arounds. I do believe that this will pave the way for improved usability within drupal core.

1 0

Re: [development] Controlling whether WYSIWYG editors are viewed - Forms feature request.
by Metzler, David 06 Oct '06

06 Oct '06

>There was a thread in the issue queue recently about adding a flag to textareas that the >module author could apply or not, which RTEs (TinyMCE, FCKeditor, etc.) could then hook >onto to decide where they should or should not be used. This got me thinking that most of the time the problem with the WYSIWG editor being displayed all the time was that a lot of the time it screws up data that wasn't supposed to be HTML to start with. I've posted an alernative solution here that I've detailed in the following issue: http://drupal.org/node/87806 Basically it's to standardize how we tell the forms api and therefor contrib modules, what kind of data is supposed to be in the text area. Works for Rich Text editors, Color pickers, CSS editors, etc.

3 2

Themes.net Deliciously Zen themes -- for anyone who might want them.
by Trae McCombs 06 Oct '06

06 Oct '06

Hi All, I really need to get to work on building up a site for my themeing contracting work, Portfolio [I'm unemployed presently]. I've tried to chip in and help the best I can by providing some leadership and code in the themes arena. Here are tarballs and screenshots of what I did (based on Farsheeds work): Plain Jane Version http://occy.net/tmp/dz-trae-0.0.7.tar.gz http://occy.net/tmp/dz-trae-0.0.7.png Bar at top version http://occy.net/tmp/dz-trae-0.0.6.tar.gz http://occy.net/tmp/dz-trae-0.0.6.png I wanted to make sure anyone who might want the code could get it. Trae -- Need a Drupal Themer? Contact me! Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com

1 0

Re: [development] Why Drupal 5.x must have built-in WYSIWYG Editor?
by Peter Wolanin 06 Oct '06

06 Oct '06

Do a search in the forums on this topic, and you'll see that the idea of having a rich text editor in coer has already been discussed many times. There was a discussion here: http://drupal.org/node/81297 of how to standardize a CSS tag to tell editors not to act in a certain text areas. I think this would be a simple but very useful advance. This requires, of course, the cooperation of the mainters of TinyMCE, HTMLArea, FCKEditor etc. TinyMCE can be disabled more precisely via a theme function, see : http://drupal.org/node/72940 http://drupal.org/node/68660 though obviously this isn't standardized across editors -Peter Date: Fri, 6 Oct 2006 16:44:01 +0800 From: "Drupal Indonesia" <support(a)drupal-id.com> Subject: [development] Why Drupal 5.x must have built-in WYSIWYG Editor? To: <development(a)drupal.org> Message-ID: <010701c6e923$a472c530$01020a0a@itmgr> Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Why Drupal 5.x must have built-in WYSIWYG Editor? General discussion ? Drupal 5.x Drupal-id.com - October 6, 2006 - 07:18 I am a web developer with long experience in PHP Nuke, OpenPHP, and Mambo/Joomla. After take a deep look at the Drupal source code and coding that available on TinyMCE and FCKEditor module, I can say that next Drupal version must has a builtin WYSIWYG Editor. Please CMIIW, but read my reasons first before you have different opinion: 1. Both TinyMCE and FCKEditor only find <textarea> then translate to their editor interface. Then how to avoid certain Textarea not converted? The anwer is not possible. What TinyMCE does only disable editor on certain page and FCkEditor will work if the textarea >= n rows.

1 0

frequent timeouts on drupal.org
by Augustin (Beginner) 06 Oct '06

06 Oct '06

Is the server having problems? A. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

2 1

Changes to your 5.0 .info files
by Earl Miles 06 Oct '06

06 Oct '06

Over the last couple of days, the core committers have given us some excellent UI changes which require some minor support in your module .info files: [Note: Actually, none of this is required]. 1) We now have dependencies. List dependencies in your module.info like so: dependencies = views [to make your module require views before it can be enabled]. You can list multiple modules, separated by a comma. 2) We now have package grouping on the module administration page. If your module is part of a multi-module package (ecommerce and CCK are super obvious choices) then adding: package = ecommerce is a good thing. Modules that are designed for these packages can also use these keywords. For now, if your module is basically a standalone module, it is best to leave this blank and let your module appear 'uncategorized', as a lone module in a package will not be terribly useful.

3 4

My site is under attack (trackbacks, spam and cpu usage).
by Augustin (Beginner) 06 Oct '06

06 Oct '06

Hello, I am curious: is anyone using the trackback.module and allowing incoming trackbacks? Spammers have a vicious script designed for Drupal, that submits spam trackbacks in a loop, every few minutes, 24/24h. Even though not ONE of their trackbacks has EVER been published on the site, once your site is entered into their registry, they'll never bother take it off. It seems the only human intervention is to ADD new sites to spam in the robot's registry, never to remove any. Even though I have disabled the trackback.module weeks ago (!!!), my logs are still flooded with "warning page not found trackback/$nid not found. " In such a situation, I wonder how anyone could be using the trackback.module for any length of time. My particular concern at this time is server resources. I know there is a spam module that can automatically delete spam trackbacks, but it won't solve the resources problems. My site hasn't had any new content for a week, and the Drupal cache should be working at its best, and the CPU load should be at its lowest. However, the opposite is true. --------------------------------------------- | For the week | For the day | | rank - % | rank - % | --------------------------------------------| cpu | 86th - 0.216% | 190th - 0.107% | hit | 504th - 0.032% | 543th - 0.030% | Bandwidth | 404th - 0.045% | 370th - 0.030% | --------------------------------------------- See the high cpu usage compared to hits and bandwidth. The relatively lower cpu rank for the day is only due to a server upgrade which rendered spamming impossible. Now, I have already noted a few weeks ago that the cpu usage of a Drupal site is higher than the cpu usage of other sites. Another Drupal site I have and which has never used the trackback module (and therefore never been entered in the spammers' registry) is showing the same pattern of a higher cpu usage. However, it is not as bad as this site. For the sake of the other web sites co-hosted on the same server, I'd like to drastically cut down on cpu usage. I'd like to add a directive at the top of .htaccess that ends straightaway any request to trackback/$nid (so that Drupal never gets bootstrapped). Would that work? What would I need to add to .htaccess? If you have some insights on the wider spam issue and trackback spam in particular, please do share. I repeat that the spam.module is not an option: it would increase even further the cpu usage when I want to minimize it. thanks, Augustin. -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

8 16