0.9.6 final sanity checks, please help

Quote from: OpenGeek at May 24, 2007, 08:33 AM

http://svn1.cvsdude.com/rethrash/tattoo/tattoo/branches/0.9.6/ as a fully-qualified URL.

Perfect! Thank you!

Update:

Today I implemented sottwell’s EditProfile snippet that allows web users to edit their profile from the website.

Everything in the provided snippet worked as expected. When a user changes their password, an email is sent to them with their login credentials utilizing the

webLoginSendNewPassword()

function inside of weblogin.common.inc.php

However, the [+surl+] placeholder was not being replaced properly with the site url, rather it was just a period? ( . )
Looking deeper into the function, I realized it was leveraging PHP_SELF:

Line #60:

        $message = str_replace("[+surl+]",dirname(PHP_SELF),$message);

I ended up having to change this line of code to the following to get it to work:

        $message = str_replace("[+surl+]",$modx->config[’site_url’],$message);

What’s interesting is that I did not experience this issue when initially creating the user, and I believe the same function/email is used in both places.

Regardless, I thought I’d relay the experience regarding the change of PHP_SELF to config[’site_url’] in weblogin.common.inc.php (Line#60) to get the link to the site to come through...

Thoughts?

I think that this issue should probably be fixed before the release:
http://modxcms.com/bugs/task/875

Unless there’s a compelling reason not to save all TV values whenever the document is saved (other than making things faster in general), I would just disable the dirty TV field logic for now. Some of my clients have been really confused and frustrated by this issue, since they try to save TVs over and over and over (expecting it to finally work sometime...it doesn’t). Ideally there’d be a way to know that the values have changed, but other than making yet another database query I’m not sure that there is one, although I haven’t researched it.

@ZAP: that can go in 0.9.6.1 and is already addressed in 0.9.7 -- I do not want to hold up this release for the additional work it would require to make those changes and test the effects.

Fair enough, but maybe xwisdom (who I think wrote the original code there) could determine pretty quickly whether disabling this might have any effect outside of this routine or not, and if not it could be patched now.

Quote from: ZAP at May 25, 2007, 10:52 AM

Fair enough, but maybe xwisdom (who I think wrote the original code there) could determine pretty quickly whether disabling this might have any effect outside of this routine or not, and if not it could be patched now.

Not likely, Raymond hasn’t really been active with MODx development for about a year now.

But I can tell you, that it will have some effect (though minimal in most cases): on save performance and on stability with high-traffic sites. Avoiding unnecessary writes to the tables (and/or cache files) can be important in high-traffic sites with lots of editors; you have to keep in mind that quite often updating rows is part of a larger operation that affects the entire site every time it is performed. This increases the potential for dirty reads (of the table rows or, more considerably, the cache files being written to disk) by other users, which can show up as invalid data, or even unpredictable errors.

Again, I’m not saying this shouldn’t be addressed in some way for the 0.9.6 branch, but I’d prefer to get 0.9.6 final out without waiting for the results of testing what I consider to be a significant change. If a workable solution is available a week later, and fully tested, I have no problem releasing 0.9.6.1 to include it.

This was BTW, another of the important factors in my development of xPDO; every object in xPDO keeps track of any fields that have been modified; there is no tracking required client-side.

Okeedokee. As long as it’s on the radar. It has caused some of our clients to bug me more than I like to be bugged.

That explains why Raymond didn’t reply to my PM...

Sirlancelot suggested using REPLACE INTO instead of INSERT for this query, which I think is available as of MySQL 4.1.0.