I’ve done a little more work on tidying this up - specifically:
- integrating cipa’s cache fix
- all my original fixes
- fixing include paths so it uses the correct header / footer files rather than Modx’s default (due to include ordering in current Modx)
- fix error when restoring deleted items
- remove some styles that weren’t used, and ensure all images refer to current theme
These optimisations are only tested on 1.0.4, and assume the default 1.0.4 theme.
I’ve now uploaded this to GitHub rather than posting here, so there’s always a home for the current version rather than zips here:
https://github.com/ncrossland/ModX-Evo-dbEdit
Author:
ManagerManager plugin - customise your ModX manager interface
Rckt - web development, Sheffield, UK
Thanks ncrossland,
Following on git from now on
Hi,
This is really good - I need similar functionality for a current project, and am comparing this with phpmyedit.
I think in general both options offer something the other doesn’t e.g. this will include file browser integration out of the box, whereas considerable more effort with javascript would be required to get phpmyedit to do this.
The biggest problem with dbEdit for my current application is the timestamp handling as refered to earlier in this thread. I have two fields: ’votetime’ is set when the record is created and should never be changed after that, and ’timestamp’ is set to automatically update to the current timestamp whenever the record is updated. Whereas I can just set these to not be written to by phpmyedit, dbedit tries to write to them, even if set to ’readonly’. It also seems to always set the time component to 00:00:00.
A minor gripe - The restriction on table prefixes to exclude modx_ prefixed tables. When I make a custom table for MODx I generally give them a modx_ prefix also to differentiate them from tables completely external to MODx e.g. SMF tables. As such, if I want to give a client access to such a custom table I have to edit out the lines of code in index.php that handle this. Not a big deal admittedly, but I’d rather it wasn’t there.
Another minor gripe - I’d also like a way to just give a client access to such a table without allowing them the ability to add more tables to the dbedit interface - perhaps even bypassing that initial table list completely. phpmyedit avoids the issue as its geared to just editing one table per setup anyway. On the down side this does mean that setting up access to multiple tables with phpmyedit could be a trifle tedious.
A big plus point for phpmyedit is that is it more configurable without having to hack the code e.g. by default users can delete records, but its fairly easy to block this. Another point is that its sorting and filtering functions are quite powerful, although the ’icons’ used by phpmyedit to access some of this functionality are less than clear IMHO.
On the down side for phpmyedit is that it does require some awareness of the MODx API and DBAPI to fully integrate with MODx and use the current database connection as opposed to potentially out of date host/user/passwd details. Its also a security liability as initially setup, but that can be fixed in a couple of ways (I just deleted the generated file and pasted into into a module in its entirety). As such, it cannot possibly be regarded as an out of the box solution.
dbEdit does integrate alot more nicely in terms of appearance. Even after a bit of effort my install of phpmyedit looks a wee bit bland. dbEdit on the other hand uses the manager theme well and looks nicely and modx-ishly familiar.
-- Tim.
Hi all!
I've got the same problem as was subscribed already 2 times.
After I try to add new table (it's custom and don't have cms prefix) I recive message "Unable to save configuration. Reason is: "
I tried to use ncrossland's pack and variant from the 3d page. Maybe somebody now what is the problem or have link to original module, so I can try once again.
