In this case, you will have to either install MailBul in a subdomain for b.com domain like email.b.com or you can still use the install from email.a.com but use a tracking domain for b.com domain.

A tracking domain is simply a CNAME(DNS Record).
In our case, we define a cname for b.com domain, namely email.b.com that will point to email.a.com subdomain.

Once we do this, propagation can take up to 48 hours, so after 48 hours, we can go in the backend of MailBul website and add a new tracking domain, the email.b.com domain. Once we did this, to check if everything works properly, we have to access http://email.b.com and we should get same page that we get when accessing http://email.a.com. If it’s not showing same page, then you don’t use a dedicated ip address for a.com domain and you should.

Now, our tracking domain is in place, all we have to do si to associate it with a delivery server and all emails that will be sent via that delivery server will change all the links from email.a.com into email.b.com.

SENDING DOMAINS:
You should use sending domains only if your delivery servers do not sign your emails with DKIM, because the only purpose of sending domains is to identify the domain from the “FROM” or “Return-Path” of your headers and generate a dkim signature for them.

Like in the above case, if your domain is b.com and you send emails from contact@b.com, then you can add a sending domain (b.com) for which MailBul will generate the dkim records (you have to add the public key into your dns records, as a TXT record).

Once the domain is confirmed, each time when MailBul finds an email that contains the domain b.com in it’s FROM/Return-Path headers it will append the right DKIM signature.

Note: If you are using CloudFlare or a similar service make sure you change the DNS records from the proper place.

The post What tracking and sending domains actually are? appeared first on MailBul KB.

Since version 1.3.6.9 we introduced a console command that you can run in order to generate all the translation files at once.
The command name is translate and can be used as follows:

-bash-4.2$ /usr/bin/php /absolute/path/to/apps/console/console.php translate
Please provide the language name(i.e: English) :  Romanian
Please enter the 2 letter language code(i.e: en) :  ro
Please enter the 2 letter region code(i.e: us). This is optional, leave empty if you are not sure. :  
Do you agree to create the translation messages in: /var/www/vhosts/domain.com/httpdocs/apps/common/messages/ro ? (yes|no) [yes]:

Above command will create all the proper files needed for translation and it will also create the language in the web interface.

[Web interface]

MailBul version 1.1 introduced multi-language, internationalization and translation support.

You can now create new languages from your backend panel and with the help of the “Translate” extension, let MailBul EMA collect the messages to be translated from the entire application so that later you can translate everything into your language.
Once a translation is ready, it becomes a language pack that can be zip archived and distributed to be installed in any MailBul EMA installation from the backend panel in a few clicks.

In case there is no language pack available for your language so that you can easily install it, you’ll have to follow these steps to enable translation:

1. Go to languages area (backend) and add your language manually (add language name and language 2 letter code).
2. Go to extensions area(backend) and enable the translate extension.
3. In the extension area, click on the translate extension title so that you are directed to the extension settings page.
4. Activate message collecting.

Once message collecting is activated, all your messages will be stored under the directory /apps/common/messages/lang_code wherelang_code is your language code, i.e: de/it/es etc.

While you browse your website, messages from the sections you visit will be written in files and you can translate them on the fly.
Once you are done translating for your language, you can save the language folder locally on your computer as lang_code.zip and distribute it as a language pack so others can use it as well.

Notes:
1. Once you are done creating translations for a certain language, make sure you disable the translate extension, it doesn’t make sense to always keep it active.
2. Make sure the messages directory(/apps/common/messages/) is writeable by the web server, otherwise translation files will not be created nor messages will be added in files.

The post How translation works ? appeared first on MailBul KB.

By default, MailBul runs in production mode, that is, no errors are show to the end user. That also means that if you get a serious error (most of the time a file permission error) the application will stop running and you will get a white screen.
If this happens, most probably you will open a support ticket but in order for me to be able to help you, you will have to enable debugging so that i can see exactly the error.

In order to enable debugging, all you have to do, is to open the ‘apps/init.php’ file and at line 16 add:

define('MW_FORCE_DEBUG_MODE', true);

Then save the file and reload the app in your browser to see the actual issue.

The post Enable debugging appeared first on MailBul KB.

/home/yourdomain/public_html

and accessible at

http://www.yourdomain.com/

then in

/home/yourdomain.com/public_html/.htaccess

you will put:

# BEGIN rewrite rules
<IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteBase /   
  
    # BACKEND APP
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
    RewriteCond %{REQUEST_URI} ^/backend(/.*)?$
    RewriteRule backend/.* backend/index.php
  
    # CUSTOMER APP
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
    RewriteCond %{REQUEST_URI} ^/customer(/.*)?$
    RewriteRule customer/.* customer/index.php
  
    # API APP
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
    RewriteCond %{REQUEST_URI} ^/api(/.*)?$
    RewriteRule api/.* api/index.php
  
  
    # FRONTEND APP
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} !.*\.(ico|gif|jpg|jpeg|png|js|css)
    RewriteRule . index.php
</IfModule>
# END rewrite rules

Please note that the above rules can also be generated from backend of your application by going to Backend > Settings > Common.

The post Apache .htaccess for MailBul appeared first on MailBul KB.

First step is to disable the cron job that triggers the send-campaigns command, the one that runs each minute. This is very important, so please make sure you do it.

Once that cron job is disabled, it means we need to trigger campaigns sending manually from command line. In order to do this, if your cron job for send-campaigns looks like:

/usr/bin/php -q /var/www/html/apps/console/console.php send-campaigns >/dev/null 2>&1

Then you need to run the following command from command line:

/usr/bin/php -q /var/www/html/apps/console/console.php send-campaigns --verbose=1

Basically you just remove

>/dev/null 2>&1

and you add

--verbose=1

.
Once you run the above command in your ssh terminal, you will notice that MailBul will start outputing information about what it is currently doing and the time it takes for each task.

Identify the task that takes longest time and you will find out what your sending problem is.

Once you know the problem and you have fixed it, you should enable the send-campaigns cron jobs so that sending campaigns resumes.

The post Debug send-campaigns command. appeared first on MailBul KB.

Please note that the below configuration is going to use php-fpm for what is worth.

/etc/nginx/nginx.conf

# For more information on configuration, see:
#   * Official English Documentation: http://nginx.org/en/docs/
#   * Official Russian Documentation: http://nginx.org/ru/docs/

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /run/nginx.pid;


events {
    worker_connections  1024;
}


http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;

    #gzip  on;

    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;

    index   index.html index.htm;

    #root /usr/share/nginx/html;

  # this is the section that matters for MailBul.
    server {
     listen      80;
     server_name domain.com;
     root        /usr/share/nginx/html;

     location / {
         if (!-e $request_filename){
         rewrite ^(/)?api/.*$ /api/index.php;
         }
         if (!-e $request_filename){
         rewrite ^(/)?customer/.*$ /customer/index.php;
         }
         if (!-e $request_filename){
         rewrite ^(/)?backend/.*$ /backend/index.php;
         }
         if (!-e $request_filename){
         rewrite ^(.*)$ /index.php;
         }
         index  index.html index.htm index.php;
     }

     #error_page  404              /404.html;

     # redirect server error pages to the static page /50x.html
     #
     error_page   500 502 503 504  /50x.html;

     # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
     #
     location ~ \.php$ {
         fastcgi_split_path_info  ^(.+\.php)(.*)$;

         fastcgi_param  PATH_INFO        $fastcgi_path_info;
         fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
         include fastcgi_params;

         fastcgi_pass   127.0.0.1:9000;
         fastcgi_index  index.php;

         fastcgi_read_timeout 600s;
         fastcgi_send_timeout 600s;
     }

     # deny access to .htaccess files, if Apache's document root
     # concurs with nginx's one
     #
     location ~ /\.ht {
         deny  all;
     }
   }
}

The post Nginx server basic configuration for MailBul appeared first on MailBul KB.

Step 1:

Step 2:

Step 3:

Step 4:

Step 5:

That’s it.

The post Enable the file manager for editor files appeared first on MailBul KB.

If the “Campaigns at once” setting from Backend -> Settings -> Cron is set to 5 for example and you set 5 autoresponders to send this means that the 6th campaign, either regular, either autoresponder won’t trigger anymore because those 5 slots are occupied by those 5 autoresponders.

You can simply increase the number of campaigns at once to alleviate this, but this will only work till certain point.

A better way is to simply split the send-campaigns cron command into two separate commands.
If your cron job for send campaigns is looking like:

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns >/dev/null 2>&1

Then you can simply edit it like:

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=regular >/dev/null 2>&1

Then add a new cron job for autoresponders:

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=autoresponder >/dev/null 2>&1

What the above does is pretty self explatory, each command will process separately a type of campaigns, that is one will process regular campaigns and one will process autoresponders.

Those commands still depend on the number of “Campaigns at once” set in your Backend -> Settings -> Cron, so if you set 10 campaigns at once, it means the system will process 10 regular campaigns and 10 autoresponders at once.

This can cause issues because again if there are more then 10 autoresponders active at once, it can happen that not all of them can be processed and if you increase the number of Campaigns at once from backend the new limit will also apply to regular campaigns, which might be not what you want.

If that’s the case, the send-campaigns command also accepts a limit parameter so you can explicitly say:

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=autoresponder --campaigns_limit=50 >/dev/null 2>&1

And that means that regardless of your backend settings for campaigns at once, the system will always process 50 autoresponders at once and the backend settings are not taken into consideration anymore.

You can do the same for regular campaigns:

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=regular --campaigns_limit=20 >/dev/null 2>&1

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=regular --campaigns_limit=50 --campaigns_offset=0 >/dev/null 2>&1
* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=regular --campaigns_limit=50 --campaigns_offset=50 >/dev/null 2>&1
* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=regular --campaigns_limit=50 --campaigns_offset=100 >/dev/null 2>&1

* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=autoresponder --campaigns_limit=10 --campaigns_offset=0 >/dev/null 2>&1
* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=autoresponder --campaigns_limit=10 --campaigns_offset=10 >/dev/null 2>&1
* * * * * /usr/bin/php -q /home/domain/public_html/apps/console/console.php send-campaigns --campaigns_type=autoresponder --campaigns_limit=10 --campaigns_offset=20 >/dev/null 2>&1

The post Process regular campaigns and autoresponders separately appeared first on MailBul KB.

After the files are uploaded in place, you will have to import the existing database into your new server(command line or phpmyadmin) and then edit the configuration file to reflect the new database data.
The configuration file you need to edit is located at “apps/common/config/main-custom.php“.

Next, you’ll have to make sure following folders are writable by the web server: (chmod -R 0777)

/apps/common/config
/apps/common/runtime
/backend/assets/cache
/customer/assets/cache
/frontend/assets/cache
/frontend/assets/files
/frontend/assets/gallery
/apps/extensions

And finally, make sure you add your cron jobs on the new server.
You can find the list of cron jobs you have to add here.
That’s pretty much it.

COMMAND LINE:
Doing the above steps from command line will be the easiest and here are the steps to do it, in big lines to give you an idea:
We will assume that on the old server, MailBul files are located in /home/MailBul-old/public_html/ and on the new server the files are located in /home/MailBul-new/public_html.

On the old server:

# change directory to MailBul home folder
cd /home/MailBul-old

# create an archive out of the entire public_html folder
tar -pczf backup.tar.gz public_html

# create a database backup
mysqldump -u YOUR_OLD_MailBul_USER -p YOUR_OLD_MailBul_DATABASE_NAME > backup.sql

# running a ls -al in /home/MailBul-old we should see both, backup.tar.gz and backup.sql files.

#additionally, you can move these two files into a public accessible location on the old server so that you can download them when you are on the new server

# create a temp dir
mkdir /home/MailBul-old/public_html/tempdownload

#move files into it
mv /home/MailBul-old/backup.tar.gz /home/MailBul-old/public_html/tempdownload/
mv /home/MailBul-old/backup.sql /home/MailBul-old/public_html/tempdownload/

On the new server:

# change directory to the new home
cd /home/MailBul-new

#fetch the files from old server:
wget http://www.MailBul-old.com/tempdownload/backup.tar.gz
wget http://www.MailBul-old.com/tempdownload/backup.sql

# untar the files, will extract the public_html directory which will override the existing public_html directory
tar -zxvf backup.tar.gz

#import the database
mysql -u YOUR_NEW_MailBul_USER -p YOUR_NEW_MailBul_DATABASE < backup.sql

# adjust the configuration of the app to reflect the new database.
# Make sure you edit the below file and add right data:
nano /home/MailBul-new/public_html/apps/common/config/main-custom.php


# make sure the needed folders are writable, we have already a shell script for this:
# step 1, make it executable
chmod +x /home/MailBul-new/public_html/apps/console/commands/shell/set-dir-perms
# step 2, execute it
/home/MailBul-new/public_html/apps/console/commands/shell/set-dir-perms

#finally, add the cron jobs:
#find the php binary, should return something like /usr/bin/php
which php

# make sure it is the CLI binary, you should see (cli) word in the output of the command:
/usr/bin/php -v

# open crontab in edit mode to add the cron jobs:
crontab -e

# and write the crons:

# Campaign sender, runs each minute:
* * * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php send-campaigns >/dev/null 2>&1

# Transactional emails sender, runs once at 2 minutes: (since 1.3.4.5)
*/2 * * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php send-transactional-emails >/dev/null 2>&1

# Bounce handler, runs once at 10 minutes:
*/10 * * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php bounce-handler >/dev/null 2>&1

# Feedback loop handler, runs once at 20 minutes:
*/20 * * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php feedback-loop-handler >/dev/null 2>&1

# Process delivery and bounce logs, runs once at 3 minutes:
*/3 * * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php process-delivery-and-bounce-log >/dev/null 2>&1

# Cleanup command to run daily:
0 0 * * * /usr/bin/php -q /home/MailBul-new/public_html/apps/console/console.php daily >/dev/null 2>&1

That’s it.

The post Migrating MailBul to a new server appeared first on MailBul KB.

Here is a brief example of what you will have to add inside your campaign template to make use of this feature:

<!DOCTYPE HTML>
<html>
<head>
   <meta http-equiv="content-type" content="text/html" />
   <title>XML FEEDS</title>
</head>
<body>
    [XML_FEED_BEGIN url='http://www.bata.com/news/feed/' count='5']
        <table>
            <tr>
                <td>
                    <a href="[XML_FEED_ITEM_LINK]">
                        <img src="[XML_FEED_ITEM_IMAGE]" width="100" height="100"/>
                    </a>
                </td>
                <td>
                    <strong>[XML_FEED_ITEM_TITLE]</strong><br />
                    <p>[XML_FEED_ITEM_DESCRIPTION]</p>
                </td>
            </tr>
        </table>
    [XML_FEED_END]
</body>
</html>

The [XML_FEED_BEGIN] tag accepts following arguments:
url – string – the url from where we will fetch the feed items. Mandatory.
count – integer – the number of items you want to receive back from the feed. Optional.
Added in 1.5.1:
offset – integer – the number of items you want to skip loading. Optional.
days-back – integer – the number of days to look back for posts. Optional.
no-item-action – string – what action to take when no items are found in the feed. Valid values: postpone-campaign(postpones the campaign till next day). Optional.
send-only-unique-items – string – if we should only send unique items. if no items are found, then  no-item-action is applied. Valid values: (yes or no). Optional.

Below is a list with all the tags accepted for XML feeds:
[XML_FEED_ITEM_TITLE] – The item title (the title of a post for example)
[XML_FEED_ITEM_DESCRIPTION] – Short item description
[XML_FEED_ITEM_CONTENT] – Item content
[XML_FEED_ITEM_IMAGE] – The image of the item
[XML_FEED_ITEM_LINK] – The url/permalink to the item
[XML_FEED_ITEM_PUBDATE] – Item publish date
[XML_FEED_ITEM_GUID] – Item guid.

Since 1.5.1 you can also use indexed tags for a better control, so you can use:

<!DOCTYPE HTML>
<html>
<head>
   <meta http-equiv="content-type" content="text/html" />
   <title>XML FEEDS</title>
</head>
<body>
    [XML_FEED_BEGIN url='http://www.bata.com/news/feed/' count='5' offset='0']
        <table>
            <tr>
                <td>
                    <a href="[XML_FEED_ITEM_1_LINK]">
                        <img src="[XML_FEED_ITEM_1_IMAGE]" width="100" height="100"/>
                    </a>
                </td>
                <td>
                    <strong>[XML_FEED_ITEM_1_TITLE]</strong><br />
                    <p>[XML_FEED_ITEM_1_DESCRIPTION]</p>
                </td>
            </tr>
        </table>
    [XML_FEED_END]
</body>
</html>

All the above tags will work if the feed is valid and the content they try to replace exist in the feed.
You should test your feed campaign before sending, to make sure the tags are parsed and the content is fine because the parsing is strict, any minor error will stop parsing the tags and render them without transformation.

The post Embed XML(RSS) feeds into your campaign appeared first on MailBul KB.