For some reason last night when I was posting this, I knew you would be the one to respond to this, thanks :)

I had an idea that this could be possibly done but it was only really last night I put my mind to it and came up with a working solution.

The whole point is even with smarty we are using arrays and objects all the time, even though they appear as smarty tags, in reality they are still what they are.

I see no real difference really....



So to access we would do



Basically, all we are doing is taking an array of object and turning them into an array of arrays, which means adding more time to the execution of the script.

We the developers still have full control over the logic and the designers would still treat those as logic and in very much the same way they would now.

But yes there could be a temptation to do our logic right here in the template, but there will always be some logic involved no matter what with smarty and this just 'cuts' out the middle man I think.

Plus, really all our logic should be done within the handlers and not within the controller part of our modules. Which it seems a lot of us developers still do.

Smarty has been in Xoops since around 2003-4 when version 2 came out and that was almost 7 years ago and still after all that time there is no way to add your own smarty plug-ins directly to the core... until now.....

Yes, I have always wanted to create different plug-ins for my modules, but that means getting the users to move them, write code to move them hoping you don't over write other ones and waiting for the core to write a way of adding them.

Well, I finally figured out a way to do it without hacking at the core, but it does require a small modification and it does come with some risks. It's not perfect, but it should work.

First to let you understand how smart and Xoops work together.

Xoops uses a class classed xoopsTpl to call smarty and configure some required variables.

When a page is rendered, a file called 'header.php' is called and doing this runs an instance of xoopsTpl and makes it ready for use.

Once the header.php file has been run, Xoops will include the next part which will be the main body of the script, this could be your frontpage or a module and this is when most of the page information is created.

Once the main body information has been created, Xoops will finally include a file called, 'footer.php' and this is when all the nice stuff is done. Xoops will gather all that information and then create the templates that are finally shown on your screen. This is when smarty is used and where we can take advantage of the smarty plug-ins, pre and post loaders to change or add other information we want via our module.

Now how do we do this? There are a couple of ways,

1. Create new Smarty plugins
2. Create pre and post loaders.

1. The Smarty plug-in.

We don't want to make life hard for ourself so first, create a couple of new folders in our module folder.

Quote:

Now once we have done that, lets create out smarty plug-in and then save it to our new folder. As below we have our very basic new smarty plug-in.



so now we should have in our path:

Quote:

Now the last part. We need to added our path to the smart plug-in path and we need to add a line directly after the include XOOPS_ROOT_PATH . '/header.php'; in our code:

like this:


This will tell smarty to look in our new path as well as keeping the old ones. Now, this is the 'HACK' part of this and if done wrong could cause some problems. This is not perfect, but it will allow module developers to add their own smarty plug-ins.

2. Pre and post filters.

here is an example directly taken from smarty. It will let you understand how easy it is to do a pre and post filter on the templates.



Post filter:



It is as easy as that...

Enjoy,

ATB

Catz

For the last few months I have been playing around with different ideas I have been having regarding getting more for my code using less.

The best way is to make use of smarty more and more, so the less code I have, in reality it is better for me. This means there is less to go wrong and easier to maintain.

The normal way of assigning variables is through smarty and normally this would be done in this manner(or something like it)



This is the way most of us do it, but there is an easier way and one that will make it easier in the long run.



And now you can access the Object straight from Smarty, using a line such as:



Or like this:






I hope others find this useful and helpful :)

ATB

Catz

WARNING: I wouldn't follow that advice on the website, unless you want to lose a lot of user information.

To do this correctly you will have to do a lot more than that... there will be many other modules that use a 'User ID' and if you follow this advice they may not match up afterwards.

There are three ways you can do this.

1. Use blocks by positioning them where you ant on the front page. You can add custom blocks easily via the admin side and you can use the Hack on Xuups.org (or com) to place blocks anywhere you want via Smarty templates.
2. You can have any module you want to feature as your home page. So if you use a module such as WF-Channel to add html/pages etc then you can set a page and have that as your front page.

You can set a module as your home page by doing the following:
1 .Go into the admin cpanel.
2. Navigate to Site Preferences and then General Settings.
3. Near the top you shall see the option 'Module for your start page'
4. Use the pull-down selector and select a module you want to feature as your homepage.
5. You can edit the template:

/modules/system/template/system_homepage.html

and fill that with loads of html and images (if you feel like going down that route lol).

I have done this from memory so... I think that is right though.

Hope that helps.

ATB

Catz

I think all of you have gone right off in the wrong direction from what she is asking, she wants to know how to prevent the SAME user from a different IP from logging into the site. This way, a user who has paid membership cannot just hand over their login details to someone else and then expect still to login to the system.

Sure protector will ban an IP address and stop them from logging into the system, but she first needs to know the IP address and secondly, she really doesn't want to sit there examining everyone who logs in to see what IP address they are using.

Now while this can be done, there are issues that need to be looked at first.

Not every IP address is static, for example, DSL connections IP addresses are rotated frequently and this is where the problem will arise. So, preventing a user from logging in with a different IP address, may affect legitimate users in reality.

Ok, the only place I found a line of code that is very much like that is.....in this file:

modules/newbb/templates/newbb_thread.html and it should be around line 26.

I hope that helps,

I would also would suggest that you download a nice little program called powerGrep or WINgrep, it allows you to search for text inside files and it is really handy for things like this. :)

Okies, this is strange, I just checked to see if that line was in 3.08 and I cannot find it anywhere, but I do find it in v4 RC lol, you gotta love Xoops modules huh.

Quote:

I believe that you're using CBB v4 RC, if the information above is correct.

I cannot find a download for CBB v3.08 so I uploaded it to my own website:

Download CBB v 3.08 here

I would actually advise against using this version in its current forum. It is just a RC and it's far from a working version.

Download CBB version 3+, I believe it is on Xoops Soureforge.