Alex, GT staff,
Here is a list of some problems, questions I noticed in Gossamer Community app:
- I miss the frame based admin interface
- admin login page should be separated from standard user login, using admin.cgi or such (as in LSQL)
- sometimes there is no enough info about how to use an option, like the email_admin, system_banip (no info about separator)
- User Session length can not be modified?
- in Who's Online, there is no info about how many guests are online. Could be optionally add Guest listing feature?
- Can be possible to change the required fields of user data and/or profile data?

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Also missing the:
- dynamic_preserve feature & option

Without this, there is not possible to preserve the selected URL parameters from page to page, when you change the template set dynamically.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Ah, for the "Can be possible to change the required fields of user data and/or profile data? " question the answer is yes. It can be changed by setting NOT NULL value to yes or no.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Hi,

1. We are moving away from the frame based interface. I'd welcome suggestions to make the navigation better without frames.

2. We are also moving away from a separate admin directory and basing things on .htaccess protection.

3. Documentation will be improved as the program progresses.

4. This will get added, right now it's stored in the config file, but not editable.

5. No, not realistically. Community has no idea about guests.

6. Yes, this can be done in Database->Profile menu. You can add columns and make them required or not required.

7. Yes, we will look into making similiar option to dynamic preserve.

Cheers,

Alex
--
Gossamer Threads Inc.

That's really a bad news...
Max
The one with Mac OS X Server 10.4 :)

Alex, I welcome and aggree your answers to most of the questions.
But I would further discuss about the following ones:

I like the frame based admin interface.
Usually I don't like frames for public areas of websites, but for the admin interface, I think frames are very useful.
Admin interface should be fast, quick downloading, and frames are the best solution for that. IMPO.

I'm seriously against to share user logins with admin login (security reasons).
Even if you don't use .htaccess protection, should be need for a separate admin login script, which can be renamed to even avoid other Links users to try to hack the admin login.
I think you should consider that separate admin login area (with a separate admin login script or with .htaccess).

BTW: what is your reason to avoid .htaccess usage?

I would need & use the Guest users feature.
I would use the GCommunity app to display how many users are browsing my website. Likely I will base all my page displays and user logins on GT::Community & GT::Template. And connect GCommunity to my Links SQL, too.
So I would welcome that Guests feature (available at least optionally), similarly how GForum has that feature.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

@webmaster33:

I agree for 100% with your posting above!

Regards,
Manu

Shopping Portal Shop-Netz.de® | Partnerprogramme | Flugreisen & Billigflüge | KESTERMEDIA e.K. | European Affiliate Marketing Forum.

Apart from the bit that frames are fast :)

Because unless you use apache or have a special extension then a lot of servers don't implement it.

I also agree with webmaster33!
Max
The one with Mac OS X Server 10.4 :)

I'd like to voice an alternate point of view, lest Alex get the impression that the uniformity of opinion expressed here is representative of user sentiment as a whole.

I hate the frame based admin, and welcome a move away from it. In general, I find frames clumsy and error-prone, and the use of them in GT admin panels has caused frustrations and headaches (albeit minor ones, usually stemming from the unexpected consequences of an ill-timed "Back" request) far more often than I can claim to have enjoyed the "benefits" of frames.

I don't see how an .htaccess login system is inherently any more secure than the standard community login system. Seriously, if someone has the skill and inclination to hack into your website, they're going to be able to find your admin panel. It's not like /admin/admin.cgi is the most cryptic of urls, especially to anyone who's ever encountered a GT script before. IMHO, the only reliable way to prevent someone hacking in is to use good, hard-to-guess passwords and change them regularly.

While I can appreciate the "coolness factor" of a guests feature, that would hugely increase the burden on Community in a heavily trafficked site, and would require that every single page and every single link had guest tracking parameters built in. Surely that's doable with a plugin and a lot of meticulous recoding of your entire site, but I hardly think it should be a default feature in Community.

---

Fractured Atlas :: Liberate the Artist
Services: Healthcare, Fiscal Sponsorship, Marketing, Education, The Emerging Artists Fund

Hi,

In regards to the frame based interface. There are a number of reasons why we are moving away. First off, it is slower to load. When loading the admin, it requires 4 separate calls to admin.cgi. Each click on a main menu requires 3 separate calls to admin.cgi to load the framest and left and right frame. This is quite noticable, especially on slower computers.

Secondly, it can be confusing and difficult to work with. The different implementation of back buttons can lead to problems. Also, especially on Mozilla/Phoenix, reloading just a frame panel is difficult. Same issues when trying to view source.

As for the move from .htaccess, when implemented properly, both systems provide equal level of protection. However, we have seen a number of sites that don't properly protect the admin area. If we distribute the program with the admin protected by default (which is not always possible with .htaccess), we can ensure the majority of users are safe.

I don't believe a hidden admin with .htaccess offers any more protection then a script that is password protected.

Finally, as for guest users, this is often not possible as not all applications are dynamic. For example, running Links SQL in static mode, there is no way that Community can know the number of guests.

Hope that helps,

Alex
--
Gossamer Threads Inc.

<<<<
Finally, as for guest users, this is often not possible as not all applications are dynamic. For example, running Links SQL in static mode, there is no way that Community can know the number of guests.
>>>>
Ok but at list community can track the guest users that navigates in the dynamic side.... For the forum too (all dynamic... so?)
Max
The one with Mac OS X Server 10.4 :)

Community is dependant upon the programs which it manages as much as it is on itself.

Programs in static (as was stated) do not allow the flexibility that a dynamic program offers BUT they run so much faster and tax the server so much less that it is in some cases very worthwhile.

One way to increase the usage of registered guests is to increase the amount of products and services that are offered on the "non-guest" side of the street. Such as using the user_home in community to display many products and services that are not available outside. Without Community the place to add items such as this would be the login_success page in LinksSQL as well as the validation_success page.

While I am a REAL data junkie and feel like Johnny Five most of the time, data from guests can be seen through logs kept on the server as well. It may not be dynamically placed on a page within Community but it is real time with the right software.

Ultimately Community will offer a centralized login system for our sites as well as some expansion capabilities that cannot be attained or not easily reached with multiple user interfaces. The cross marketing concept becomes much more in control and the external marketing capability enhanced greatly.

Our goal is to convert as many look - i - loos as possible to registered users. With this we can control what they see, when they see it and how it is delivered to them. As per the guests, well if I cannot convert them to users then I need to look at the big picture a little bit more closely to identify shortcomings in the design and content.

Disclaimer:

Of course this is just my opinion and opinions will vary. Consult your local listings for a showtime in your area. Ages may vary due to dates of birth. Selection may vary based upon stock availability. And so on...

NOTE: The new Community interface is VERY cool. I like it much more than the frames version.

Brian

Links SQL is not a static script.. It's a dynamic script that builds static pages. But a user can navigate trough all links sql always being on the dynamic side as you know...

As for the log access guest tracking please... That's not realistic.. And will not fit purposes like dynamic <if guest> variables and so on...
Max
The one with Mac OS X Server 10.4 :)

Oh a guest feature isn't only a coolness factor!

It's also good for marketing reasons!

Normally users like sites with a lot of traffic (users online).

So it makes a difference if you show your users a "7 registered useres online" message or a "284 users online" message!

I agree the feature should be optional (switch on/off)!

P.S.: I really like the Frame-Admin. Quick and usable navigation!

Regards,
Manu

Shopping Portal Shop-Netz.de® | Partnerprogramme | Flugreisen & Billigflüge | KESTERMEDIA e.K. | European Affiliate Marketing Forum.

Yes, this is the situation. When loading the admin, it requires 4 separate calls.

1) But how much resource does the admin page use?

• 4 calls are executed only once, at admin login.
  
• When you click on Top menu, 2 frames are refreshed (3 calls).
  
• When you click Left menu only 1 frame content is refreshed(1 call).

Well not the admin page calls will hog down the webserver, right? IMHO if you want to move anyway to non-frame admin pages, and admin module already HAS the functions, would be not difficult task to make the frame based admin interface at least optional.

2) How many admin page calls are executed a day? Not so much. So from the viewpoint of server it does not matter... (admin page has has much less calls than user pages, so will not affect server resources)
But from the viewpoint of user frames does matter. User has likely wait for full load of each page (depends how you use the tables).

3) How slow a webserver must to be, to slow down so much the admin interface, that is not usable. My earlier (shared virtual!) webserver was Celeron 300 or 400. I even developed the earlier Links 2.0 (which also has frames), using Pentium I. 200 Mhz. Isn't that enough slow? But the admin interface is not affected so much.

4) Finally, anybody who uses slower computer than Celeron 300, is mazochist

How much performance do you gain without frames?
IMHO, I think it does not worth the efforts you put into...
But if you put into, then please make frames optionally available.


Do you know how many users use Mozilla, right? Below about 2%. Anyhow, not many.
BTW: I also use Mozilla, and still I like frame based admin interface.


I see your point. Yes, this is true and I definitely aggree with it.
I'm not against form the based admin login.

I'm only against the COMMON User & Admin login form. Admin login should be DEFINITELY done using separate script, which should fit the requirement to be renamed anytime (so no hardcoded admin script name allowed, max in 1 place: the config).

Quote:

guest users, this is often not possible as not all applications are dynamic. For example, running Links SQL in static mode, there is no way that Community can know the number of guests.

1. I think, those Community users who misses the guest user feature, want to use this feature on dynamic pages, not on static pages.
   
2. If we would really want to track online users on static pages, that would be possible through a 1 pixel size, dynamic, script generated image, placed into static pages, which also connects to Community db tables.
   
3. Also SSI calls on static pages would be also usable to track guest (even all users) users. Additionally SSI tracking is exact, not like the image based one.

So there would be possible to track site users on static pages. But I (and possibly others also) don't expect that feature, we would like to have the guest users feature just on dynamic pages.
Very likely, if Guests feature will be not added, I will create a plugin for myself to have that functionality.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Excuse me if I'm just completely lost, but the guest user issue seems straight forward to me. If community generated a session ID for everyone, couldn't that give a close enough proximation of number of guests and users currently online. A session ID could easily be passed from static page to static page or dynamic page and back again. The session log would house all of the sessions to be counted. The trick, as it seems to me is to exclude the expired or logged off sessions from the total. Maybe when a session is finished it could be moved from the active session log to the session history log.

The fact is I haven't seen the community script so I'm trying to describe a painting in the dark but this seems reasonable based on other GT scripts I've seen. The real problem is that in order to track all of this and keep everything straight requires the session log api's to work three to five times harder and your service provider may complain. But, if you are running mostly dynamic scripts any way, the extra work of the server would be pretty small.

Another problem is that in order to really get this to work every time a visitor loads a page without a session ID or expired ID, the server would have to generate a new ID. Hard to do if they go directly to a static page. Your server could end up creating thousands of ID's every day just for people who clicked the wrong link on Yahoo.

The other option is for community to generate a random temporary user name for each "guest".

Like I said, I could be lost, but the problem is straight forward. There are many ways that community could track guest users but, most solutions have many drawbacks and community just isn't designed for that type of use.

It's just my opinion, but it's the only one I've got!
beetleman

Marcus L. Griswold

I wrote the following right in the first post: "Could be optionally add Guest listing feature?"
Once you understand that, your problems are not valid. Those who does not want to use guests feature, will simply not use this feature. By default Guests feature would be turned OFF.

No, there is not possible to pass session ID from static page to static page (at least not through URL)...
Just imagine, it's static :-) Therefore it's not possible to read the session ID nor from URL, nor from cookies by perl script.
I listed the possible solutions for static pages above: dynamic image (like a counter), or SSI.
(but unless you don't use mod_perl, dynamic image or SSI cgi call would result almost the same server usage as you would use dynamic page display).

This is not true. If you don't want to track Guest users on static pages, then do not place the dynamic image or SSI call into your pages, and your service provider will complain. Guest tracking would be not an obligatory thing...
Otherwise as you told correctly, "if you are running dynamic scripts, the extra work of the server would be pretty small".
Also the Guest feature should be implemented as optional feature, so your worries should be gone now.
You will be simply not affected by Guest users feature, if you don't want to be affected.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

I too think that the guests online feature would be a waste of resources - Alex's time in particular.

The number of non members online is in no way connected to how good a site is as a community. After all, the registered members are the ones who contribute. Having 1 or 1001 "lurkers" makes no difference to the amount of useful content available, which is what most people will be visiting for.

If there was a really high percentage of non-members compared to members I would likely begin to wonder why so many people didn't want to join in and whether they had been tricked into visiting via a misleading link.


I would also like a frames based admin panel to remain as an option. Despite my usual dislike for frames, I find the Links 2 and FileMan admin panels to be easy to use in that format - particularly if there are problems.

If the program fails for some reason, only the main frame is affected and all the other options are left intact on the screen.

I have had no speed related problems with the frames based admin panels, even on a P133.

Not that I agree of disagree with your thoughts on the amount of guests online VS users, but the Gforum Whos Online shows the information already and the following was taken from this forum:

4 registered users have accessed the forum in the last 15 minutes:
75 guests have accessed the forum in the last 15 minutes:

What is your thoughts on this and do you think it should or should not be shown in GForum?

In my opinion the guest count is cool but listing each guest is a bit too much.

Thanks

Wysardry,

Yes, Guests feature was already implemented once in GForum. I don't think, that adding an already developed feature into GCommunity, will take too much resource from Alex. Also would not affect users, since should be added as optional feature.
I think, for Alex it is more a matter of principle, and than a resource question...

IMHO, Guests count is a good thing, it shows for the visitors how popular is your site. Also, if you see that there are a lot users at the same time on your site, this means you can start your own chat service on your site to build a real community. Once user see that there are X users at the same time, they will like to contact them and share their opinion about your site, about your site content, or just chatting a bit with those who has the same interest... And at that point it's good idea to add chat and/or forum to the site.
That's one of those solutions how you can keep your visitors...

It's your right to refuse using these marketing strategies, but let others have the chance to turn on that option, if they want to use that feature.
Finally, yes, I aggree your reasons about the frame usage on admin side, I think the same way.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

Well, the guest users are tracked anyway (by cookie or IP), if we want to display guests count, so the fact that each guest is listed or not, is just optional. The data was already collected, sessions created, it depends on the programmer to display or not.

Otherwise yes, I aggree with you, that listing each guest is nor a necessary thing, nor required by any reasons. Listing each guest is just curiosity for users, nothing more (as I see).

But number of all users on the site (including guest & registered users) at the same time, may be useful in marketing reasons, as I expressed my opinion to Wysardry.

Best regards,
Webmaster33

---

Paid Support from Webmaster33. Expert in Perl programming & Gossamer Threads applications. (click here for prices)
Webmaster33's products (upd.2004.09.26) | Private message | Contact me | Was my post helpful? Donate my help...

A good point. The Who's Online feature is already available via GForum for those that are interested.

In other words, it doesn't need to be added to the community plugin in the first place. Perhaps using the plugin to make that info available from other GT products would be an option.

I actually think this is an acceptable way of doing things - the info is only shown if specifically asked for, on a page that doesn't do anything else.

My objections were mainly targetted at the idea of showing that info (without it being asked for) on pages that already use a lot of resources to do other things.

Listing each guest by name is a bit much, but I assume the number shown can be configured somewhere. I'd rather see the top 10 rather than 50, but everyone is different.

Yes, you're starting to go further down the road I thought a guests online feature would start people on. The quest for more and more features.

The community plugin was intended to allow users to register and log into all the GT products as if they were one. It wasn't supposed to add anything else.

Features like guest counts, chat boxes etc. should really be separate optional plugins or features of the GT library for those that want them.

Putting them in the main program would make it bigger and slower than it needs to be. Even if users could "turn off" the extra code it would still be there.

I have no objection to having a guests count feature if it's truly optional and completely separate, but I don't think it should become an integral part of the core code.

Now I'm not expecting GT to make their decision based solely on my opinion, any more than they would based on yours alone, but it's only fair that those who don't like the idea mention their views in the same way as those that do.

How else are they to know how many people would actually use the feature? They can't add everything people ask for.

Everyone wants different features, and to include them all would lead to a program as big and unwieldy as PHP-Nuke. (For those that don't know, it's a news publishing system that adds over 2600 files to your site before you even start adding content).