Jump to content

ditto

Retired Forum Member
  • Posts

    192
  • Joined

  • Last visited

Everything posted by ditto

  1. Never mind. On my development install I actually had previously set "Six" to be active template, and then forgot about it. So there is no bug, I simply made a mistake.
  2. The problem was not with the new libraries. I solved the problem by deleting the "Six" template, then my custom portal/invoicepdf.tpl works correct again! So there is a bug in WHMCS 7.6.2, when you are using "portal" theme, it does not use portal/invoicepdf.tpl but instead WHMCS use the .tpl from "six".
  3. After I updated from WHMCS 7.6.1 to 7.6.2 my customised PDF invoice lost all of the custom edits I have in portal/invoicepdf.tpl (yes, I still use the old portal theme). I see in the release notest https://docs.whmcs.com/Version_7.6.2_Release_Notes that this related library is updated: "tecnickcom/tcpdf: 6.2.17 to 6.2.26" However under "Security" this is listed: "CORE-12853 - Update TCPDF to 6.2.22" So I don't think it is a good idea to rollback the library update to temporary fix my problem. Does anyone have any information about how I am suppused write my edits in portal/invoicepdf.tpl in WHMCS 7.6.2 so that they work the same way as in WHMCS 7.6.1?
  4. Another user at webhostingtalk posted about that happening to him: http://www.webhostingtalk.com/showthread.php?t=1716462
  5. I am preparing to manually upgrade WHMCS from 7.2.3 to 7.5.1. Looking at the new files in 7.5.1 I find a new file named package-lock.json directly in public_html. What is that file for? Is it added there by a mistake? Can I delete it?
  6. Now that WHMCS 7.3 is released without support for PHP 7.1.x, when can we expect a new version that support PHP 7.1.x?
  7. Yes. I am also very disapointed with them not working more on this. There is mininal code changes needed between PHP 7.0.x and 7.1.x - all they need to do is to give us a download encoded with ioncube 10, but they will not for a long time (until the next major version), it seems.
  8. Have you used Ioncube Encoder version 10.0.x when encoding the files? If not they will not work on PHP 7.1.x I am not able to test on PHP 7.1.x, because I can't upgrade my server to PHP 7.1.x until you release a version that is compatible with PHP 7.1.x
  9. PHP 7.1.x was released December 2016, and now Ioncube has released Encoder version 10.0.x and ioncube loaders 10.0.x which both support PHP 7.1.x Question: Will WHMCS 7.3 support PHP 7.1.x? If not, how long do we need to wait for WHMCS adding support for PHP 7.1.x?
  10. Also in 7.1, the "To-Do List" widget sorts all the oldest (oldest due date) "Postponed" messages on the top, wich make the widget useless for me who have a lot of postponed messages every day. Also it is a pain that clearing the browser cache is resetting the settings for widgets. There is not many settings left, however it is still posibble to minimize widgets, but there is no point of doing that if the setting is only remembered in a cookie. After upgrading to newest WHMCS, I find my self only working in the top horisontal menu, and never look below that line when I am on the front page. I hate all of the current widgets. They have absolute no value for me in the current implementation.
  11. It is WHMCS. After deleting the file, it comes back when viewing a support ticket i WHMCS 6.3.x. It seems to be releated to the visual editor in tickets.
  12. Today I discovered a new folder in templates_c named HTML, in that folder there was a .ser file. Is this related to a hacking attempt, or is the .ser file official placed there by my WHMCS install? I am running WHMCS 6.3.2. Here is the path and file name on it: templates_c/HTML/4.7.0,d184cd487e25d86ffbb6336a1ef1ed6b888cbfe0,1.ser I am confused because I thougt .ser file was related to java? Is this something to worry about?
  13. I find this concerning to, I also find it concerning that there is no official reply to this post. Also, WHMCS has still not listened to their customers in this thread: https://forums.whmcs.com/showthread.php?119614-How-to-disabled-Automatic-Updater
  14. Regarding the five minute cron job. Is it a requirement for whmcs 7, or will I be able to run the cron job only once every day instead of every five minutes? I feel really bad about whmcs 7 because of not being able to disable auto upgrader completely, and also this talk about running a cron job every five minutes. I feel sick in my stomach. Hope they will change these things.
  15. I am currently running WHMCS 6.3.1 on PHP 5.6.27 with newest ioncube loaders 6.0.5 However I really would like to upgrade to PHP 7, but I don't want to upgrade WHMCS to 7 before there is a option to disable automatic updater https://forums.whmcs.com/showthread.php?119614-How-to-disabled-Automatic-Updater When I study WHMCS 6.3.x changelog http://docs.whmcs.com/Version_6.3.0_Release_Notes , I found this: "FEATURE-1247 - Compatibility Updates for PHP 7": So, it seems it might be worth testing if WHMCS 6.3.1 will run on PHP 7. Have anyone tested it? As noted I already run the latest ioncube loaders 6.0.5, and they work fine on PHP 5.6 and WHMCS 6.3.1
  16. I don't want and don't need the autoupdater, and I need to be able to completely disable the autoupdater before upgrading to v7.
  17. @Scolpy, yes, finally! I am now running WHMCS on a server with PHP 5.6.3, it works without any problems. So it is solved now, but not thanks to WHMCS, they did nothing to support newer versions of PHP.
  18. I totally agree with user eremini. It is really annoying not to be able to upgrade php only because whmcs don't have taken this serious enough and is lagging so far behind in that regard.
  19. Where did WHMCS announce they are beginning to prepare for php 5.5? I have not seen any such announcement. However I am waiting, being more frustrated for every day without any support for php 5.5. We have upgraded all our productions servers to php 5.5 a long time ago, except for the server running WHMCS. And now php 5.6 will be stable at the end of the summer. This is getting old.
  20. We just add the enom mail ip 69.64.153.133 to our spf records, and have not had any trouble yet.
  21. You have closed this thread http://forum.whmcs.com/showthread.php?88354-eNom-bug-wrong-contact-info - therefore I post this new thread. For description of the bug see the above link. Why is case 4291 still not fixed in WHMCS 5.3.7? http://docs.whmcs.com/Changelog:WHMCS_V5.3#Version_5.3.7
  22. I have checked the box in WHMCS that says this: Use Clients Details Tick this box to use clients details for the Billing/Admin/Tech contacts However after upgrade to WHMCS 5.3.6, when I register a new domain using the eNom registrar module, only the "Registrant" contact information is set to the clients contact information, but both "Admin" and "Tech" is set to my own contact information. I think this only happens when there is langauge special characters in the clients contact information. Because when there is language special characters, like æ, ø or å in clients contact information, it is changed (like it should) to character "a" or "o" in the "Registrant" contact information. However when I "Modify Contact Information" to change "Admin" and "Tech" back to the client own contact information, these language special characters is not changed to "a" and "o", but is used like they are, and eNom don't support those characters. Anyway, the bug is in WHMCS 5.3.6 when using the eNom module to register a domain for a client that have æ, ø or å in the contact information, what happens then is that only "Registrant" contact information is set to the clients own contact information, but but "Admin" and "Tech" contact information is set to my own contact information. Before I upgraded it worked fine and all "Registrant", "Admin" and "Tech" was set to the clients own contact information, after upgrade, only "Registrant" is set to client, the rest is set to my own contact information. Please fix this ASAP.
  23. The default on most server setup is to not dispaly errors like this.
  24. No, WHMCS does not have to rewrite anything for it to work on PHP 5.5.x. Deprecated is not the same as removed. The MySQL extension will continue to work as before in PHP 5.5.x. You can set your error reporting in PHP the way you want, so that is not a problem. The MySQL extension will not be removed before a future version, like in PHP 5.6 or 5.7. Currently there is no changelog entry that say it is removed in PHP 5.6, so it might be a long time until it happens. Anyway, this is not a problem in PHP 5.5.x. I know this for a fact, as I have upgraded several shared hosting servers to PHP 5.5.x wich is having clients running older CMS of many variants. - - - Updated - - - You corrected the inccorect statement in your reply after i posted my reply to that. Anyway, E_DEPRECATED errors will not cause confusion as it will not be visible in the web pages, but only in the log files (unless you have your server configured in a inappropriate way.
  25. There is no need not to update it. All my servers is running PHP 5.5.8 without problems, expept the server wich is running WHMCS wich still is running PHP 5.4.x - and all it takes for WHMCS is so offer files encoded with Ioncube encoders for PHP 5.3 or newer, and it will work on PHP 5.5.x. WHMCS is currently encoding their files with Ioncube encoders for PHP 5.2.x By the way, PHP 5.6.0alpha1 is now released http://php.net - there is a new major PHP version every 12 months. Please WHMCS, keep up with the times and offer download of files encoded with Ioncube encoders for PHP 5.3.x or newer, so that the ones that like to upgrade to PHP 5.5.x have that possibility.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated