| *** Joins: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) | 01:02 | |
| *** Quits: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) (Ping timeout: 258 seconds) | 01:38 | |
| *** Joins: Cupertino (~Cupez@unaffiliated/cupertino) | 02:25 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 02:32 | |
| *** Joins: Ragnor_ (~Ragnor@dslb-178-009-050-181.pools.arcor-ip.net) | 02:45 | |
| *** Quits: Ragnor (~Ragnor@dslb-178-009-050-181.pools.arcor-ip.net) (Ping timeout: 252 seconds) | 02:47 | |
| *** Joins: Rixie (~Rixie@188.177.20.182) | 02:57 | |
| *** Joins: kirillka (~Miranda@195.242.142.17) | 03:02 | |
| *** Joins: soustruh (~Miranda@firewall.czech-tv.cz) | 03:12 | |
| *** Quits: siebrand (~chatzilla@535392CA.cm-6-4c.dynamic.ziggo.nl) (Quit: ChatZilla 0.9.86.1 [Firefox 4.0/20110318052756]) | 04:20 | |
| *** Joins: rolfkleef (~rolfkleef@92.254.21.180) | 04:41 | |
| *** Joins: siebrand (~chatzilla@188.200.34.66) | 06:18 | |
| dhx1 | jreese: there was a reason for sending the original and updated bug (and then returning them both) | 07:57 |
|---|---|---|
| dhx1 | it allows a plugin to determine what changes will be made if the plugin does nothing | 07:57 |
| dhx1 | and it allows a plugin to overwrite those changes if needed (including the ability for the plugin to fake the original state of a bug so the notifications can be silenced) | 07:57 |
| jreese | ... I think that's a very hacky thing to do | 08:03 |
| jreese | if it wants to silence notifications, just do config_set_global() | 08:04 |
| dhx1 | the faking of the original state? | 08:04 |
| jreese | that way it's just a temporary override | 08:04 |
| jreese | as for faking original state, I think that's bad too | 08:04 |
| jreese | especially since plugins have no guarantee of what order they'll run in | 08:04 |
| dhx1 | actually I don't see where we return the original state | 08:05 |
| dhx1 | oh nm I was looking at 1.2.x | 08:05 |
| dhx1 | event_signal( 'EVENT_UPDATE_BUG', array( $t_existing_bug, $t_updated_bug ) ); | 08:07 |
| dhx1 | we're not doing anything with return values | 08:07 |
| jreese | ? yes you are | 08:08 |
| jreese | $t_event_updated_bug = event_signal( 'EVENT_UPDATE_BUG_DATA', array( $t_existing_bug, $t_updated_bu> | 08:08 |
| jreese | $t_existing_bug = $t_event_updated_bug[0]; | 08:08 |
| jreese | $t_updated_bug = $t_event_updated_bug[1]; | 08:08 |
| dhx1 | oh yeah | 08:18 |
| dhx1 | that allows you to cancel user field change requests | 08:18 |
| dhx1 | so a user may ask to change the priority to 'high' but your plugin may perform other checks that don't allow that to happen | 08:24 |
| dhx1 | and instead of a fatal error it has the option of automatically doing things | 08:24 |
| dhx1 | I'm not sure I like that idea much | 08:25 |
| jreese | well, ok, but they plugin shouldn't need to return the original state of the bug to accomplish that | 08:25 |
| jreese | I mean, I already have custom plugins doing that in 1.2 just fine | 08:25 |
| dhx1 | $t_text_field_update_required = ( $t_existing_bug->description !== $t_updated_bug->description ) || | 08:25 |
| dhx1 | required for things like that | 08:25 |
| dhx1 | admittedly there is quite a lot of code to fix there now I look at it again | 08:26 |
| jreese | still, it's one thing to pass the existing bug as a third parameter to event_signal, but to make plugins able to modify and return it imo is silly | 08:26 |
| jreese | esp since with the old behavior, where plugin sjust received the new state and a bug id, the plugin could query the original bug state just by calling bug_get() | 08:27 |
| dhx1 | the difference is that the bug hasn't been committed by the time EVENT_UPDATE_BUG_DATA is called | 08:28 |
| dhx1 | and we'd be moving towards passing the bug object by reference as we move to OO | 08:28 |
| dhx1 | so it's not an issue of performance | 08:29 |
| dhx1 | I do agree that returning the existing/reference bug is silly | 08:30 |
| dhx1 | I can't remember why I added both return types | 08:30 |
| dhx1 | I seem to recall it being in response to that method being used elsewhere | 08:30 |
| jreese | ok, so then if you change it to event_signal( "...", $t_updated_bug, $t_existing_bug ) I would be perfectly happy with it | 08:30 |
| dhx1 | and return the updated bug... :) | 08:31 |
| jreese | that way plugins only have to return the updated bug | 08:31 |
| dhx1 | yeah | 08:31 |
| jreese | either way, the whole reason this was all brought up is: bug_assign.php doesn't match bug_update.php in how it uses the events, so it needs to be brought in line | 08:31 |
| *** Joins: ericbarnes (~ericbarne@rrcs-98-101-76-249.midsouth.biz.rr.com) | 08:32 | |
| dhx1 | yep I see, I'll fix it now | 08:32 |
| dhx1 | does it have an issue #? | 08:32 |
| jreese | ummm | 08:32 |
| jreese | sec | 08:32 |
| jreese | let's go with no | 08:33 |
| dhx1 | ok no problem | 08:33 |
| dhx1 | bug_assign.php is likely deprecated by bug_update.php too | 08:35 |
| dhx1 | the idea was to try and standardise the code we're using to update bugs | 08:35 |
| dhx1 | because it was very different in parts before | 08:35 |
| jreese | ok, then if bug_assign.php is never used, it needs to be dropped as well | 08:35 |
| dhx1 | almost done | 08:46 |
| dhx1 | does the assign to dropdown need the "operation successful" redirect page? | 09:00 |
| dhx1 | I suppose it makes it clear to the user that their action was saved OK | 09:01 |
| *** Joins: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) | 09:02 | |
| dhx1 | jreese: it seems EVENT_UPDATE_BUG_DATA is returning an array with 2 objects anyway | 09:19 |
| jreese | ? | 09:20 |
| dhx1 | $t_event_updated_bug = event_signal( 'EVENT_UPDATE_BUG_DATA', array( $t_existing_bug, $t_updated_bug ) ); | 09:20 |
| dhx1 | var_dump($t_event_updated_bug); | 09:20 |
| dhx1 | die(1); | 09:20 |
| dhx1 | is there some place where the return values of events are specified? | 09:20 |
| jreese | that's because of the way you're triggering the event | 09:20 |
| dhx1 | ah figured | 09:21 |
| dhx1 | so removing the array :) | 09:21 |
| dhx1 | ok fixed | 09:22 |
| daryn | mornin | 09:23 |
| jreese | howdy | 09:23 |
| dhx1 | daryn: howdy | 09:23 |
| dhx1 | jreese: I take it event_signal() can accept variable numbers of arguments and the last one is returned in the default "do nothing" plugin event handler | 09:24 |
| jreese | no | 09:25 |
| jreese | well, yes and no | 09:25 |
| jreese | event_signal( event, parameters, static_parameters ) | 09:25 |
| jreese | the event naem is obvious | 09:25 |
| jreese | the parameters are passed to the plugin hooks, and in the case of chained events, represents the parameters that must be returned by the plugin for use by the next plugin in the chain | 09:26 |
| dhx1 | in that case it should be: | 09:27 |
| jreese | static_parameters is only used for chained events, and represents parameters that should be passed to plugin hooks, but won't change from hook to hook, and don't need to be returned by the plugin | 09:27 |
| dhx1 | $t_event_updated_bug = event_signal( 'EVENT_UPDATE_BUG_DATA', $t_updated_bug, $t_existing_bug ); | 09:27 |
| jreese | right | 09:27 |
| dhx1 | ? | 09:27 |
| dhx1 | aha | 09:27 |
| jreese | then the plugin's function would do something like: | 09:28 |
| jreese | function foo($event_name, $updated_bug, $existing_bug) { ... return $updated_bug; } | 09:28 |
| dhx1 | yep | 09:28 |
| jreese | also dhx1, have you seen the dev list emails regardin some upgrade/install issue in 1.2.5? | 09:29 |
| jreese | iirc you were the one who committed the patch that's supposedly breaking things | 09:29 |
| jreese | but I can't reproduce the issue | 09:29 |
| dhx1 | jreese: yeah probably ADOdb handling the _connect() call differently in MySQL/PostgreSQL backends | 09:29 |
| dhx1 | I'll check in a moment | 09:29 |
| jreese | ok | 09:29 |
| dhx1 | can't wait to scrap ADOdb | 09:39 |
| CIA-35 | Mantisbt: d * r73493e22ed81 / (2 files in 2 dirs): Remove unnecessary return value from EVENT_UPDATE_BUG_DATA | 09:47 |
| CIA-35 | Mantisbt: d * r79ffdb847a9e / (45 files in 2 dirs): Remove bug_assign.php (use bug_update.php instead) | 09:47 |
| CIA-35 | Mantisbt: d * r57db68ce737e /bug_assign.php: Delete bug_assign.php | 09:49 |
| jreese | dhx1: a) you didn't update the developer documentation, and b) I think it would make sense to have the standard UPDATE_BUG event use the same parameter order | 09:56 |
| dhx1 | I did :) | 09:56 |
| dhx1 | agreed | 09:56 |
| *** Quits: kirillka (~Miranda@195.242.142.17) (Quit: kirillka) | 10:01 | |
| *** Joins: tmckeown (~Adium@64.191.211.43) | 10:03 | |
| *** Joins: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) | 10:09 | |
| CIA-35 | Mantisbt: d * r7b456a546c24 /admin/install.php: Tidy list of database types in install script | 10:29 |
| CIA-35 | Mantisbt: d * r41fddb772b94 /admin/install.php: Remove MySQL database version check from install script | 10:29 |
| CIA-35 | Mantisbt: d * ra8864b082b1a /admin/install.php: Fix #12675: Do not attempt connection to non-existent database | 10:35 |
| CIA-35 | Mantisbt: d master-1.2.x * rc749c0cdd763 /admin/install.php: Tidy list of database types in install script | 10:36 |
| CIA-35 | Mantisbt: d master-1.2.x * ra4774043a804 /admin/install.php: Remove MySQL database version check from install script | 10:36 |
| CIA-35 | Mantisbt: d master-1.2.x * r1e1c073be272 /admin/install.php: Fix #12675: Do not attempt connection to non-existent database | 10:36 |
| jreese | dhx1: should that fix the issue that roland brought up? | 10:43 |
| *** Parts: rolfkleef (~rolfkleef@92.254.21.180) | 10:46 | |
| *** Dreksypoo is now known as JonMarkGo | 10:53 | |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 252 seconds) | 10:55 | |
| *** Parts: Rixie (~Rixie@188.177.20.182) | 10:56 | |
| *** Quits: Cupertino (~Cupez@unaffiliated/cupertino) (Quit: I give up...) | 10:59 | |
| dhx1 | jreese: yeah, but the original bug still remains (see my ML post, I'll try to fix it shortly) | 11:04 |
| *** Quits: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) (Ping timeout: 240 seconds) | 11:22 | |
| *** Joins: dhx1 (~anonymous@60-242-108-164.static.tpgi.com.au) | 11:29 | |
| *** Quits: soustruh (~Miranda@firewall.czech-tv.cz) (Quit: visit http://wormscesky.cz) | 11:57 | |
| *** Joins: Github (~Github@sh1-ext.rs.github.com) | 12:30 | |
| Github | mantisbt: master-1.2.x David Hicks * c749c0c (1 files in 1 dirs): Tidy list of database types in install script | 12:30 |
| Github | mantisbt: master-1.2.x David Hicks * a477404 (1 files in 1 dirs): Remove MySQL database version check from install script ... | 12:30 |
| Github | mantisbt: master-1.2.x David Hicks * 1e1c073 (1 files in 1 dirs): Fix #12675: Do not attempt connection to non-existent database ... | 12:30 |
| Github | mantisbt: master-1.2.x commits 0772787...1e1c073 - http://bit.ly/g4of2i | 12:30 |
| *** Parts: Github (~Github@sh1-ext.rs.github.com) | 12:30 | |
| *** Quits: JonMarkGo (~Jon@ool-18bfe16f.dyn.optonline.net) (Ping timeout: 246 seconds) | 12:34 | |
| *** Quits: deepy (~deepy@c83-248-154-79.bredband.comhem.se) (Changing host) | 12:40 | |
| *** Joins: deepy (~deepy@wrongplanet/deepa) | 12:40 | |
| *** Quits: siebrand (~chatzilla@188.200.34.66) (Ping timeout: 246 seconds) | 13:14 | |
| *** Joins: siebrand (~chatzilla@188.200.34.66) | 13:24 | |
| *** Quits: siebrand (~chatzilla@188.200.34.66) (Ping timeout: 260 seconds) | 14:37 | |
| *** Joins: giallu (~giallu@fedora/giallu) | 15:51 | |
| *** Joins: siebrand (~chatzilla@188.200.34.66) | 16:00 | |
| *** Quits: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) (Quit: Ex-Chat) | 16:03 | |
| *** Quits: siebrand (~chatzilla@188.200.34.66) (Ping timeout: 240 seconds) | 16:05 | |
| *** Joins: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) | 16:08 | |
| *** Quits: tmckeown (~Adium@64.191.211.43) (Ping timeout: 258 seconds) | 16:11 | |
| *** Joins: tmckeown (~Adium@64.191.211.43) | 16:14 | |
| *** Quits: tmckeown (~Adium@64.191.211.43) (Read error: Connection reset by peer) | 16:32 | |
| *** Joins: tmckeown (~Adium@64.191.211.43) | 16:32 | |
| giallu | daryn, there? | 16:56 |
| daryn | giallu, lo | 16:56 |
| giallu | hi :) | 16:56 |
| *** Quits: tmckeown (~Adium@64.191.211.43) (Ping timeout: 258 seconds) | 16:57 | |
| giallu | do you know if db_result should be killed or not? | 16:57 |
| giallu | all the db_prepare_* are amrked as deprecated | 16:57 |
| giallu | so I wondered | 16:57 |
| daryn | hm...not sure off the top of my head. let me see what paulr was doing | 16:58 |
| daryn | giallu, he's using pdo and modified db_result to call p_result->fetchColumn | 16:59 |
| giallu | ok. same here for now | 16:59 |
| daryn | would be nice to agree on an interface for db... | 17:00 |
| daryn | so either your work or paulr's wouldn't change the rest of the app | 17:00 |
| daryn | i guess database_api is the...adapter? | 17:00 |
| giallu | well. for now I'm keeping the current API | 17:00 |
| giallu | so no changes are needed | 17:01 |
| giallu | however, it seems db_num_rows is not really portable across backends | 17:01 |
| daryn | but it isn't a drop in change for both. | 17:01 |
| daryn | right, he came across the same issue | 17:01 |
| giallu | so I'm removing that one | 17:01 |
| giallu | I should feel guilty for doing basically the same work. too bad I stopped to care some time ago :) | 17:03 |
| *** Joins: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) | 17:03 | |
| daryn | heh | 17:03 |
| giallu | however, filter_api is killing me. a lot of db_prepare_* calls | 17:04 |
| daryn | yeah...i pretty much gave up on filter until the foundations are better. it just needs to be rewritten from scratch | 17:05 |
| giallu | possibly, but right now I need them to be functional. Don't want to keep manzen untestable | 17:07 |
| daryn | right | 17:08 |
| daryn | giallu, any thoughts regarding configuration? I've run across an issue where config_api is dependent on db and db is dependent on config. needs to be separated somehow | 17:08 |
| giallu | well. I think we need to have a configuration file with maybe 5 settings, all the rest in the database | 17:11 |
| giallu | just try to install wordpress to see what I mean | 17:12 |
| daryn | yeah...there are 30 'global_settings' some of which are regexes so would be more than 5... | 17:13 |
| giallu | hey, that's far more than I used :) but you know, I tend to dramatize... | 17:16 |
| giallu | how many do we use? | 17:16 |
| * giallu checking | 17:16 | |
| daryn | is there any reason they shouldn' t all be in the database? on install you have to specify db settings anyway | 17:16 |
| daryn | and configurations have access levels | 17:17 |
| giallu | grep '^$g_' legacy/config_defaults_inc.php |wc -l | 17:17 |
| giallu | 426 | 17:17 |
| daryn | so would prevent unauthorized users from reading them | 17:17 |
| daryn | yeah... | 17:17 |
| giallu | yeah. right now I can't think about any reason for not putting everything in the DB | 17:18 |
| daryn | jreese? | 17:19 |
| daryn | doh... | 17:20 |
| daryn | that doesn't fix my dilemma | 17:20 |
| jreese | iirc, the rationale for keeping certain values out of the database was to prevent "snooping" on critical values from custom functions and/or plugins, but imo I couldn't really care | 17:20 |
| jreese | the biggest reason I have for keeping configs in a file is because a) it takes a lot of effort to create a usable UI to edit all those options, and b) I like being able to grep the file for config options | 17:21 |
| daryn | right | 17:22 |
| daryn | either way db configs still require a file as config api depends on db access. i don't know what i was thinking | 17:23 |
| jreese | daryn: I think the biggest thing to note is that db api only relies on "config_get_global()", which doesn't rely on db api | 17:24 |
| daryn | right | 17:24 |
| jreese | the other option would be to make config_api only use the database, and extend db_api to be able to read the 4/5 values it needs from the config file | 17:25 |
| jreese | but the *real* problem with that sort of change is how to handle users upgrading from older versions | 17:26 |
| daryn | i think that one is easy... | 17:26 |
| daryn | install script require config_inc.php. adds db records for configs | 17:26 |
| daryn | that aren't db configs. db configs stay in config_inc.php | 17:27 |
| jreese | have fun implementing that :P | 17:27 |
| jreese | one more problem | 17:27 |
| daryn | i'll be done "shortly" :P | 17:27 |
| jreese | some of what the configs do atm is more than just static values | 17:28 |
| jreese | eg, $g_path and friends | 17:28 |
| daryn | most of the path stuff is moved out of config | 17:28 |
| jreese | daryn: just be careful, there are still cases where users need to be able to override the values that are guess/inferred at runtime | 17:29 |
| jreese | eg, some installs are accessed from multiple host/domain names, so they need to be able to define a canonical url for things like generating emails, while still using relative paths in hyperlinks | 17:30 |
| daryn | i think i'm ok for that one | 17:31 |
| daryn | only problem would be if they need to set a different base url and don't have access to the webserver config. | 17:31 |
| *** Quits: daryn (~daryn@h158.249.190.173.static.ip.windstream.net) (Quit: Ex-Chat) | 17:40 | |
| *** Joins: siebrand (~chatzilla@535392CA.cm-6-4c.dynamic.ziggo.nl) | 17:44 | |
| *** Quits: ericbarnes (~ericbarne@rrcs-98-101-76-249.midsouth.biz.rr.com) (Remote host closed the connection) | 17:49 | |
| CIA-35 | Mantisbt: giallu * r09aa4a0d919a /core/logging_api.php: Fix XHTML markup | 17:55 |
| *** Quits: giallu (~giallu@fedora/giallu) (Ping timeout: 258 seconds) | 18:05 | |
| *** Joins: Github (~Github@sh1-ext.rs.github.com) | 18:30 | |
| Github | mantisbt: master Gianluca Sforna * 09aa4a0 (1 files in 1 dirs): Fix XHTML markup - http://bit.ly/e3n2to | 18:30 |
| *** Parts: Github (~Github@sh1-ext.rs.github.com) | 18:30 | |
| *** Quits: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) (Ping timeout: 260 seconds) | 18:34 | |
| *** Quits: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 20:00 | |
| *** Joins: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) | 20:00 | |
| *** Joins: Dreksypoo (~Jon@ool-18bfe16f.dyn.optonline.net) | 20:26 | |
| *** Dreksypoo is now known as JonMarkGo | 20:50 | |
| *** Joins: tmckeown (~Adium@pool-173-73-138-227.washdc.fios.verizon.net) | 21:05 | |
| *** Parts: tmckeown (~Adium@pool-173-73-138-227.washdc.fios.verizon.net) | 21:14 | |
| *** Joins: tmckeown (~Adium@pool-173-73-138-227.washdc.fios.verizon.net) | 21:18 | |
| *** Quits: tmckeown (~Adium@pool-173-73-138-227.washdc.fios.verizon.net) (Quit: Leaving.) | 21:23 | |
| *** Joins: daryn (~daryn@h191.67.29.71.dynamic.ip.windstream.net) | 21:58 | |
| *** Joins: hardyNH (~hardyNH@c-24-128-17-162.hsd1.nh.comcast.net) | 22:02 | |
| *** Quits: daryn (~daryn@h191.67.29.71.dynamic.ip.windstream.net) (Quit: Ex-Chat) | 22:06 | |
| *** Joins: daryn (~daryn@h191.67.29.71.dynamic.ip.windstream.net) | 22:07 | |
| *** Quits: daryn (~daryn@h191.67.29.71.dynamic.ip.windstream.net) (Quit: Ex-Chat) | 22:44 | |
| *** Quits: hardyNH (~hardyNH@c-24-128-17-162.hsd1.nh.comcast.net) (Quit: hardyNH) | 23:47 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!