I have this sort of running, but no features enabled. Right now, it's a matter of getting the install working, (which it does) and tweaking the table params, which seems endless, and getting all the settings to match up.

This is turning out to be a _whole_ new program. The old code was, well, old. There is so much more Links can do now, that it needs to be completely rewritten.

The install/uninstall works, but the settings are changing as I try to figure out the new program flow.

MyLinks_DB used a really weird program flow, for Links/GT coding. It had "cool" coding features, but it was non-standard Links SQL/GT logic, and that is a problem in upgrading. I should probably just have started out new, on this, but data compatibility was an issue, and I knew nothing about the workings of these programs.

Right now, the new database has significantly increased internal flexibility. This comes at a price -- more data storage for user links, so I will try to allow disabling the advanced features (possibly a later version), and using the simpler LinkID/UserID format for the linking table.

Allowing a user to store a new Title/Description carries a space penalty. Even limited to 100 chars Title, and 255 chars Description, that is almost 400 bytes per MFL record. If each user has 25 FML's, and you have 1000 users, it's managable. If you allow users 100, 250 or more MFL's, and have 10,000 users, it starts to get significant.

If you have 10,000 links in your database, 5,000 users, and 25 MFL's each, the MFL database will be larger than the Links database. Anyway..... as I said, features come at a price.

Part of the delay is I'm not hacking this. Where I need a function, I'm writing a function. Reusable later on.

There will be a basic "pre-pre-alpha" plugin settings editor, almost non-noticable in this version, since it will be mostly hard coded, that will allow you to add fields to the User record and the Plugin Settings, and have access to both automatically. The Plugin settings are available via plugin calls, but user settings had to be coded into the various templates and modules. What this will do is load $USER, and _remove_ any fields that are prefixed with $PLUGIN_NAME_(underscore). This will leave a hash of, in this case, MyFavLinks_nnnnnnn fields from the user record. Using similar logic to the Links code, you can block certain fields from user editing, and the other fields will get a form generated, based on their settings.

As it is now, there are the following user settings:

'MyFavLinks_Viewable',
'MyFavLinks_Rating',
'MyFavLinks_Count',
'MyFavLinks_Per_Page',
'MyFavLinks_Grouping',
'MyFavLinks_Save_Type',
'MyFavLinks_Ordering',
'MyFavLinks_Order',
'MyFavLinks_Font',
'MyFavLinks_Title',

Looking at the list, I see I need another field, MyFavLinks_Viewable_admin, for admin locking of a user's list.

Also, these settings should _really_ be in their own table, and loaded only if $USER->{'MyFavLinks_Count'} is > 0
For speed/performance issues, that and $USER->{'MyFavLinks_Rating'} should probably be in the Users table, and everything else in the MyFavLinks_Users table. I have to think about this. Those two settings should be non-editable by the user anyway, and that would keep the user from editing/changing anything in the User record....

(Community is going to throw a wrench into this as well.....)

But, back to original issue. When loaded, the $plugin_cfg hash for that plugin will have a field for non-editable fields, such as MyFavLinks_Count, which are not added to the forms, and are not updated via passed in params. Those fields will be blocked from editing/modifying.

What this will do is find any custom fields you may have added, allow you to define them editable or not, and have it managed pretty much automatically. Flexibility for sites that need it.

The program functions on very few "key" parameters. Most things are for look/feel or customization via site defaults, or user preferences. (Defaults are in the $plugin_cfg, preferences are in the Users table - for now).

MFL_LinkID is the ID of the link in the Links table. It's '0' for a custom link.
MFL_UserID is the MFL list that MFL_LinkID belongs to -- this may or may not match
Username which is the logged in user (standard links).

if MFL_UserID == Username, a user is working on their own list.
if MFL_UserID != Username, a user is viewing/rating another list.

For future use, an MFL_ID field was added to the MyFavLinks_Links table, which is a unique identifier field, just like Links::ID

Just an update. This bear is now a resurrected, genetically altered, re-engineered sabre toothed tiger.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Ok,
I need to put this stuff somewhere so I can find it later, might as well put it here.

Changes to the programs (I can't diff between MyLinks and MyFaves at this point). This has turned into a virtually complete rewrite.

=========

1) completely new table structure, template variables prefixed with MFL_, tables with MyFavLinks, User options MyFavLinks_ and to prevent confusion, "Username" is the logged in user, "UserID" is the list/MFL's you are working with. They may, or may not, be the same value.

2) MFL's and "custom" MFL's are now stored in the same table. The custom MFL's have a MFL_LinkID of '0'.

3) When a link is added, the users get a pre_add page, which allows them to edit/change any of the data visible data (Title, Description, URL). I'll try to remember to add a check if they change to URL to print a warning page and allow them to pick the old or new url. Either way, if they change the URL, the link is added as a custom link (for obvious reasons).

4) Fixed up the code -- loads of bug fixes, logic fixes, etc. Created new bugs.

5) mod_perl / persistant environment compatible, where it was not before.

6) GT-ified calling conventions, logic flow, no bomb code, no time outs, etc.

7) Major template fixes. New formatting, matched tags, should pass most checks.

8) Bigger/better install routines. Uninstall will give you options to leave user preferences and/or table data intact. This could be a "gotcha" if the table definitions change, but we'll deal with that later.

9) more admin options, and more being added. As the program/sub routines develop, I'm adding more flag fields so you can control what is going on with the program and users. To handle different set ups (though it makes my skin crawl) there will be an option to allow non-logged in users to rate things, and to view others lists. These are overrides to the standard links permissions. eg: if user_rate_required, it's required for this program, unless overridden. Same for user_required.

10) I'm really, really toying with making a MyFavLinks_Users table, which will keep the Users table clean, and only put the Viewable & Count params in the $USER record. That would prevent excess table look ups and SQL calls, though violating "normal" rules. It would also give easier/better access to stats, as only users with MFL lists would be in the MFL_Users table.

11) need to decide how to deal with deleted Links


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

This is getting ready for a beta.

Any show of hands as to how many people are using MyLinks and MyFaves would be appreciated.
You can post here, or privately, or in the http://ultranerds.com/forum

How many people will determine a few things, and how fast the program can be released -- and how quickly you can install it. Upgrading is a simple issue, but I *might* not make the upgrade code, since the sQL statements are easy to issue via MySQL Man, and the error report is instant.

Seems a waste of time to write install/upgrade routines to handle all sorts of errors, when it only has to be done once, and it's not going to keep happening after the intial migration.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

I 'm using them.

CCUnet
my Christian web

I'm getting close to a release of this, and it may bypass beta, except I did probably miss a few bugs.

The _UserOptions are now in their own table. These are display preferences that are only of interest to a logged in user.

_Count, _Rating and _Viewable are still in the Users table, for performance reasons.

The _Custom links table is gone, all links are now in the _Links table, and a custom link just has a LinkID of 0

Two things need some input.

1) How should the admin be able to lock a users list, and override a "bad" or non-paying users "visibility" flag?

2) Should MFL_Title (the custom title for their list) be in the Users table?

Right now, with a call to Users, you can do something like:

User BigLinker has 320 links and a rating of 9.23

If the title ws also stored there, you could do something more like amazon,

BigLinker's "Top 900 slasher films of all time" has 320 links and a rating of 9.23

without having to link to the _UserOptions table.

There are pros/cons for each ... since a user can change the title of their list, they have write access to the Users table if it's stored there. It's only a _little_ thing, but in the larger scheme of things, it's the little things that get you <G> The first way, the way it is now, the users can only change items in the _UserOptions table, and the fields stored in the Users table are set by the system when a user adds/deletes links or gets rated. Of course, the _Viewable flag is also set by the user, but it's more of a "system" option than an editable field such as Title.

Comments???


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

Just got more complicated again :(

I like the way the links are stored in their own table, it has many more advantages over using the LinkID::Username linking format. Also, by not using that format, I simplified a lot of overhead calls, and such.

*BUT* One feature left out of this, is a sort of special case.

If you have an upload type site, or a site where users are interested or concerned about their "hits", if a user was using the Fav list to keep track of their own links, and hits, or ratings as in the main links database, that can't be done right now.

I have two (or two and a half) ways to fix this.

1) Create a new set of routines, so a user could choose to use the LinkID::Username format for saving, disabling all the other features
1.5) Create a new display routine, that a user could choose to display only non-custom links, using the link.html template, rather than MFL_ template, in effect, it would be a search on Username, and display by their ordering selections.
2) If there is a LinkID, go fetch the Link record data, but sorting/ordering by that data would not be available -- at least at this time.

Right now I'm leaning toward #1.5, as the most flexible. It would allow "special cases" to be handled by writing a new routine, rather than changing any internal logic. The penalty is new display routines.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.

As you can see, this simple rewrite became a big hairy bear. There are several concepts/logics at work here, most conflict with one another.

To wit: using the list as a simple pointer into the main database, vs using the list as a more robust (and potentially traffic generating) bookmark system.


From each of these design views, a lot of conflicting functionality descends rapidly into programming hell.


If we assume there are much better methods for allowing a user to track/monitor their lists of links -- eg: a watch list, then we again rise to a more placid level of existence.

I *think* I will continue to develop along the second track : eg a robust bookmark system, rather than a simple pointer into the main database. For those sites which have been using the FavLinks programs as a watch list system, it would be better to reprogram a simple watch list. There will be far less overhead for that purpose.

Maybe I'll add that in as a feature here, but the special case of users using the Favorites list to follow which of their sites (or competitors) was getting more hits will not be available in this release. So far, I think this is the only functionality "lost" or not enabled (as well as the "grouping" feature). I'll be adding the Grouping feature back in, but as a more robust - create your own categories -- type feature.

As for the "watching" of your own links, *that* really lends itself to a more stripped down, leaner program. A "favorites" list has more demands on it, that incurr higher overhead.

Anyway, this is an area that is evolving. Comments and suggestions welcome.


PUGDOG� Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.