Initial Files!

Pre-CVS code...

Without further adieu, here it is. I've got to get this into CVS, but replacing everything that's there is a total pain in the rear.

Developer's Guide

The .zip file

Expect bugs and the installer needs to be merged with the original Etomite Installer, so Susan, here ya go. Lots of fixes coming soon, I'm sure.

Now... off to install on pixelhick.com

OK... there's some really serious issues with the manager right now... I am poking through and trying to get it to work, but so far no good. Should be worked out very soon, though, I hope.

Here's my initial findings on problems. I have a feeling a lot can be fixed by curing the JS errors, particularly the last one:

First is the dead login box. The login shouldn't do anything fancy but take a username and password and log you in. I think it's expecting a non-existant cookie (until it runs the first time and opens the manager, any way). I had to change line 152 of /manager/accesscontrol.inc.php to:


Next it tried to open a popup window in Firefox when I logged in. The popup blocker prevented it form opening. I then tried to reload the page, and a couple of other things, and it redirected it to the Etomite site (seriously) in a popup window (I probably clicked on a non-visible page). It then proceeded to mangle the manager so bad in Firefox that it locked up the browser, and I had to force quit it.

Upon returning, I logged back into the manager, and managed to login but got a scripting error page to appear that I've never seen in Etomite, but it is an etomite original page because it asked to report files back to the Etomite bug tracker. No actual error was reported in the popup though.

When trying to switch to the advance manager layout, I get the following errors (in both Safari and in Firefox):

Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /home/httpd/vhosts/pixelhick.com/httpdocs/manager/processors/cache_sync.class.processor.php on line 135

Warning: Cannot modify header information - headers already sent by (output started at /home/httpd/vhosts/pixelhick.com/httpdocs/manager/processors/cache_sync.class.processor.php:135) in /home/httpd/vhosts/pixelhick.com/httpdocs/manager/processors/save_settings.processor.php on line 35

Worst of all, the tree menu does not render, which is probably due to the following JS errors (particuarly the very last one).

------------------------------------
Numerous JS errors...
------------------------------------
When logging out:

Error: DynElement is not defined
Source File: http://pixelhick.com/manager/index.php?a=1&f=5
Line: 112

Error: el.attachEvent is not a function
Source File: http://pixelhick.com/manager/media/script/cb2.js
Line: 32

When logging in:

Warning: Element referenced by ID/NAME in the global scope. Use W3C standard document.getElementById() instead.
Source File: http://pixelhick.com/manager/index.php?a=1&f=5
Line: 1

Error: document.setIncludePath is not a function
Source File: http://pixelhick.com/manager/index.php?a=1&f=3
Line: 15

When doing pretty much anything:

Error: DynElement is not defined
Source File: http://pixelhick.com/manager/index.php?a=1&f=5
Line: 112

Hope this helps...

There are some changes in these new files that I'm just not getting and would love to see someone explain the rationale behind them...

* add new #declare syntax to weblogin template - this will allow you to declare your own section separators instead of <!--tpl_separator-->

* important change: please update youy signup email to use the new placeholders. This version will still honor the %s codes but future versions might not.

* new weblogin template will standardize on the new placeholder variable format [+name+]

Also, I really question why we are adding things like
* add field to user attributes dob, photo, gender, country, state, zip, phone, fax

into the core. IMO, this should have been handled with some sort of module/plugin so that people can decide their own way to extend this information. (I stand by my earlier thought that a lot of this stuff needs to be abstracted more, not just added into the core.)

Most likely they're there because there hasn't been a lot of abstraction taking place before now. We're still a long way aways from getting rid of a lot of Eto-legacy, and I'd say they're better in than out.

Then again, I'm not exactly a coding genius.

That's "ado". (or was that a joke? I'm always the last one to "get" a joke)

Anyway, thanks! I love new toys...it's like Christmas morning! (only without my Mom to make us wait until after breakfast!)

Hm. Yes. I see what you mean. The big problem that I have with all this stuff being added to the core at this point is that all too often I have seen that there is somehow never time to go back and tidy up, there is always the push forward. I would much rather see the new stuff put on the back burner, and getting the core set up and finalized, then start adding the new stuff as modules in the first place. I know the new stuff is more interesting, but it will be much better if the proper framework is put in place at the beginning. (sort of like getting all the dishes washed and the kitchen cleaned up before starting on that new gourmet recipe; dull, but really worth it in the end. I know; I sound just like my mother, but then she was usually right!)

Anyway, it's really just good programming practice; it's much easier to debug and finalize smaller units, then add more, one step at a time, debugging the new units as you go along, since you know what went before already works.

I would like to suggest a freeze for, maybe, two weeks, that should be more than enough time for you smart guys to get the core cleared out and modularized properly. Then we can all go off and work on whatever our pet projects might be, without trashing the whole thing every time something new gets added. Trust me, it will be well worth it.

There are some changes in these new files that I'm just not getting and would love to see someone explain the rationale behind them...

* add new #declare syntax to weblogin template - this will allow you to declare your own section separators instead of <!--tpl_separator-->

This will allow the user to specify the delimiter used inside the template. The old <!--tpl_separator--> is still supported but the new #declare: allows you to declare your own separator. For me I used <hr> which is much better when working with wysiwyg editors

* important change: please update youy signup email to use the new placeholders. This version will still honor the %s codes but future versions might not.

Again more options for your mail merge

* new weblogin template will standardize on the new placeholder variable format [+name+]

That's correct. the old [name] format was causing some problems with javascripts. My other reason for this is the standardize on placeholders rather than creating another place or field holder format.

Also, I really question why we are adding things like
* add field to user attributes dob, photo, gender, country, state, zip, phone, fax

into the core. IMO, this should have been handled with some sort of module/plugin so that people can decide their own way to extend this information. (I stand by my earlier thought that a lot of this stuff needs to be abstracted more, not just added into the core.)

These will be standard fields used for the login in the same way we have standard TVs used by documents. Additional attributes will be customizable in future versions. This means that you can add as many as you want.

The Web user service has been greatly enhanced to provide you with more security features such as Allowed Days, Allowed IP, Blocked Until and Block After.

OK... after battling my slow dialup connection and working with Raymond, we're ready for a go I think for the internal release for the devteam to get their hands dirty... lots of little bugs squished and weblogin/webuser request working just fine.

I'll upload a new batch of files and Victors going to create a fresh repository for this, so it'll all be in before noon CST tomorrow, and hopefully in the AM.

Just to make it clear, the majority of the problems were due to an incomplete upload of files on my part. :/

(note to self: don't mess with critical stuff when clients are coming over really soon)

Ok, I have the installer integrated nicely and working...up to installing into the database. Will debug the sql, then we'll see how it goes. CSS looks funny; I think I'll change the whole CSS look of the installation anyway.

I'm strongly tempted to add a $base_url and $base_path to the config.inc.php file, automatically adding the detected values to text inputs along with the database info for the user to change if necessary; thoughts on that?

I made the GPL acceptance page the first page; I have always hated getting some click-through license (or key entering/license accepting page, MS, are you listening???) halfway through an installation (as if anybody doesn't click it without bothering to read through it anyway, but what if?).