I dont know if this been mention before...
I'm pretty new to modyle-coding... but...

Why is xoops_version.php so inconsistant?

if the first part...

$modversion['name'] = _MI_MODUL_MODULENAME;

in the blocks part...

$modversion['blocks'][1]['name'] = _MI_MODULE_BLOCKNAME;

and so on...

but then in the config part...

$modversion[config][1]['name'] = '_MI_MODULE_CONFIG1NAME';

suddenly you must have the ' mark around the define for it to work properly, why is that?

also, there is a limit on the length of the define somewhere just beyond thirty characters (32?) Wich is a bit small considering how the naming convention is laid out.

Quote:

That migth explain a lot, I've been delving deeper and deeper into the XOOPS source lately and found the core to pretty good albeit quite undocumented.

Such a simple thing as to let the imagehandler handle separate users images letting each user upload/update their own images for the bb and other comments in paralell to having a global one that all or groups could use

Anyways, most seems well written, and the uploaderclass seems well written. I can definitly use it for what I'm doing.

It seems a lot of people keep doing the same basic stuff, the more I look the more reworked earlier stuff I see
most of it seems to be copied over without a real understanding of what its used for.

I'm sure your module will be better then mine in many regards since its my first one that alone will make it suffer but I'll do it anyway to get two things...

* My Way
* My Knowledge (upped hopfully)

Just wanted to mention here... since I been criticising the downloads module a bit

The actual classes for download and upload are not that bad Its the modules that makes it a bit "jiffy".

I think it also should tie in more to the automatic mime handling in php, but thats my view

Just though that I should mention that after looking through the code as I have done now.

And BTW...

The upload.php isnt bugged, it is supposed to > 0

The tests says, if there is anything in the mime-array and the mime-type doesnt exists, then it is false, otherwise its true.

The problem with that statement only comes when there isnt anything in the array, or rather, if its an empty array.
since it defaults to something, the module can leave it as it is or has to overide it and if they override it with a zero length array then I would consider it a bug in the module, not the class.

Well,
I dont know how Catzwolf modules looks or acts, I havent seen it in any newer revision. I tried to look for a download somewhere but I failed to find it. Maybe it solves my problems, maybe it doesnt. Right now I'm looking at all the XOOPS code and how they doen it to get a feel for it and my impression stays the same.

It works... but I dont think they follow their own coding rules, but perhaps I misunderstood them.

Anyways, If I find Catzwolfs module and can check it out somewhere, then I'll sure look into it, but I'm already far enough on my own to make it happen anyways, if for nothing else, so at least to learn how it fits together.

Quote:

I tried to, but I dropped it.

The code looks to be written by several different persons
with different understanding on how XOOPS should work.

The person who added the last stuff seems not to have understood smarty at all for example, if you look at submit.php you can see it has a template but its not used

It uses it's own configuration of mime-types instead of using php built in model and it's depends on the file tags to conclude a type and trusts the user to give the right size of the file.

This is all and good if you are gonna provide links to another site where that webserver is going to provide this information to the client, but its not good enough when you want to store the data localy (at least not to me)and serve
it through the php-scripts.

So what am I doing?

I'm building my own module, I've already gotten upload and download to work, with automatic mime-types and filesizes, what I'm doing right now is figuring out how to make it conform to xoops, and thats not so easy with the current documentation and differently written modules.

I have been reading the Wiki documentation on building a module, problem is that not even the "core" modules abide the rules as I see it. Rigth now I'm trying to find a module or documentation to provide me with the "true way" to make it work in a fully configurable XOOPS manner, and that takes longer than just putting the actual code together

There isnt even documentation on how to connect the MySQL database into it, it seems the rule is "read the friggin code" which would be well if people coudl stick to one way of coding

But I'm getting there and I'' try it out for a while.
BTW, I'm not writing a link module, mydownloads works fine for that. My goals a re a bit different.

* All files stored locally on server.
* User manages his/her uploads.
--* version
--* categories
--* permissions
--* screenshots
--* licenses
* Database will take care of filehandling, that means no
direct linking will be possible, everything will be
handled through php. That also means same filename can
exists as a download any amount of times.
* I will be scanning the files for viruses, exactly how
that will be done I havent yet decided.

Anyways, thats where it stands right now, with me looking at how I can get this into a XOOPS module.

Quote:

It probably will, I will check that out tomorrow.

Ok,

I summarize a fw problems I have with the download modules I've tried so far

* They have upload FILE as an option, the main idea with
upload (i.e the download modules) seems to be to LINK to
another website where the stuff hopefully still exists
when the person that wants to download it wants it.
To me this is a LINK not a download. And there is a
module for that.

* They all, the ones I've tried, upload to ONE directory and
use the name given by the uploader to save to, instead it
should save the filename in the db and use the upload
index as the savename for uniqueness.
another upload can otherwise overwrite the first

* Mimes seems to be handled in every separate module, that
might be better handled by a separate module and queried
by all the others.
Remove double work

* There doesnt seem to be any real method for several people
to "own" their own uploads. It should work as with the
comments and posts, the one that did them should be able
to "repair" or "edit" the upload and its info.

I havent seen the new stuff from catzwolf, sorry if that one
already has this.

Well,

I've started to rip the downloads_pro module apart, it has some interesting bugs (as I see it) and I need som features it hasnt got so I'm writing another one fitting my needs.

I will try to make it as "general" as possible.

I will use some code from the module that is working properly But I guess I have to check the license a bit closer before I release it.

well see where it ends up...

Duh!

I just found the very STATIC imagetypes in the submit.php for the screenshot files.

Stupid as I was I assumed that the selected mime-types for downloads would be for both the download AND the screenshot, but it was not valid for the screenshot which has its own, static types. (static as in not configurable from interface)

I'm currently adding that functionality.

I'm also trying to overcome the problem with multiple mimetypes for one file-ending, although, the easiest should be to just make the mime-types visible instead, I will probably go for that.

I will also try to make the mime-types administrable within the admin interface.

How is catman coming along with his module?

/Dhurgan

Ah yes, forgot to say.

Otherwise this module is a step in the rigth direction.
Now if the cat delivers, maybe thats even better
I still miss the keyword thing though, but the group permission stuff is good, even the user-permissions are a step in the right direction, even if I dont need it :)