adminSettings' was given in […]includes/form.inc on line 269.

is there are a class named taxonews_facade?
i told you to stop this facade idiocy
the class is simply taxonews
so array(taxonews', 'adminsettings')
also
this is the most undrupalish code i have seen in a long, long time

probably so
previous versions were probably more "drupalish", though.

we do not use class methods for callbacks, period

I know. I just tried to find a way to do it, and it works in D5. I'll try to find another way
the saddest thing is that, although, it throws two errors, the form still renders just fine
this being said, I think D7 will need a generic way for modules to be implemented as classes, and have methods as menu callbacks. but we're not there yet

edison got db_num_rows() removed from head? cool.
While you're refactoring the paginator, maybe someone should apply my optimization?
Maybe chx

modules are not classes

I guess it doesn't exactly use num_rows though…

talk to Crell

Ohh it does

hi@ al

I know, they're not classes, but I've made plans for my future versions, where most of a module is in a set of classes following existing ZF-like conventions, and just uses the hook system to link into drupal
seen crell
and the .module is just the glue linking to the class-based module

that's gross

oh ? sorry about that. I don't see why, though (seriously)

Drupal. does. not. use. the. class. construct.
views is a rare example but there is a good reason for it

drupal = 6, indeed

Drupal 7 will be a bit different but the day has not yet dawned when menu callbacks will be object methods
as I stated more than once

I'm not in a hurry

I am stepping up to this PHP5 talk at Barcelona to *counter* Crell flying away with objects

:-)
the workaround is simple, it's with the form system, and drupal_get_form not willing to accept array('someclass', 'somefunction') for a form

did dries actually commit anything that removes db_num_rows? it's still around…

i found that too…? i am planning to remove my blob post
*blog

he -fixed but didn't commit anything

he set it as fixed, but i can't get the CVS message
lol

I checked out head, it's still there.
I was gonna reroll my optimization to the pager, that would have been affected by this.

maybe it will commit when Dries free?
i think you can assume it is already commit. actually, we don't need db_num_rows() at all

I had an optmization that avoided an extra count(*) query in the pager, which used db_num_rows().

but based on benchmarking result, remove db_num_rows() can improve overall performance for around 5%

that's when you can restructure the code to not need it - I don't think that applies here.

i think you will still able to tweak pager, without db_num_rows()
would you mind to post some code? i would like to have a look too

http://drupal.org/node/135674
at the moment, the pager does two queries, one to figure out how many pages there are, and one to fetch the rows.
my patch removed the first one (sometimes), by running the actual row-fetch, and noticing if it returned less than the page size.
Which means it's the last page, so we know there are exactly pagenum+db_num_rows() items
No big deal, but it saves a bunch of those extra queries.
pagenum*pagesize + db_num_rows() rather
how does your patch work, if it doesn't fix all instances of db_num_rows?

i grep all core codes

pager.inc is in core
db_num_rows is in there

find . | xargs fgrep -nH 'xxx'

go look

studying your code

Hey, I'm not saying the idea is anything special, just that it needs to be considered.
ahh, it's only in my patch

ooo seems it is only in your patch ;p
thinking about other implementation…

thanks for your comments. hope i didn't distress you with my alien code

hint. keep one checkout. revert between patches. thus it won't get lost.

i've made another type of workaround and it works now
….and even passes coder.module review

thanks. I more-or-less do that for patching, but also have a "real working" checkout, which keeps my patches.
I'm a bit distracted fixing bugs in amarok right now

maybe this can be an option: $num_results = db_result(db_query_range("SELECT COUNT(*) (" . $query . ")", $args, $pager_page_array[$element] * $limit, $limit))

sorry, dinner calls! bbl

Yet another strange issue. I'm seeing random numbers at the top of large 404 pages when browsing through squid, anyone seen that before?
happens after the upgrade to D5, not on 4.7
argh, drupal is sending out HTTP/1.1 responses even when the client uses 1.0 .. squid apparently doesn't like that.
why do i always have to be the one who runs into issues like this? :p

ping

pong

a) if the db_num_rows patch went in then why is the last commit against taxonomy module is 4 days ago?
http://cvs.drupal.org/viewvc.py/drupal/drupal/modules/taxonomy/
b) your example is wrong
+ while ($node = db_fetch_object($result)) {
+ $output .= node_view(node_load($node-nid), 1);
+ }
+ if ($node) {
that if($node) should be if ($output) because $node is _guaranteed_ to be FALSE after that loop

a) i don't know why dries set it as fix but not yet commit… b) what's wrong with that example?

right?

db_fetch_array/object will return FALSE if no result fetched. so (db_fetch_object() return FALSE) == (db_num_rows() return 0) == FALSE

you are looping as long as db_fetch_object returns something
you stop when the expression iside while() is FALSE
that expression equals its right hand side
so again when that while finished $node is FALSE
its possible that there was a $node before
but when the loop ends, there is no trace of that

!? seems you are correct

unbelievable

thanks for your suggestion, it is on time :0
i will review it once again

now I need to review the patch
it's isset/empty again

trick question.. do 404/403s end up in the page cache for anonymous users?

menu is also broken.
menu.inc
it's the same thing again

i will fix them once

you need a variable like $is_more for menu.inc

i get your idea, and will handle them now. thanks for your advices

find a good name for it make it FALSE before the while ($item = and make it TRUE inside the loop
no I am not stopping because I do not want to go after the bugs introduced by this patch
aggregator_parse_feed , if ($item) , wrong, if ($items)
comment_render , tricky, might need use a control variable here as well
node_title_list , return $node ? change to return $items ?

if ($output)

system_update_179 , use control variable

sorry that i need some time. i get your meanings (very clear), but sorry that i will need some time for fixing them

sure. I am just listing them. return count($authmaps) ? $authmaps : 0; = no need for count, php will nicely cast empty array to false , nonempty to true, try it.
posted comments, off to the gym

thanks about that, you let codes become perfect

so many ppl were workin' on it i thought i do not need to interfere
i was wrong

hey chx
the server is back online

Anyone knows a good way to install modules in an installation profile that use other modules function in their .install file? I'm stuck.

just return after dinner break. already update the patch, and would you mind to give some advice again? http://drupal.org/node/163191#comment-287587

Drupal, database system, normal, patch (code needs review), 8 IRC mentions

thanks for your comment too

posting again - use a boolean flag not an int counter