Leaderboard

Hi @Jade D, I have responded to your ticket, but just wanted to follow up here so there's an answer if anybody else comes across this. The underlying issue here is that your web server was advertising a domain other than that registered for your license. This causes the license cache in your install to be invalid, and so your install needs to check in with our licensing infrastructure to validate your license. Since the details we held about your license were different to those being advertised by your web server, your install kept making a request to our licensing API. We rate limit all requests made to our licensing infrastructure to ensure stability thereof for all our customers. If your server sends too many requests, it will be temporarily blacklisted as part of this rate limit. To resolve this, make sure that your web server is only advertising the server_name that we have listed in your Valid Domains. Wait for 30 minutes or so and the rate limit will be removed, then your install will get a response back from the licensing servers that your license is valid and access will be restored. If anybody is unable to get to the bottom of this, please reach out to our support team and we can help!

You aren't authenticated in your hooks. The hooks aren't running as you - they're running as the system. WHMCS doesn't offer a native way of logging in as an admin in a hook. If you just want to download the invoice, you can include /includes/invoicefunctions.php and run the pdfInvoice($invoiceId) function.

Hello @HarryAdney You can try from System Setting -> General Setting -> 1st Tab (General) -> Update "Records to Display per Page". You can update 200 records per page

Look for something common, like a .ru domain, and block that at the TLD level (unless you have customers using those). Trying to block all spammers by individual email addresses is a game you won't ever win. More effectively, you can disallow tickets by non logged-in users. Public facing things like this are abused all the time, and recaptcha only helps a little.

After A/B testing with a different payment solution I can tell you that it is absolutely a WHMCS issue. Long story short: we moved card payments to a different billing system. Even with the added cost is still saves us money.

I’ve had a similar issue before, and it turned out to be a syncing problem between WHMCS and Stripe. It seemed like WHMCS didn’t update its records properly after processing a payment, but Stripe ended up charging clients twice. In my case, it was due to a misconfigured webhook or an automated retry that triggered the second charge. It’s definitely worth checking your payment gateway settings and logs, and if it keeps happening, you might want to contact WHMCS and Stripe support to get to the bottom of it.

New to community, but old to whmcs. Nice to meet you all!

I actually used to help with the billing of this online site and figured that was what was up. Thanks for the info!

Hi everyone, We are excited to introduce Caasify, a free WHMCS module that allows you to easily sell VPS from Hetzner, Vultr, and DigitalOcean directly through your WHMCS client area. Download the module for free from GitHub Video Demo Installation Guide The platform is totally free for web hosting companies. The installation process takes only 5 minutes. If you need further information, please do not hesitate to contact us through the website ticket. Best regards,

Here's the fix! https://whmcs.community/files/file/204-gocardless-eur-payments/

this was fixed by executing this line to add the missing dir in phpmyadmin ALTER TABLE `tblhostingaddons` ADD `subscriptionid` VARCHAR(128) COLLATE utf8_unicode_ci NOT NULL DEFAULT '' AFTER `notes`;

Thanks for sharing the valuable info. It was required to disable the on cPanel / Plesk servers.

Why does your WHMCS installation need to be on the same server you develop your Windows applications on? For us, and I'd personally recommend this, it's on a server totally segregated from hosted sites and clients. Safer, and available if the hosting server(s) fall over.

Lagom WHMCS Client Theme has been updated to 2.0 version! Order Now Changelog Documentation Services Contact Different Styles & Colors Lagom WHMCS Client Area Theme consists of 4 unique styles. There are 5 different color schemes available for each style. Modern Futuristic Default Depth Style Manager Provides essential tools used to manage Lagom theme colors and styles without having any technical know-how. You will be empowered to apply various Styles and Color Schemes to tailor our theme to your brand style. Learn More Menu Manager From now on, you do not need to create complicated WHMCS hooks to modify the Lagom theme navigation. Menu Manager delivers a super convenient option to set up the menu items from the WHMCS addon. Learn More Multiple Layouts Make full use of 5 unique layouts for the main menu navigation and 2 various layouts for the footer. Other Lagom Features Login Based Layouts Display different menu and footer layouts based on the customer's login status. Learn More Basic SEO Management Manage SEO for selected theme pages. Assign your custom page title, description, and social image. Learn More Custom Layout for Pages Assign a unique Lagom Layout to specific pages and overwrite settings made in Layout Manager. Learn More Affix Theme Navigation Affix the top Lagom theme navigation when a customer scrolls your website up. Learn More Multiple Element Styles Using a few simple clicks you can choose from 3 different styles available for particular Lagom elements. Learn More Multiple Page Templates Define various templates for selected Lagom theme pages and configure its settings. Learn More Different Fonts Change Font Family used in the Lagom theme with a few simple clicks. Learn More Affix Theme Sidebars Affix theme sidebars to the top of the browser window. Learn More Hide Sidebars Hide Lagom theme sidebars for selected pages in Page Manager. Learn More

WHMCS users and client accounts have separate contact information and they require separate updates to change details like the email addresses. The user management system allows a single user to access multiple client accounts. This separates authentication and authorization from services, billing, and support. To learn how to change the client account and the user account email address so they match please review this help guide: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details With this hook added to your WHMCS installation the system will now "Sync" the Client Account Email Address to match the User Account Email Address only when the change is made under the Account Details page via the client area. This hook adds a little "Note" under the Email Address field under the Hello Client! > Account Details section of the client area to inform that when this Email Address is changed, they will be logged out and they will need to log back in using the new Email Address they just set since this hook is updating both the client account and user account email addresses. Here is an example of the Account Details page Email Address field with this note: Via the Admin Area, when a client does this change and the hook was used it will make a log entry just like this: This entry indicates that the Client/User Email Sync Script hook was a success. Now both the Client Account Email Address and the User Account Email Address match for that client account. If there are multiple Users associated with the Client Account, this will only change the Email Address of the Owner of the account. <?php /* This script will update both the Client Account Profile email address and the user account email address when the change is made to the Account Details page for the email address field. Otherwise, you would have to update the email in both places and follow this article: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details Upload this file to your /includes/hooks directory of your WHMCS installation. There will be a Log entry when this script runs. @WHMCSDanny */ add_hook('ClientAreaHeadOutput', 1, function($vars) { // Only run if the on the Account Details page via the client area. // The action is going to be "details". This will make sure this message does not show anywhere else. $action = $_GET['action']; if($action == "details") { //Input the message under the Email Address field that they will be logged out after making the change. return <<<HTML <script type="text/javascript"> $(document).ready(function() { jQuery("input[name='email']").after('<span style="color:red; font-size:9pt;"><b>Note:</b> Changing your email address here will sync the email with your User Account. You will be logged out after you change the email. You must login using the new email address you just set.</span>'); }); </script> HTML; }; }); // prevent file from being loaded directly if (!defined("WHMCS")) { die("This file cannot be accessed directly."); } else { function clientowneruseremailsync_changeUserEmail(int $client_id, string $client_email){ // call the API and grab the owner user ID $command = 'GetClientsDetails'; $postData = array( 'clientid' => $client_id, 'stats' => false, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { // success! $client_owner_user_id = $results['client']['owner_user_id']; if (is_numeric($client_owner_user_id)){ // got a number, so it should be a valid owner user ID // now to perform the update to the user account to match the email set for the client account $command = 'UpdateUser'; $postData = array( 'user_id' => $client_owner_user_id, 'email' => $client_email, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { logActivity("Client/User Email Sync Script - Emails Successfully Changed and Synced. The e-mail address is set to $client_email for the Client Account and the Owners User ID: $client_owner_user_id", $client_id); } else { logActivity("Client/User Email Sync Script - Failed to change the e-mail address to $client_email for the Owners User ID: $client_owner_user_id . Results: ". $results, $client_id); } } } else { logActivity("Client/User Email Sync Script - Failed to verify that an e-mail change occurred on the clients profile. Results: ". $results, $client_id); } } add_hook('ClientEdit', 1, function($vars) { // Only run if the clients account profile email address is being changed. if ($vars['email'] != $vars['olddata']['email']){ // email is being changed. Update owning user accordingly. // get the client ID. It should be $vars['userid'] $client_id = $vars['userid']; // get the new e-mail address $client_email = $vars['email']; // call our helper function clientowneruseremailsync_changeUserEmail($client_id, $client_email); } }); } ?> Enhanced Version - Added a checkbox and tooltip In this new updated version of this hook, I added a checkbox/tooltip for the end-users to decide if they want to use this option to sync the Email Address under the Profile page too. Otherwise, nothing happens and WHMCS works as normal. The checkbox needs to be checked before it will run the same hook code to update both email addresses in both locations. (Account Details and Profile sections via the client area) <?php /* This hook script will update both the Client Account Profile email address and the User Account email address When the change is made to the Account Details page for the email address field only. It does not work for the Profile page. This version adds a new checkbox with a tooltip to let the end-user decide if they want to use this option or not. The checkbox needs to be checked for the hook to execute. If the checkbox does not get checked WHMCS works as expected and updates just the Account email. The Profile email account will still need to be updated if they want it to be the same. Otherwise, you would have to update the email in both places and follow this article: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details Upload this file to your /includes/hooks directory of your WHMCS installation. There will be a Log entry in the admin area when this script executes. @WHMCSDanny */ add_hook('ClientAreaHeadOutput', 1, function($vars) { // Only run if the on the Account Details page via the client area. // The page action is "details". This will make sure this message does not show anywhere else. $action = $_GET['action']; if($action == "details") { //Input the checkbox and tooltip under the Email Address field return <<<HTML <script type="text/javascript"> $(document).ready(function() { jQuery("input[name='email']").after('<input type="checkbox" name="syncEmails" id="syncEmails"> <span style="color:red; font-size:9pt;"><b>Sync Email with your User Account Email</b></span><span class="form-group"> &nbsp; <i class="far fa-question-circle" data-toggle="tooltip" data-placement="top" title="This option will sync your Email Address Here with your Profile Email Address. You will be logged out and will need to login with your new email address. If you do not check this option you will need to update it under the Your Profile page as well"></i></span>'); }); </script> HTML; }; }); // Prevent file from being loaded directly if (!defined("WHMCS")) { die("This file cannot be accessed directly."); } else { if (isset($_POST['syncEmails'])) { // Checkbox is checked // Perform actions and the logic to check the emails and replace them with the new one function clientowneruseremailsync_changeUserEmail(int $client_id, string $client_email){ // call the API and grab the owner user ID $command = 'GetClientsDetails'; $postData = array( 'clientid' => $client_id, 'stats' => false, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { // Success we have the owners user ID from the database! $client_owner_user_id = $results['client']['owner_user_id']; if (is_numeric($client_owner_user_id)){ // We have the ID number, so it should be a valid owner user ID // Perform the update to the user account to match the email set for the client account $command = 'UpdateUser'; $postData = array( 'user_id' => $client_owner_user_id, 'email' => $client_email, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { logActivity("Client/User Email Sync Script - Emails Successfully Changed and Synced. The e-mail address is set to $client_email for the Client Account and the Owners User ID: $client_owner_user_id", $client_id); } else { logActivity("Client/User Email Sync Script - Failed to change the e-mail address to $client_email for the Owners User ID: $client_owner_user_id . Results: ". $results, $client_id); } } } else { logActivity("Client/User Email Sync Script - Failed to verify that an e-mail change occurred on the clients profile. Results: ". $results, $client_id); } } add_hook('ClientEdit', 1, function($vars) { // Only run if the clients account detaoils email address field is being changed. if ($vars['email'] != $vars['olddata']['email']){ // Wmail is being changed. // Get the client ID. It should be $vars['userid'] $client_id = $vars['userid']; // Get the new e-mail address $client_email = $vars['email']; // Call the helper function to make the change clientowneruseremailsync_changeUserEmail($client_id, $client_email); } }); } } ?> At the time of writing this post, this process was tested on the latest stable release of WHMCS 8.9.0 I hope you find this useful. If you have any feedback or questions, please feel free to reply to this thread! WHMCSDanny

Is this available anywhere? if you can point me to where i can find this, it would be appreciated

For many businesses, there will be keywords that you do not want customers to be able to use. For example, you might want to prevent them from being able to create services under any of your domain names, or prevent the use of strings like "admin" or "root" in the "First Name" and "Last Name" fields. By making use of action hooks, it is totally possible to add this functionality. In this post, I'll show you how to get this setup, and how you can add your own rules. Overview To make this work, we're going to be making use of Action Hooks - specifically, the ShoppingCartValidateCheckout hook. If you've never used hooks before, I'd recommend reading our Getting Started guide, which will help you to understand the basics of what we'll be doing here. Step 1: Set up your hook file To begin, open your WHMCS instance's filesystem, and navigate to /path/to/whmcs/includes/hooks and create a new file keyword_filter.php. Now open the file, and paste in the following: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { // Content goes here }); This will tell WHMCS that we are using the ShoppingCartValidateCheckout hook, and will allow us to retrieve the variables provided to us. As this article goes on, we'll be adding to this base layer until we have our finished, fully-functional script. Step 2: Define your keyword filters There are many different ways that we could define what strings are banned in which fields. For maximum legibility and modularity, I've decided to use a map. This will allow us to associate one set of data (the "key"), in this case the field name(s) to apply the filter to, and another (the "value"), which in our case is a list of banned keywords. Here's the code: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed ]; }); Each set of 'fields' and 'keywords' is a mapping. You can add as many of these as you need. We'll be returning an error based on whether or not the field contains these keywords (i.e. if they are substrings). For example, if the user enters "admin123" for their firstname and "john.smith@google.com" for their e-mail, both of these filters will apply because the substrings "admin" and "@google.com" are present within the 'firstname' and 'email' fields respectively. You can find a full list of available fields in the documentation for this hook. Step 3: Implement logic to check field submissions for any banned substrings Now that we've defined our 'filters', we need to implement the logic that's going to make them work. Here's the full script, explained in the provided comments: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) ) { // If there is a match, add it to the list $errors[] = "'$fieldName' cannot contain '$keyword'. Please remove this and try again."; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Here's a little summary of how it works: Iterate through all of your mappings ('filters') Check all fields for each filter If the field value is blank, skip all checks for that field - we need to do this since this field is only included for new users If the field value is not blank, carry on to checks Check if any keywords are a substring of the field value If they are, add that infraction to an array of errors to be returned If not, do nothing If there are any errors, return them. If all checks are passed and no keywords are present, return true. The only part of this code that you should need to modify is the top section, where you define your filters. If any of the filters are matched, here's what'll be displayed in WHMCS: Step 4: Prettify error messages (optional, but recommended) As it stands, our hook is completely functional. If any banned words are present, an error will be returned. However, our script looks like a customisation, and you'll probably want to make it appear like native functionality. The issues are: We're currently using the $fieldName, which doesn't read like English Language used doesn't fit in with the rest of WHMCS's error messages To second issue is fixed by adjusting the error message, so that's easy! To fix the first problem, we'll use another map to correlate each $fieldName with its "English equivalent" (which I've just called $friendlyFieldName: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Map field names that you're using above to their "English equivalent". $friendlyFieldNames = [ 'firstname' => 'First Name', 'lastname' => 'Last Name', 'email' => 'Email Address', // Add more field name translations as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) { // Translate the field name to a nicer name for the error message. $friendlyFieldName = $friendlyFieldName[$fieldName] ?? $fieldName; // Add it to the list $errors[] = "$friendlyFieldName cannot contain '$keyword'"; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Simply add a new mapping for each $fieldName that you use in the $friendlyFieldNames array, and they'll read well and feel like a native part of WHMCS: And there we have it: a hook script that can be easily extended to include as many fields and keywords as you require, and it feels totally native too! Customising/extending this script Feel free to customise this script to you heart's content, whether you want to change how it behaves or extend its functionality. However, please keep in mind that our Technical Support team won't be able to help you troubleshoot any problems that you may encounter should you make any changes. Use at your own risk. Suggestions for other "Tips & Tricks' articles If you'd like to see an example of how we can customise WHMCS in other ways, please do give us your suggestions!

delete the line item from the invoice cancel the invoice delete the cancelled invoice change the due-date back 1 day on the product change the due -date to it's original date on the product change the billingperiod and tick the recalc on save on the product and save on the client summary page click generate due invoices (or wait for the cron if doing multiple)

Thanks for all the help and replies on this. Really loving this community. So engaging and helpful... I resolved it myself. The issue was a set of extraneous rules related to a separate issue in our Apache conf regarding Access-Control-Allow-Origin and setting X-Frame-Options to "sameorigin".

I personally think post count is enough of a "ranking" system. As for people that are employed, by WHMCS, well.. they just need something to indicate that (as they already do). I give little attention to a rank under a persons name. I give plenty of attention to their meaningful posts. To be blunt, "we" (whoever you may choose to put into that group) help WHMCS a lot more than I think they realize. Reward "us" with better support, or tangible things other than a fancy tagline and you might just be on to something when it comes to encouraging contributions. PS If you want to learn about how to engage people, you'll find much material on the subject online, including plenty of contradictions. I have quite a lot of experience managing a community many times larger than this, but it's a Open Source community.. and the reasons people are there are vastly different from the reasons they are here.

it's only taken you a couple of years to get to this stage of changing the ranks... it's one hell of a long journey if it's only just beginning now. or perhaps a more constructive approach would have been to discuss it first before implementing it?? 🙄 if I believe users think ranks are unimportant, then why should I give you suggestions for alternatives when they don't matter ??? I even lost my sarcastic "Legendary Member" tag for 90 days ROFL. 🤣 you want a suggestion Chris - to a user, is my rank, "Senior/Legendary Member" or "Honorary Contributor" ?? Is Kian a "Senior Member" or a "GearHead" ?? a casual user is not going to know which is the rank - nor will they care. i'd argue an Advisor should outrank a Contributor, but as I said, they're all meaningless... I told you years ago that you don't need to have both visible, there's an argument you don't need either. excellent - as a matter of regular routine, I have a screenshot of the entire original thread - I find that it's always good to keep a complete unadulterated record of these things for later use - consequences of actions can, and will, work in both directions. #KTTK 😉 absolutely correct - ideally, you engage with them before making decisions.... if ranks matter, they will speak up - if they don't, then that proves my point. as a demonstration of that Chris, when you start other community suggestion threads - how much response do they get?? exactly! nobody is interested - there's YOUR community Chris. users come here for one of two reasons - either they have a technical problem and they want an answer, or they're a developer and only interested in checking for new threads in SO&R, or posting about their latest addon... neither group are going to be interested in the minutiae of these forums, e.g ranks, tags etc. you might want to check mine too - i've gone from 6% to 95% used.

FWIW, i'm not keen on the use of "Advisors" as one of the ranks - surely, the definition of an advisor is someone who is qualified to give advice??? users making a lot of posts ASKING questions, or replying to their own threads doesn't necessarily mean that they should be giving technical advice (which calling them advisors implies) - for some users, yes that's fine... but I would have thought not for the majority of users with Advisor type ranks... therefore, using the word "Advisor" in the ranks is potentially confusing... I appreciate that you like change for changes sake, and wanted to get away from the generic use of "Members" for everyone, but using advisor just seems silly to me. and don't get me started on "Collectors" - what are they collecting ??? 🙄 btw - why the use of US English in the titles, e.g "Honored Contributor" ?? that looks plain wrong to me. in the meantime, i've taken the liberty of blocking these rank titles in the browser with uBlock, so i'll never have to see them again. 😎 P.S - the search function is seemingly broken, e.g if I search for knowledgebase, it's returning 7 results! if I search my local backup of threads, I can find 96 posts with knowledgebase just in the title - that's not including posts where it might be mentioned in the body.

Yes, you have to edit the admin template "viewticket.tpl". I hacked this code myself: {if !$numcustomfields} <div align="center">{$_ADMINLANG.support.nocustomfields}</div> {else} <table width="100%" border="0" cellspacing="1" cellpadding="5" bgcolor="#cccccc"> {foreach from=$customfields item=customfield} <tr bgcolor="{cycle values="#F4F4F4,#F8F8F8"}"><td width="200">{$customfield.name}</td><td><strong>{$customfield.value}</strong></td></tr> {/foreach} </table> {/if} There's probably a more elegant solution but that works.

I am happy to say that the development cycle of vBLink 2.0 is now complete. The release was delayed for a complete ground-up rewrite after WHMCS 4 was announced. It is not ready for download just yet; I have not taken the time to create an installer or documentation because of two major issues that may become a factor in the long term success of vBLink. The first issue is vBulletin 4 support is not included. This is in part because of the fact that I do not agree with decision by vBulletin to change the licensing structure essentially us to purchase new licenses. I own three licenses, two for production sites, one for a development site. The cost to upgrade is going to be huge, especially if I choose the publishing suite. So at this point I have no access to vB4 code. The second issue is that from a business standpoint vBLink has not been a success, or at least the free/paid model that it has been distributed with. In the past year there have been over 400 downloads of vBLink but less than 2% were paid licenses making vB4 support hardly justifiable. So the question now is what to do next, and that is the reason that I am posting this message. Obviously, vBLink without vB4 support is only going to be useful for a short time until v4 goes gold. But without a solid community and financial backing behind it, I have no reason to continue development. But one promise I will make is that if I do walk away from vBLink, I will release all source code into the public domain; I do not believe in holding code hostage. If I do in fact release vBLink 2.0, I'm thinking of a 3-tier release structure... vBLink Basic (Free, Fully Encoded with only account bridging and no extras) vBLink Pro (Mid-range cost, a few admin module source files encoded, fully functional) vBLink Pro Dev (Highest cost, fully functional with full source) All feedback is welcome and will help determine the future of this vBulletin integration.