Can we have language defines in your own language for this module please? Just attach them to this topic or email them to us.

Can someone please write a working document on how to install and use this module please? Again, either post in within this topic or directly to us.

Thanks

Catz

I understand, thank you!

Unfortunately it has not been the further development of ...

thank you catz..you make my day

I can't extract the zip archive. Do I need an updated decompressor?

Xoops deluging tool:

None All errors (0) queries (12) blocks (0) extra (2) timers (3)
Errors
Queries
SELECT * FROM config WHERE (conf_modid = '0' AND conf_catid = '1') ORDER BY conf_order ASC
SELECT sess_data, sess_ip FROM session WHERE sess_id = '7ebd7d7b670b39874df3a916acf9ea04'
SELECT * FROM users WHERE uid = '1'
DELETE FROM protector_access WHERE expire < UNIX_TIMESTAMP()
SELECT COUNT(*) FROM protector_access WHERE ip='85.70.153.208' AND request_uri='/modules/xoopsfaq/admin/category.php'
SELECT COUNT(*) FROM protector_access WHERE ip='85.70.153.208'
INSERT INTO protector_access SET ip='85.70.153.208',request_uri='/modules/xoopsfaq/admin/category.php',expire=UNIX_TIMESTAMP()+'60'
SELECT * FROM modules WHERE dirname = 'xoopsfaq'
SELECT * FROM config WHERE (conf_modid = '47') ORDER BY conf_order ASC
SELECT * FROM group_permission WHERE (gperm_name = 'module_admin' AND gperm_modid = '1' AND (gperm_groupid = '1' OR gperm_groupid = '2'))
SELECT COUNT(*) FROM `xoopsfaq_categories`
SELECT * FROM `xoopsfaq_categories`
Total: 12 queries
Blocks
Total: 0 blocks
Extra
Included files: 56 files
Memory usage: 1074120 bytes
Timers
XOOPS took 0.087 seconds to load.
XOOPS Boot took 0.033 seconds to load.
Module init took 0.054 seconds to load.


PHP 5.2 is needed, in documentation is not written...

Czech language file for XOOPS FAQ

here is the xoopsfaq old version documentation based on japanese manual (translated by google)

http://tinyurl.com/dc6ydc

my english is not good someone with good english can update this documentation

Quote:Don't forget
Murphy's Law: after all bugs are found, there is still one left.
and the law of Conservation of misery (no gain without drain): The code needed to resolve a bug, will introduce another bug.

But without laughter: Yes: we need progress, but not at all costs.
The point is: will we make a module for the elite (with PHP 7.8.9) or make we a module for everyone?
So, I restate my question: will the module function better or do more with filter_var as opposed with intval? (Maybe easier to program, but that is not the point.)
Quote:If it is simply duplicating the function, then it has no sense to complicate the program. If it brings no addition functionality, you can then better use the method that fits for all. When it brings better functionality (unrelated eg PHP 5 users can get their list sorted on a alternative way and PHP 4 users only in one way) then it makes sense to make a version dependent split way in the program.
Quote:Yes, they still do.
But from that same thread:
Seems there is a problem in blocksadmin
and they have difficulties to keep up with XOOPS 2.3:
Quote:Are we making XOOPS incompatible with XOOPS?

Quote:Is this not a bit reinventing the wheel? I think starting with the best module in the FAQ genre, would give more a headstart of it. After all, they are GPL, aren't they?

Catzwolf, I made my points, but it is your call!
Quote:Here, no problems with eg Winzip 8. What program do you use?
Maybe your archive is not complete and you may try to do the download again.
You may also try 7zip.

I'll focus on the Dutch translation, will send it to you when finished!

Quote:

Firstly the two functions do not do the same job, all intval does is force a variable into a certain type and for all intensive proposes this will work fine, however there is major difference between the two methods. Using filter_input ensures that the information comes from HTTP Method and forces it false, if not true. The input data will be filtered according to type and filter type. Then I can add further flags to determine what we will allow through the filter.

Using this method will build consistency when dealing with filters, there is plenty of documentation on this subject already on the internet for other developers to use as a reference and to help their understand of how these functions work..

The point is this do we have some sort of standards when dealing with this? Or do we write a completely new set of functions or do we use what is in PHP already? But you are quite right; I should have taken into account that not all users can use these functions.

The biggest issue with XOOPS over the last few years is this subject. There is not standard method of Input filtering within the core and everyone just uses their own methods and as we have seen, this always does not work. All I am attempting to do is put some standardisation within the whole framework and since this already is in PHP I didn’t see the need to reinvent the wheel.

As for making an independent version for both platforms, that would be wonderful if we lived in a world where I had all the time needed. In reality, I am not going (personally) spend my time writing for an obsolete package that is currently no longer supported by the developers. If they are not going to support it why should I? It doesn’t make sense to me.

The other thing is this, we at XOOPS always urge our users to use the latest version and update when possible. This way they can be assured that they will get newer features and a safer XOOPS. We can joke about introducing more bugs as much as we fix, but that’s the nature of the beast when we program, and if we all took the stance that its better to stay with one version because it seems to do the job, then we programmers wouldn’t be needed really lol

Quote:

It as already has been made clear from Smart factory that they do not intend on keep compatibility with XOOPS 2.3 and the move of all their modules is a big indication that that they are moving further away from Xoops. The point is that these two systems are going to grow further and further apart to the point they will not be the same system and we would be deluding ourselves if we expect them to keep up compatibility. Then again, they could always write a version both for XOOPS and IMCMS.

Quote:

Compatibility in reality has to end somewhere and we have to be kidding ourselves if we expect a product to continually support outdated code or other dependant programs. We wouldn’t expect every new program to run on Windows 95 or Windows NT would we? Same has to be said with Xoops.

Quote:

To be quite blunt and honest, that module is based on a module I did 5 years ago and much of the code base hasn’t changed in many respects, and to change that module over to what I would consider better cleaner code, would be a developers nightmare.

I am not saying that the module is bad, I am saying it will probably be quicker starting the way I did and then to add the features that would be required to get this module up to scratch.

I think what a lot of people don’t seem to realise is this. This drive is about getting a lot of older modules working again on XOOPS 2.3. My hope with ‘Move to Blue’ drive is to highlight the fact that we are trying to push module development back into our community. We might even bring back old developers and more importantly we might gain new developers. Right now the focus is not about building the élite module for everyone. If that was the case, I would have spent another week developing XoopsFAQ into a module that would have been on par with SmartFAQ, but that wasn’t my objective though.

The fact is this; we have lost a lot of module developers from our community because we didn’t put enough effort into giving them the help and tools required. Again I aim to change that.

I hear what you’re saying, though I initially don’t agree with everything you’re saying, I do however respect ‘yours’ and ‘everyone’ else’s opinion on this matter and I have taken this onboard for the future.

Quote:

I used winzip 12 here, but I used legacy mode to archive these up and it should be compatible with any version (apparently).

Catz

If this modules are to be XOOPS 2.3 compatible than they should work with php4(supported by this version), my opinion. Besides I doubt there is a need to use php5 just to clean a single request in a single file.

As for smartfaq I have to agree with catz. Goal is not to make a better module, is to make a functional module that others can work on and improve.

I notice a wfp_ function inside one of the classes but could not find where it was defined. I did not installed the module to check this out, it may be producing an error.

Also I notice a method like get_objs or something that performs two queries, one to get a count of all available objects and other to get just a limited number of objects. I think it would be better to use just one query, count the resulting array, and then unset the not need objects according to the criteria.
Again, did not tested it.

Thanks for the update and for your time.