Snippetry comments & questions ... (DB, security, etc)

I’ve been working today on writing my own snippet ... it connects to a database, pulls out some data and then formats it nicely, and came across some little "gotchas" and had some queries..

My first gotcha was that my snippet kept on breaking MODx .. I eventually tracked it down to the fact that when I did my

mysql_connect(....)
mysql_select_db(.....)

I was inadvertently getting the same connection to the server as the main MODx connection - so I changed the DB with the select statement and then MODx couldn’t find any of *its* tables in the newly changed DB.

Secondly, I keep reading stuff like "put the DB username and password into a separate file outside your web area" so that any misconfigurations etc cannot cause the password-containing files to be exposed inadvertently... is this good advice?

Thirdly, I usually use MDB2 for my DB connections... for various local reasons I have had to revert to "mysql_connect" etc for this particular snippet, but when these are overcome I would like to go back to MDB2 - is there any issue in principle in doing this or should it just work?

Finally, is there any fear that my (PHP) variable names in the snippet can accidentally get mixed up with the names used by other snippets and/or MODx PHP variable names? I confess that PHP variable scope is something that I repeatedly confuse myself with and as the document is dynamically constructed, I wonder if at some intermediate stage a partially-constructed document might contain raw PHP from multiple snippets..

Thanks

Gordon

Is your snippet getting data from the same database as your MODx installation’s database? If it is, use the MODx dbapi. If not, make sure you give your database connection a different name ($MySnippet_db = mysql_connect... would be a good idea, if you aren’t using OOP).

Keeping login and password and other sensitive data outside of your web root is a good idea, but most shared hosting plans don’t allow a php script to access anything outside of the web root, so that won’t work in that case.

Yes, your snippet’s variable names could conflict with MODx. So name your snippet something like MySnippet, then have all of your variables named $ms_variablename, or even $MySnippet_variablename. Yes, it’s extra work, but it will eleminate any possibility of conflicts. It also helps if you practice good OOP, since that will help to protect your data from any outside conflict.

Same server, but different DB... I could move the data to the same DB, but would prefer not to.. On the other hand, I could move it to an entirely different SERVER as well...

$MySnippet_db = mysql_connect... would be a good idea, if you aren’t using OOP).

As I discovered, if you call "mysql_connect(..)" with the same arguments twice, then you are (silently) given THE SAME CONNECTION even if you give the connection variable a different name! So when I changed the "selected database" on what I thought was my new connection, it actually altered the "selected database" on the existing connection owned by MODx..

I have the freedom to move files out of the web root, so I guess I should do that..

Thanks for the comments about snippet variables.. is the snippetname_variablename a "recommended convention" for variable naming in snippets so that if everyone follows it then there will be no problems?

All the best

Gordon

Even with a different DB you can still use the modx api to call your database. The document parser class has a few fucntions for this, at least it did last time I looked (RC3)

getExtTableRows($host, $user, $pass, $dbase, $fields, $from, $where, $sort, $dir, $limit);
putExtTableRow($host, $user, $pass, $dbase, $fields, $into) (for inserts)
updExtTableRow($host, $user, $pass, $dbase, $fields, $into, $where, $sort, $dir, $limit)

I’ve never used them myself so I don’t know if they have the same problem you mentioned but it’s worth having a look at them. Browse through the parser source to find out the format of each parameter.

It’s good practice to use the API whenever possible especially if you are thinking of sharing your snippet with the community.

I believe you can use the DBAPI (or XPDO if you want an OO model for your tables) to get a connection to another db. At least that is the intention, and jaredc contributed some changes to make that possible over the last few months.

The functions getExtTableRows, putExtTableRow, and updExtTableRow have been deprecated since we split from Etomite and will likely be completely removed in the next minor release.