On Mon, Sep 7, 2009 at 1:46 PM, Kevin<tnet.servi...@gmail.com> wrote:
>
> On Sep 7, 9:24 am, The Editor <edi...@fast.st> wrote:
>> Kevin, sorry for not getting back to you earlier on this. Let me share
>> with you how I would recommend solving this problem.
>>
>> 1) Avoid any changes to the core functions. That means you will have
>> to remake the change every time theres an upgrade. This should be a
>> hard and fast rule--never change anything there. There's virtually
>> always a way to work around what you want.
>>
>> 2) I'm not opposed to adding a new feature to the core, if you think
>> there is merit in it. It's only a couple extra lines. Generally,
>> though, I think something like this would do better as a plugin, as it
>> is probably not a common need.
>
> No problem with above... not sure how many people would need what I am
> looking at.
Agreed then.
>> 3) I think the easiest solution would be to use toolmapping to create
>> a custom function. You can do this with any function, command, or
>> condition. In your config.php file try this:
>>
>> $BOLTtoolmap['x']['login'] = 'mylogin';
>> $BOLTtoolmap['x']['register'] = 'myregister';
>>
>> This means map any calls to the login command (x) should go to
>> function mylogin instead. Use f for function and c for condition.
>
> Can toolmapping be used in a plugin? By that I mean, if I created a
> plugin with replacement login and register functions could it have the
> toolmapping to tell the system to override the current functions. Or
> is there something else that can do that in a plugin?
>
> I was wondering that when I was making the changes that I did.
Certainly. You can put the toolmap line, and the replacement functions
either in config.php or a plugin. Generally I develop in config.php,
and then when I get the code to work, I just cut and paste the needed
lines out and and into a plugin file.
If you are curious, the routine that calls up the various config files
and plugins is found in engine.php around line 202-216. You will
notice (perhaps) that it not only loads config.php, but also the
closest hierarchical config file, like config.forum.php, a skin.php
file, and plugins. You can also enable plugins in config files
(include_once) under whatever coding rules you like. For example, load
this plugin if an admin, or if the day is tuesday or whatever. So you
have pretty good flexibility. And while we're at it, remember you can
even overwrite whole toolsets, sitewide or hierarchically. So lets say
you wanted a very limited set of functions to be available in a forum
hierarchy, you could write a forum.functions.php and it would get
loaded instead of functions.php. All just fyi.
>> Next copy the login and register commands from the commands.php script
>> to your config file, and rename them mylogin, myregister. And make any
>> changes to the code that you wish. In this case, changing crypt to md5
>> in all appropriate places.
>
> I understand the part about pulling the login and register commands so
> that I could make changes to them, but I don't get the config file
> part. Which config file are you talking about?
BoltWire always looks for and loads a file at field/config/config.php.
Virtually anything can be configured here or in a plugin (or
hierarchically as noted above). The settings in site.config or only
limited configuration options. And they are always ignored when
overwritten in a php file. So you could set any setting in site.config
programmatically. IE, setting a skin based on user preferences or
whatever. That is, based on any php conditions you wish. Ask if you
want to now how.
>> 4) You're finished! All your usual login features in BoltWire now get
>> rerouted to your custom functions and you can do upgrades at any time
>> you like, without losing functionality. Of course, if there was an
>> improvement to the core login/register functions, your custom
>> functions would not contain those improvements unless you updated them
>> to be based on the newer code. For example, in the last release or two
>> I added a small bit of new functionality to how the register function
>> handles emails. Of course, those are usually noted in the changelog...
>>
>> I would probably not use commands code/encode/decode as they are used
>> by some other plugins, and might have better uses down the road. But
>> if your system is working, that's what counts. I do see you are
>> catching on quick to how BoltWire works.
>>
>> --------------------------------
>>
>> On a related note, DrunkenMonk gave a nice snippet of code you could
>> probably use to get a more universal login. I think that would be a
>> nice feature. To get an outside function to save data to a page in
>> BoltWire (such as a login page), you might want to look at the
>> savedata functon in engine.php. Remember they are all alphabetized.
>> You would have to hardcode a few variables/paths, and work around the
>> few BoltWire functions in it (like exists, loadpage and savepage, but
>> none of these should present too much trouble. So you could probably
>> salvage some of the code to make a quick external script.
>
> I didn't understand his post at the time, but am getting there now.
> Learning curve.
>
> Treading into custom zone here I think...
>
> In one project that I am just starting, the need to user data in the
> wiki is really not needed. All that is really needed is the ability
> to validate who a user is by MySQL call to a common database.
>
> Rather than creating login.user files, using your method mentioned
> above it appears that I could replace the functions dealing with users
> for login, register, exists etc...
>
> Am I going to run into problems doing this where there are no
> login.user files?
Technically, no. I've been meaning to setup a msql plugin for
awhile--and perhaps a plugin to do pagestores in a database. As well
as data. I think it would be cool, and might be faster in some
respects. I'd also like to do an ldap authentication plugin. BoltWire
was designed early on with that kind of extensibility in mind.
Certainly no problems to using alternate login/register functions.
However, you might want to create profile pages just the same, to
store at least some profile data, even if not used for login info,
because I suspect you might have some problems possibly with
shortcuts. For example, I use [[~someid]] all the time to create
quick links to the [[login.someid|+]]. In my main site, I even use a
config option to use a realname data value rather than some obscure
member id. Very nice. But if there is no login page, you won't have
any pages to link to. There are other shortcuts also to profile info,
like {~id} as I mentioned. above. Nothing that should break the
system, just some fine tuning. Such as turning off a couple markup
rules you wouldn't need.
> If toolmapping or something like it can be activated by a plugin, it
> might make implementing something like this simpler, allowing for
> upgrades to the core as needed without having to redo everything each
> time.
>
> A plugin would also help others I think by providing a shell of how it
> can be done that could be used by others that need to integrate like
> this.
That's correct. If it is something that might have broader appeal, by
all means, put it in a plugin and make it available in the solutions
area. If it is something specific in your site, you may prefer to put
it in a single config.php file. On my main site (www.fast.st) I have a
lot of very custom code for various functions, conditions, side menus,
the like. All of that is dumped in one big config file. Tidier than a
bunch of plugins, though I do use plenty of those as well. :)
Cheers,
Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to boltwire@googlegroups.com
To unsubscribe from this group, send email to
boltwire+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
