Kian

Alternatively edit your configuration.php file and add the following: date_default_timezone_set('Europe/Rome'); Don't forget to change timezone accordingly.

Look for uid in PHP session array. It sores the ID of the currently logged customer.

In case it's bugged open tblconfiguration table and look for your module system name in value column for the following settings: AddonModulesHooks (comma separated list like this: module_one,module_two,another_module) ActiveAddonModules (still comma separated list) AddonModulesPerms (json array)

There's no clean way to prevent email sending. If Domain Synch was an Email Template, we could have stop it via EmailPreSend. Sadly WHMCS sends it by directly requiring (or initializing) phpMailer file (or class). The only solution is an hack. Edit phpMailer loader file so that it throws a die(); when it is included or initialized by crons/domainsync.php. It works but it is ugly and your change will be reverted back on every update of WHMCS. A more sensical approach is to use a filter on your email so that the all incoming emails with "WHMCS Domain Synchronisation Cron Report" title automatically go in "Automatic email" folder. If like me you recieve a lot of such useless emails (I have access to hundreds of WHMCS systems that flood me with thousands cron/sync emails on a daily basis) also enable automatic cancellation after X days.

I didn't build PEPPOL integration but the integration with electronic invoicing. I know both share similarities but they're two separate things. I gave electronic invoicing enough time already. I no longer focus on complex projects like this one that very few people will use. Not even for a million dollar 😁 Btw electronic invoicing & BX is active and maintained. It's just that I no longer provide free support because it is not worth it. Complex stuff + many customers + one guy = 🤯 I know it sucks but I wanna have a life.

Same hope here 🤞

@Dugger88 Have you tried to "triangulate" information to confirm they truly did this to you? All you need is: Determining as precisely as possible when your database disappeared Look for their IP log in for the timestamp in question (if they used Tor it's game over) Moreover it looks they had access to your phpMyAdmin. If you are lucky enough, you could try the following. Click the small "Console" button at the very bottom of the page. phpMyAdmin offers a brief history of SQL statements but some people configure it to store hundreds if not thousands of queries. You should look for DROP statements. If you find some, it means your db has been deleted directly from phpMyAdmin and not from a backdoor. Next you could try checking if they uploaded a backdoor (a .php file) to your system to mess up with you. Lazy people usually bury such file deep within your root directory. Scan your access log and look any access to .php files that are not the official ones of WHMCS or that are placed in strange places. In case they included the backdoor in a module they sold you, still in access log look for direct access to any .php these files (eg. if their module is in modules/addons/hello look here). Don't forget that if you are quick enough you can still recover your database. As far as I know mysql keeps all data for a certain time. It simply "forgets" tables but they're still on the HD. Also make sure they can no longer access your server before investigating otherwise they could remove proofs if they happen to see this post. Important: I am not saying they are responsible for what happened to you. I am simply trying to help.

Ciao, che io sappia solo due clienti la utilizzano ma non so dirti di più ma non so se poi sono passati alle vie più tradizionali. Personalmente ti sconsiglio di utilizzare questa modalità per i motivi che vado a descrivere. Prima di tutto non è una soluzione "pronti e via". Il modulo si limita a metterti nella condizione di produrre XML firmati digitalmente con il tuo servizio di firma digitale remota. Tutto il resto del flusso è da integrare a carico tuo. Di fatto si tratta di diventare a tutti gli effetti un intermediario. Hai presente servizi come Aruba piuttosto che FattureInCloud? Parliamo di diventare (passami il termine) l'Aruba di te stesso. In seconda analisi per poter utilizzare questa soluzione devi farti abilitare un canale di trasmissione diretto con SdI rispettando le stringenti policy di utilizzo. Ad esempio puoi inviare solo X fatture elettroniche alla volta, ogni feed non può eccedere gli Y megabyte di dimensione complessiva. Poi ci sono una serie di altri concetti che cambiano nel corso del tempo. Ad esempio c'erano dei giorni in particolare nei quali SdI invitava a limitare gli invii perché i benzinai trasmettono X volte al mese in determinati giorni. Non so se è ancora valido ma ci sono davvero un sacco di cose da tenere in considerazione. Infine dovresti anche provvedere tu stesso alla conservazione sostituitiva per 10 anni. Non succede niente ma se succede qualcosa (es. il tuo server si rompe ed anche il backup) non so a che santo potrai appellarti. In conclusione ribadisco il mio consiglio di lasciar stare. Dipendentemente dal numero di fatture che generi ogni anno, usa Aruba (economico e facilissimo) oppure Digiting.

È stata appena rilasciata la 2.2.175 che includerebbe l'integrazione con Aruba tuttavia è stata messa "in sospeso" per la seguente ragione che è stata pubblicata nel changelog (qui chi preferisce la versione inglese). Riporto il tutto di seguito. ---------------------------------------------------------------------- Abbiamo completato l'integrazione con la "Fatturazione elettronica" di Aruba ma non perdere tempo a cercarla nel modulo poiché siamo stati costretti a mettere la funzionalità in "pausa". Cominciamo dall'inizio. Abbiamo integrato con successo Billing Extension con Aruba. Come puoi immaginare l'integrazione si poggia sulle API. Poche settimane fa abbiamo scoperto che Aruba vincola l'utilizzo delle loro API agli utenti Premium il che significa una delle due cose: TU devi pagare 600 € / anno più 300 € di spese di setup (IVA esclusa) OPPURE... NOI dobbiamo diventare reseller di Aruba sostenendo le stesse spese più 15 € per ciascuno dei nostri clienti. Per poter rientrare nei costi chiaramente dovremmo addebitarvi un costo maggiore In tutta onestà non sappiamo come proseguire visto che non abbiamo idea di quanti di voi utilizzino Aruba per la trasmissione delle fatture elettroniche. Fatecelo sapere in questa discussione in modo da metterci nelle condizioni di prendere la decisione opportuna.

It's even worse. Just look at this post of mine. I had to take a screenshot of my entire post. The server no longer allows to post: Basically any code Write words that happen to be PHP global variables Paths and URLs used when making examples What's the point of having this f*o*r*u*m if people can't post? Too many times I spent like 10 minutes to offer my help just to be faced with 403. It tilts me so much that I no longer post. Oh and btw I can't even write f*o*r*u*m since it gets replaced by "community". I guess integrating NordVPN is the number one priority.

I have been forced to take screenshots of my post because this f*o*r*u*m* thinks that PHP variables and URLs are hacks. Click to zoom and report WHMCS to Police 😑 A f*o*r*u*m* can't be so stupidly restrictive (yes, we can't even type f*o*r*u*m) 😡

You have to open tblconfiguration table. In this table you find SMTPPassword in setting column. The password is stored in value column (encrypted).

It's stored in tblconfiguration.value (setting name is SMTPPassword). Be advised the pssword is encrypted. You'll have to use Decrypt() function to use it in phpMailer.

The thing is WHMCS uses System Settings > General > Logo URL in three different places: Website PDF files (quotes and invoices) Email notifications You can easily tune dimensions in website with CSS, by simply editing header.tpl pointing to a different URL or simply let responsiveness do its job. Same for PDF files with FPDF syntax. Now when it comes to Email Templates, WHMCS prepends this same logo in all emails "as is" (original dimensions). If your logo happen to be 1920x1980 px, no resize occurs. It will show at full size which is the problem you are experiencing. You have two options: Change your System Settings > General > Logo URL so that it points to a logo of decent sizes (not to the "full HD" version). Once done make sure your logo still shows correctly on website and PDF files. If something isn't quite right simply play with CSS/FPDF or define dedicated URLs just for the website and/or PDF Override {$logo} Smarty variable via EmailPreSend hook point with a smaller version. This way WHMCS initially plans to use the 1920x1980 px versions but before it sends the email you override it with another logo/URL with correct dimensions (eg. 250x80 px)

System Settings > General > Logo URL Keep in mind this could also affect logo displayed in PDF invoices & quotes and website. It depends on how you customized them.