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.
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.