starred/ViMbAdmin-opensolutions

Fork 0

mirror of https://github.com/opensolutions/ViMbAdmin.git synced 2026-04-26 00:36:00 +03:00

[GH-ISSUE #34] Use PostfixAdmin core code? #29

New issue

Closed

opened 2026-02-26 09:35:17 +03:00 by kerem · 5 comments

kerem commented

2026-02-26 09:35:17 +03:00

Owner

Originally created by @cboltz on GitHub (Feb 14, 2013).
Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/34

Hello,

I'm one of the PostfixAdmin authors and would like to ask if you are interested in using the PostfixAdmin core code instead of re-inventing the wheel all the time ;-)

I'm currently working on a full rewrite of PostfixAdmin, which has PHP classes for each part (AliasHander, MailboxHandler, AliasdomainHandler, AdminHandler etc.) that does all the work, and a common edit.php that works for all of them. (You can find the code in SVN trunk on sf.net/projects/postfixadmin - this will become the 3.0 release.)

This also means: You could use the *Handler classes and would only have to maintain your version of edit.php as a "skin". You'd also get all new features (for example alias domains and a commandline client) and bugfixes in PostfixAdmin for free ;-)

If you are interested or have any questions, just reply here, join the #postfixadmin channel on freenode or the PostfixAdmin mailinglist on sourceforge.

Regards,

Christian Boltz

Originally created by @cboltz on GitHub (Feb 14, 2013). Original GitHub issue: https://github.com/opensolutions/ViMbAdmin/issues/34 Hello, I'm one of the PostfixAdmin authors and would like to ask if you are interested in using the PostfixAdmin core code instead of re-inventing the wheel all the time ;-) I'm currently working on a full rewrite of PostfixAdmin, which has PHP classes for each part (AliasHander, MailboxHandler, AliasdomainHandler, AdminHandler etc.) that does all the work, and a common edit.php that works for all of them. (You can find the code in SVN trunk on sf.net/projects/postfixadmin - this will become the 3.0 release.) This also means: You could use the *Handler classes and would only have to maintain your version of edit.php as a "skin". You'd also get all new features (for example alias domains and a commandline client) and bugfixes in PostfixAdmin for free ;-) If you are interested or have any questions, just reply here, join the #postfixadmin channel on freenode or the PostfixAdmin mailinglist on sourceforge. Regards, Christian Boltz

kerem closed this issue

2026-02-26 09:35:17 +03:00

kerem commented

2026-02-26 09:35:18 +03:00

Author

Owner

@lenada commented on GitHub (Feb 22, 2013):

To me http://sourceforge.net/p/postfixadmin/code/1435/tree/trunk/edit.php still looks very spagetti. No offence but I think opensolutions have a good point in reinventing the wheel

@lenada commented on GitHub (Feb 22, 2013): To me http://sourceforge.net/p/postfixadmin/code/1435/tree/trunk/edit.php still looks very spagetti. No offence but I think opensolutions have a good point in `reinventing the wheel`

kerem commented

2026-02-26 09:35:18 +03:00

Author

Owner

@cboltz commented on GitHub (Feb 23, 2013):

Thanks for your feedback!

edit.php supports creating and editing all things (mailboxes, aliases, admins etc.) and reconfigures itsself based on the thing to edit, which also means it needs some pragmatic[tm] coding. I wouldn't call it spaghetti ;-) but that might depend on the POV (and I'm of course open to suggestions how to enhance the code). As I said, edit.php is just a frontend / "skin", and is the part ViMbAdmin would probably need to replace anyway.

For ViMbAdmin, the more interesting code are the classes in model/*Handler.php. They do all the work and are quite easy to use.

To give you an example, here's how to edit an alias:

<?php
define('POSTFIXADMIN_CLI', 1); # test this file on the commandline with "php demo.php"

# load config, texts etc.
include('common.php'); 

#alias to edit
$id = 'info@example.com';

# new settings for this alias
# (fields that are not given will keep their old value)
$values = array(
        'goto'   => array('foo@example.com', 'bar@example.com'),
        'active' => 1,
);

$admin = "admin@domain.tld"; # optional, enables permission checks
$handlerclass = "AliasHandler";
$new = 0;

$handler = new $handlerclass($new, $admin);

# check if Alias $id exists and $admin has permissions to edit it
if (!$handler->init($id)) {
        print "Error: ";
        print_r($handler->errormsg);
        exit;
} 

# hand over and validate $values
if (!$handler->set($values)) {
        print "Error: ";
        print_r($handler->errormsg);
        exit;
}

# finally, store everything in the database
if (!$handler->store()) {
        print "Error: ";
        print_r($handler->errormsg);
        exit;
}

When using AJAX to validate the input on the fly, stop after $handler->set() and check if there's for example an error in the 'goto' field:

if ( isset($handler->errormsg['goto']) ) {
    print "Error in goto field: " . $handler->errormsg['goto'];
}

Does this still look like spaghetti? ;-)

@cboltz commented on GitHub (Feb 23, 2013): Thanks for your feedback! edit.php supports creating and editing all things (mailboxes, aliases, admins etc.) and reconfigures itsself based on the thing to edit, which also means it needs some pragmatic[tm] coding. I wouldn't call it spaghetti ;-) but that might depend on the POV (and I'm of course open to suggestions how to enhance the code). As I said, edit.php is just a frontend / "skin", and is the part ViMbAdmin would probably need to replace anyway. For ViMbAdmin, the more interesting code are the classes in model/*Handler.php. They do all the work and are quite easy to use. To give you an example, here's how to edit an alias: ``` php <?php define('POSTFIXADMIN_CLI', 1); # test this file on the commandline with "php demo.php" # load config, texts etc. include('common.php'); #alias to edit $id = 'info@example.com'; # new settings for this alias # (fields that are not given will keep their old value) $values = array( 'goto' => array('foo@example.com', 'bar@example.com'), 'active' => 1, ); $admin = "admin@domain.tld"; # optional, enables permission checks $handlerclass = "AliasHandler"; $new = 0; $handler = new $handlerclass($new, $admin); # check if Alias $id exists and $admin has permissions to edit it if (!$handler->init($id)) { print "Error: "; print_r($handler->errormsg); exit; } # hand over and validate $values if (!$handler->set($values)) { print "Error: "; print_r($handler->errormsg); exit; } # finally, store everything in the database if (!$handler->store()) { print "Error: "; print_r($handler->errormsg); exit; } ``` When using AJAX to validate the input on the fly, stop after $handler->set() and check if there's for example an error in the 'goto' field: ``` php if ( isset($handler->errormsg['goto']) ) { print "Error in goto field: " . $handler->errormsg['goto']; } ``` Does this still look like spaghetti? ;-)

kerem commented

2026-02-26 09:35:18 +03:00

Author

Owner

@lenada commented on GitHub (Feb 23, 2013):

@cboltz this is probably not the right place to review code of a different project ;) Where would be the appropriate place to give feedback/review? SF?

@lenada commented on GitHub (Feb 23, 2013): @cboltz this is probably not the right place to review code of a different project ;) Where would be the appropriate place to give feedback/review? SF?

kerem commented

2026-02-26 09:35:18 +03:00

Author

Owner

@cboltz commented on GitHub (Feb 23, 2013):

yes, sourceforge ( http://sourceforge.net/projects/postfixadmin/ ) is a good place - either in the forum or subscribe to the postfixadmin-devel mailinglist.

If you like IRC, you can also meet me in the #postfixadmin channel on freenode. I'm usually there in the evening (CET).

@cboltz commented on GitHub (Feb 23, 2013): yes, sourceforge ( http://sourceforge.net/projects/postfixadmin/ ) is a good place - either in the forum or subscribe to the postfixadmin-devel mailinglist. If you like IRC, you can also meet me in the #postfixadmin channel on freenode. I'm usually there in the evening (CET).

kerem commented

2026-02-26 09:35:18 +03:00

Author

Owner

@barryo commented on GitHub (Sep 10, 2013):

Sorry for the late reply - we won;t be using Postfix core code but thanks for the suggestion. V3 is already complete bar some final review and tests and has been for some time. It would be a backward step to change now.

@barryo commented on GitHub (Sep 10, 2013): Sorry for the late reply - we won;t be using Postfix core code but thanks for the suggestion. V3 is already complete bar some final review and tests and has been for some time. It would be a backward step to change now.