| T O P I C R E V I E W |
| Etymon |
Posted - 14 December 2008 : 06:08:27
MOD: MOD Suite (dbs Installation)
Date: December 14, 2008
Download: Download Here
Requests and Notes:
I'm rolling out a series of components to a much larger MOD called MOD Suite. This is the first component of the MOD Suite. It is the dbs installation component which is where installing MODs often begin.
I need some extra sets of eyes to review the security aspects of these files. I have not fully gone through them.
If you all could go through the code to look for security issues, that would be great. 
There's more to come, so this should be a fun ride!
If you want to see where we are headed with this one, read the description and look at the images in this post: http://forum.snitz.com/forum/topic.asp?TOPIC_ID=67879
< |
| 7 L A T E S T R E P L I E S (Newest First) |
| garyrobar |
Posted - 16 December 2008 : 16:51:46
Etymon - not yet...I'll download now, but not sure when I will have a chance to experiment. I've got a big workload of stuff to get through on my site...while im on holidays from my real job< |
| Carefree |
Posted - 16 December 2008 : 16:23:16
Back in the Commodore days, we wrote bulletin board packages based on the same principle - there was no choice, we didn't have the luxury of memory that exists today. Basically, we would use lines 1-1000 for the base code and every mod would start on line 1001. When a mod was called from a menu, it would overlay whatever currently existed at lines 1001-? and not have any effect on the base code.< |
| Etymon |
Posted - 16 December 2008 : 15:55:27
Thanks Gary! I hope it helps others. Have you had a chance to download the .zip, take a look at this component of the MOD Suite, and test it on a test site?
Yes, I like the WordPress Widgets. I think, originally, Widgets was a MOD that became basecode in WordPress. I like the way Widgets accomplishes things visually, but I don't know what goes on in the programming to make it do that.< |
| garyrobar |
Posted - 16 December 2008 : 15:47:09
Very Cool! I've been using wordpress a little bit, and the ease of "plugins" (their word for "MODs") is astonishing. It would be nice to get closer to that with snitz.
I just don't think the snitz codebase can accommodate that though. The level of plug and play for mods that we see in wordpress, and some of the phb boards are only possible when the codebase totally separates code from content/presentation.< |
| Etymon |
Posted - 16 December 2008 : 13:52:20
It's has elements of automation, in that, as the MOD is brought on-board, it is easier to track. I have some plans that could standardize mod dbs_ files, but that would have to be a group effort rather than my call alone.
Here is one example that comes to mind:
Say a mod is called PM Manager
What I have posted above, in this thread, is not the full MOD Suite. It is the start of it.
What the full MOD Suite (that I have offline) currently does is takes the title a dbs_ file, the first line, and then it inserts that title into a table. There is more than just one table. There are several.
After the MOD title is inserted into its table, then I can manage the title via its category. I can create, edit, and delete MOD titles. I can add notes. I can add moderators to oversee the MOD whereas they can not see other MODs. I can also do the same with the MOD categories titles (whose names are of my own choosing or in your terms, of your own choosing).
I can transfer MOD titles between MOD categories just like you can transfer a Topic Title between Forums. If I think the PM Manager MOD title should be in the Communications category instead of the Private Messages category, then I can simply transfer it over. Then when I look at the list of all my installed MODs, that is where I will find the PM Manager. Now, in the list of installed MODs they are not just titles. If they have an admin page, they also link to that admin page.
As far as automation, what I would like to see take place is for folks to name their admin page (if there is one) to have the same title as their MOD, except with the extension of admin_ as a prefix, and as such, the MOD Suite could "automatically" place that link in the table for the admin page without the person having to manually do it. But honestly, Snitz has been out for over 8 years, so I truly don't expect a reverse course at this point in time regarding naming conventions for admin pages. However, for my MODs, whatever I release, I do want them to be MOD Suite compatible regarding the admin page.
I hope all of this makes sense.
As far as other things that require manual modification of the actual file ... no, no automation there.< |
| garyrobar |
Posted - 16 December 2008 : 13:21:12
Hey Etymon - are you building automation for MOD installations?< |
| Etymon |
Posted - 14 December 2008 : 06:47:16
I just saw this in the mod_suite_dbsetup_source.asp file:
if MemberID <> intAdminMemberID and MemberID <> 2 then
That should be:
if MemberID <> intAdminMemberID and MemberID <> 2 then
And, then below that is this:
if intAdminMemberID = 1 then
intAdminMemberID is hard-coded as 1 in a standard Snitz config.asp file where Const intAdminMemberID = 1, but some folks know enough to change that to another MemberID. If you have a different intAdminMemberID, then you would want to change the code above to reflect that change. I'll look throughout all of the code for more stuff like that.
< |
|
|
