PHP and/or SQL debug information revealing any errors?

It's actually called SmartMail

We are currently in testing/development of the method to actually send out the emails and it will not be browsable to begin with (i.e. archive of previous newsletters is not available to visitors) but will come later.

As far as I can see, it has been fixed in 2.0.15 - not tried, but looked at the code.

The xoops.org front page is cached with some minutes caching, so replies to threads are not immediately visible on the front page. If that is what you mean

It helps if you describe the problems better.

Might also help others, if answers are given in the forums.

It is a difficult subject to discuss as the implications can be far-reaching.

If we divide modules into ports or native XOOPS modules, there will be borderline cases that could go either way. As Tom says, a ported module could be fully xoopsified or merely using XOOPS mainfile and have a xoops_version.php

But is it a measure of quality? Both yes and no, I'd say. No, because it says nothing about the quality of the code. Yes, because the more XOOPSified it is, the higher the chance of it working fully with future XOOPS versions - and the higher the chance of someone else being able to do further work on parts of the module.

On one hand, a simple checkbox for "ported module" could be added and show an image that says that this is not a native XOOPS module - but it would not have the gradient in how much it has been XOOPSified. On the other hand, it would not make sense to have module developers rate their modules on a scale that goes from "basic port" to "fully XOOPSified" with several steps inbetween. And having qualified XOOPS module developers go through each module and assign a value would not be practically possible.

We shall also consider the work involved in creating and managing categories for these two types of modules - there are 60 categories in the modules repository at the moment. Even though there wouldn't be ports in each of these, it would still be necessary to create quite a number of categories for ported modules.

It's tough.

At this point, I'm asking myself what we will accomplish from having this rating/distinction/marking of modules as being ports or not. I'd rather see the QA checklist being incorporated as it would give quite a few answers to the gradient. But again, that is a question of resources.

And for me as a module user, it doesn't really matter _that_ much (except that it would be nice to have a full QA checklist) whether the module is fully XOOPS coded or a basic port. If it doesn't work as I want it to or is too cumbersome because it uses a completely different interface, I'll find something else.
Or use it as inspiration for a new module.

We use the dev.xoops.org project trackers for reporting inwards and xProject on smartfactory.ca for reporting outwards - however, I'm not sure it has been opened to the public, it may have to do with access permissions as we don't want feature requests and bug reports in xProject (it should show what WE think should be there - not (necessarily) everything that is suggested)

In regards to limiting the sending, we work on a throttle mechanism in the actual mail sender, where a maximum number of mails sent per hour can be configured as well as how many in a batch/job.

This is meant to come in the first release.

Our goal is to have a central mailer API that can replace the XOOPS built-in (that "just" uses PHP's mail function or an SMTP server directly) for sending out any mails through XOOPS.
It would also open up for a better notification method where submitting a forum post does not potentially send out hundreds of emails, thus lagging the submissal process and making the user think that it hasn't been submitted.

This will come at a later point.

Check this FAQ:
How do I move my site from one server to another?

And see if it works.
If not, ask again, giving information on what you have done and what happened in as much detail as possible.

Just to clarify to avoid misunderstandings:
I only want database tables to be created, when there actually ARE tables to create.

Basically, my thought is that when I install a module through the modules administration, it is installed. I don't have to run installation scripts to setup the database tables (since it is very trivial to do this the XOOPS way, I find this a very reasonable requirement), when it's installed, I'm done with installing and can immediately go to configuring it (using my XOOPS admin account - not by creating a new one in the "module").

Basically, if it walks like a horse and jumps like a horse, I might as well use it as a horse and call it a horse (don't take too literally, please).

If language files HAVE to be XOOPS-structured and use XOOPS functions etc. we'll have to disqualify a great number of modules such as Wordpress and the ZenCart module.

Maybe there should be a better distinction (category for ported scripts) or a text saying "This module is a port of scriptname version x.y.z"

Another note is that I am not commenting on Wizanda's statements, modules or anything - only Bender's question.

Personally, I regard this a XOOPS module:

1) Installs through XOOPS module admin - i.e. database tables are created during installation
2) Navigational through main menu (if it has front-end pages)
3) Access governed by XOOPS module permissions and XOOPS user login

If those three criteria are fulfilled, it is a XOOPS module by my standards.

Language and admin stuff using XOOPS' structure would make it even more a XOOPS module (you'll notice that I have gradients ) but if the three above are fulfilled, I can use it in any way as if it was any other XOOPS module.

Otherwise the XOOPS port of ZenCart, Wordpress and similar would not be XOOPS modules - which I think they are.

So in conclusion; if a module is completely XOOPS'ified with language, admin, blocks and templates it would be great - but to the webmaster installing it on his or her site, it doesn't matter that much how it was programmed. If it has hardcoded MySQL stuff in it and XOOPS changes to be usable on PostgreSQL and the module doesn't work anymore, it is the problem of the module developer - we'll have to accept that, I think. However nice it would be to have perfect XOOPS modules that will always be working on all future versions of XOOPS, we just cannot be sure unless the module is completely using XOOPS's structure - and can we really expect to see a ZenCart system as a XOOPS module? Let's not overestimate the influence of XOOPS on other scripts (at least until XOOPS 2.4)