Razva

BUMP?

Anybody...?

I'm not able to connect to G Suite via IMAP, only via POP, this being the reason for opening this ticket. Here's an example of one IMAP and two POP, all on the same G Suite account (I've replaced my domain.tld with X in the paste, because of privacy/spam reasons): POP Import Log Date: 26/12/2018 12:44:17 --- Host: imap.gmail.com Email: commercial@X Connection error: POP3 connection broken in response --- Host: pop.gmail.com Email: support@X Mailbox is empty --- Host: pop.gmail.com Email: wordpress@X Mailbox is empty --- Any hints?

None..nothing...nobody...?

Hey, Is there any way, or plugin, that'll allow me to use IMAP instead of POP? G Suite filters seem to not apply when using POP, but only when using IMAP. Thank you

Hey, I've setup 8 products in the same Group, and assigned the Universal Slider as desired Template. Unfortunately the single result I have is this: I guess that I need to set something at the description of the product...? Thank you!

Well ... can you please make me an offer on PM? 🙂

I'm no programmer so ... I totally agree with you, but I have no idea how to implement it.

I've replaced $pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . $duedate, 0, 1, 'L', '1'); with $pdf->Cell(0, 6, Lang::trans('invoicesdatedue') . ': ' . date('d.m.Y',strtotime('+15 days',strtotime($datecreated))), 0, 1, 'L', '1'); The "original" invoice is this: The result is this: So we can consider this as a "win" for now. I'll search for somebody to write a module, because I'm pretty sure this will get overwritten at the first update and diff-ing is a huge pain in the arse. Thank you very much for your support!

Done.

Unfortunately it doesn't applies to Romania. Here the law imposes both the Invoice Date and Due Date, because it has "contractual meaning". So...yeah... 😕

Sure I/we could, but that wouldn't really fix a behaviour that is not appropriate/legal. I think that the solution is for WHMCS to "be legal", not for its (paying) users to search workarounds and gimmicks. It's just my humble opinion. Meanwhile, you had a great idea! Can't we modify the template so it shows the Due Date as InvoiceDate+15 days? I'm not a programmer but it doesn't looks very complicated?

Hello, Right now the "VAT Addon" module behaves like this: when applying payment the "Invoice Date" is changed into the current/today date, which is ok/normal the "Due date" is NOT changed, which results in very weird invoices, as sometimes clients pay way after the Due Date Example: Proforma Invoice is issued by WHMCS in 01.11 and has 15.11 as the Due Date (everything normal until here) the client makes a late payment in 05.12, aka 20 days after the Due Date the accountant registers the payment in 06.12, this resulting in the Fiscal Invoice with 06.12 as Invoice Date BUT the Due Date remains 15.11.2018. This behaviour is illegal in the vast majority of EU countries, as you cannot issue an invoice ... after its Due Date, or on different months. Any fix for this? Thank you, Razvan

Hello, Right now the "VAT Addon" module behaves very strange: When applying payment, the "Invoice Date" is changed into the current/today date (which is OK/normal/acceptable) The "Due date" is NOT changed, which results in very weird invoices. Example: invoice is issued in 01.12.2018, but the due date is 15.11.2018 - which is illegal in Europe, as you cannot issue an invoice ... after its due date. Requested work When adding payment, the "Invoice Date" and "Due Date" should be the same OR the "Due Date" should be "Invoice Date + 30 days". I'm looking for a serious developer who can make this simple module. Thank you, Razvan

After spending a couple of hours with my programming colleagues, the general conclusion was "fsck it, let's just use Global Date Format". I'm coming from HostBill and I'm amazed of the limitations imposed by WHMCS! You cannot specify quantities for products on invoices, you cannot create products with quantities (my workaround was to create a product + configurable options, which is horrible), you have hugely limited multi-language support (even if WHMCS advertises itself as "fully multi-lingual"). Sometimes I'm so tempted to just go back to HostBill... 😐

I'm getting this when trying to use it: AppConfig for “csf,” requires that you must have one of the following acls: “software-ConfigServer-csf” to access the url: “/cgi/configserver/csf.cgi”. Any hints?

@brian! thank you very, very, much! This solved my problem.

Hello, Our WHMCS setup is set to English by default. Unfortunately our international customers are complaining that the messages we're sending are "mixed-bilingual". Here's an example: The above message was sent to a user that had Romanian set as Language, so basically the message is in "romglish". This is/looks very unprofessional. WHMCS's staff reply was this: Unfortunately I'm not so good at coding so ... can somebody please point me to the right direction? Thank you

Thank you very much for your in-depth reply! My problem with {$product.pricing.triennially} is that it will show the entire price per 3 years, not the "triennially monthly price". The end-game would be to show this instead of this Yes, I am sure that the triennially price will be the smallest one for this product category. The problem is that other (more expensive) products will not have triennially pricing. For those I should post quarterly or whatever is the biggest period. I don't have any products that are more expensive quarterly/annually/triennially compared with monthly. Long story short I need to show the monthly price for the biggest existing term, even if that is quarterly or triennially.

Hello, We, as most providers, offer the best price for Triennially payments, Monthly payments having the highest cost. Unfortunately WHMCS shows the highest price (monthly) when listing Products. Any way to fix/workaround this?

Yes, we're making VAT VIES validation via the "VAT Plugin" (hopefully it'll work). The problem is not about trust, but about the user experience. Asking unnecessary and irrelevant questions on first contact is a really bad idea. Signup forms are one of the most common "mental roadblocks" when enrolling a new client, so we need to do our best and ask only what is relevant for us and for the client. To put it simple, WHMCS doesn't has any way of differentiating Businesses from Private Persons? Because that's one of the oldest tricks in the books. Later edit: I see no way of translating the inputs done in "Select Options" for the Dropdown?

Hello, We're moving from HostBill to WHMCS and we found the first "road-bump". I cannot find any way to separate Companies from Private Persons. In EU we need to ask different information for Companies (VAT Number, Registration Number etc) compared with Private Persons (Personal ID etc). It doesn't makes any sense to ask the VAT Number from a Private Person... Is there any way to make a difference between these two categories, when signing up? Thanks, Razvan

Thanks for your reply. Unfortunately that topic states the same rewrite rules (plus some general configs) as I've stated in the initial post. What we need at this point is a complete rework of the NGINX rules that were used until recently.

Hey, Our old NGINX configuration was using this in order to rewrite URLs in a "friendly form": rewrite ^/announcements/([0-9]+)/[a-zA-Z0-9-]+.html$ /./announcements.php?id=$1 last; rewrite ^/announcements$ /./announcements.php last; rewrite ^/downloads/([0-9]+)/([^/]*)$ /./downloads.php?action=displaycat&catid=$1 last; rewrite ^/downloads$ /./downloads.php last; rewrite ^/knowledgebase/([0-9]+)/[a-zA-Z0-9-]+.html$ /./knowledgebase.php?action=displayarticle&id=$1 last; rewrite ^/knowledgebase/([0-9]+)/([^/]*)$ /./knowledgebase.php?action=displaycat&catid=$1 last; rewrite ^/knowledgebase$ /./knowledgebase.php last; and/or location ~ /account/announcements/?(.*)$ { rewrite ^/(.*)$ /account/index.php?rp=/announcements/$1; } location ~ /account/downloads/?(.*)$ { rewrite ^/(.*)$ /account/index.php?rp=/downloads/$1; } location ~ /account/knowledgebase/?(.*)$ { rewrite ^/(.*)$ /account/index.php?rp=/knowledgebase/$1; } Unfortunately these rules don't seem to be generally valid any more. For example "Setup -> Sign-In Integrations" is not working. I've noticed that current/modern 7.6+ installs have a totally different .htaccess structure, as follows: RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} -d RewriteRule ^(.+[^/])$ $1/ [R] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond $0#%{REQUEST_URI} ([^#]*)#(.*)\1$ RewriteRule ^.*$ %2index.php [QSA,L] Can anybody provide some newer NGINX rules, based on the above 7.6+ rewrites? Thanks you!

Hello, I'm looking for a module that can generate invoice numbers based on the Payment Gateway and/or Client Examples: invoices paid through PayPal should be numbered PP-1, invoices paid through bank transfer should be numbered BT-1 etc. Invoice numbers must be totally separated, meaning that BT- and PP- should be totally independent; invoices paid by client John should be numbered with JH-1, invoices paid by client Murphy should be numbered with MU-1. Invoice numbers must be totally separated, meaning that JH- and MU- should be totally independent. In this case the default numbering and Payment Gateway numbering (^^^) must be overwritten. Requirements: options need to be administrated via UI, not via textfile/text-config; module should be totally independent; module should not require any kind of WHMCS files modifications or manual intervention to the core files; module should use own/specific SQL tables (so I can remove them in case the module is not needed any more) and not "mess-up" with WHMCS more than necessary (I had very bad experiences with modules that modify a load of stuff and basically break WHMCS when disabled). It's not something that needs to be done "until tomorrow" but I also don't want to postpone it more than 1-2 weeks. Thanks, Razva