My suggestions are mainly for admin panel functions. musicalmidget recently approved a couple of resources I submitted that I would like to see in the core code. The main one is that the db->fetch_array() function in both db_mysql.php and db_mysqli.php use the fetch_assoc() method. There are certain SQL functions such as SUM that need to return via numerical arrays. I am not sure of the overhead that using the fetch_array() method would cause for large resultsets. Perhaps adding a second argument to the db->fetch_array() function would allow devs to have access to the functionality w/o affecting any current core code and would eliminate the chance for overhead.
example from db_mysqli.php
function fetch_array($query,$fetch_row=false)
{
if(!$fetch_row)
return mysqli_fetch_assoc($query);
else
return mysqli_fetch_row($query);
}
//or with the possible overhead
function fetch_array($query)
{
return mysqli_fetch_array($query);
}
usage:
$query = $db->simple_select( ..... );
$result = $db->fetch_array($query,true);
Since I'm not privy to the admin panel for the upcoming releases and hope I am not rehashing any old suggestions here. I noticed that some plugins need to modify the admin/index.php to add items to the menu. This is not a big problem to do, but I have no way of knowing which other plugin might be using the same menu index or item index. If the menu were stored in the db as a setting and cached similar to the plugin, a plugin dev could simply register a new item to the end of a current menu. A plugin requiring its own menu would be added to the end of menu index. Once a new plugin is installed, a fresh menu cache would be generated. This may require that no plugins would be approved that require modifying admin/index.php.
Lastly, I would like to see a hook to the xmlhttp.php functions w/o having to modify the file and adding a new conditional. Maybe making the xmlhttp.php a class and a dev could simply extend it.
mtjo Wrote:Lastly, I would like to see a hook to the xmlhttp.php functions w/o having to modify the file and adding a new conditional. Maybe making the xmlhttp.php a class and a dev could simply extend it.
Some hooks in there would certainly be nice. I needed
one for the quick edit.
I'd have to do a little bit looking into the change you've proposed, considering I've never had a problem with the current way, and I'm not sure I understand the difference completely
There are plugin hooks to add items to the menu. Plugins that don't do that haven't been updated probably.
I'm not sure if we should do that with xmlhttp.php because it's supposed to be a stripped down version of the MyBB Core, for returning results fast.
Tikitiki Wrote:I'd have to do a little bit looking into the change you've proposed, considering I've never had a problem with the current way, and I'm not sure I understand the difference completely
There are plugin hooks to add items to the menu. Plugins that don't do that haven't been updated probably.
I'm not sure if we should do that with xmlhttp.php because it's supposed to be a stripped down version of the MyBB Core, for returning results fast.
fetch_assoc() returns $db->fetch['some_var']
fetch_row() returns $db->fetch[0]
fetch_array() returns both. Aggregrate functions like avg() and sum() need numeric arrays. A good db acces layer should have this functionality. Perhaps you could just add fetch_row as its own function.
function fetch_row($query)
{
return mysqli_fetch_row($query);
}
As to the plugin hooks for the menu, could you point me to a tutorial on how to do that. My main issue with the hard coded menu is that I don't have any reference on which numeric indexes/items are already used other than opening admin/index.php and installing every available plugin to see whether it modifys it. Maybe just a sheet that lists these and any plugin would be assigned a registered value.
I am currently working on an ad manager that uses xmlhttp request to update banner clicks. Unless I callback thru a conditional hardcoded into xmlhttp.php, it returns a permission error. I am assuming this is by design and is a good thing for security. However, I want to add inline editing for certain items and this will require that I add conditionals for each one. This is what leads to bloating the functionality. By classing it, I would only have to extend it and call my own class and unless the user has installed my plugin, MyBB never need know that it is there. I'll try to play around with this this weekend to at least have something to show.
class newXMLHttp extends mybbXMLHttp
$var = newXMLHttp::getClick( $_POST['bannerID'] );
Also, while I have you attention for the moment, you might want to do a very small mod to the Axiom stylesheet. This isn't a bug but an IE issue. IE by default adds padding/margin to forms and if using the makehoptolinks() above a form, IE adds this additional margin/padding which make the button links seem to float. Simply adding "form { padding:0;margin:0; }" to Axiom/stylesheet.css fixes this issue with IE.
The new ACP has a totally new style so there's no use to change that now. As for the other changes, I'll talk to chris about it
As to the xmlhttp.php file, I have a solution. It's pretty obvious and I am not sure why I didn't do this before. All I had to do is create a file for my plugin, (ie: myplugin_xmlhttp.php) and include xmlhttp.php. I just point my xmlhttp request to new file and all is fine. Any chance I can get a peek at the new admin cp?
Can't you go SELECT SUM(col) as sum ... in your query to get the result from a mysql_fetch_assoc call?
DennisTT Wrote:Can't you go SELECT SUM(col) as sum ... in your query to get the result from a mysql_fetch_assoc call?
yep. We actually use it in MyBB that way
That didn't work, however, again I created and included a myplugin_db.php file with the needed mysql functions and that works. I guess I have an aversion to having to modify core files and pollute core mybb dirs with custom plugin files. With over 200 plugins available, that could get very messy. I want to be able to just upload a myplugin folder with all my support files to the plugins dir w/o requiring a user to add/modify files in the admin and root dir or wherever.
