Jump to content

velaware

Alpha Developers
  • Posts

    346
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by velaware

  1. I wrote a small script that aims to help people start on projects extending Blesta. Currently it only allows creating a plugin, but I will be pushing up more templates sooner than later (want to get at least simple module template done too). Any feedback is welcome. This is written with simple PHP in mind, as I didn't see a need to use a full blown framework, so the code may be a little spaghetti. Originally this was going to be written in shell but wanted to make this useful for non-*nix users as well. Project link: https://github.com/velaware/blesta-developers-tools
  2. Per my fixes they are within the SMP plugin itself. As are gosu's.
  3. I have not put up my changes as they are minor really. If there's a demand for it I can, though. For the support ticket issue, it sounds more like an issue w/ your email's spam filtering not working as well as it should vs. an issue with Blesta. Unfortunately there's not much that Blesta can do about that besides putting some sort of validation in place. But, they also offer an option to disable anonymous users from sending emails to departments.
  4. I can see reasons why Blesta wouldn't allow this. Other systems too don't allow this. I.e.: Kayako doesn't (or at least hadn't in the past). For historical reasons, and I'm sure some legal aspects, it's usually best to limit what can be deleted in a client-facing software. ALso thanks @gosuhost for the further explanation. If you want I will edit my fix post with what you gave.
  5. 1. As far as I could tell, yeah. I'm still not 100% following the badge issue but rather investigate than say it's wrong off the bat. 2. When I have some time, sure. 3. Given Blesta is an ever-changing platform, there's no guarantee of future proofing any 3rd party element. Essentially it is up to the author or maintainer to ensure consistency. If the author wants to turn the product over to someone else like I, then I can do my best.
  6. It will work at least up to 4.0 on PHP up to 7.0. I haven't tested it against 4.1. There is a side effect to my badge fix that I wasn't aware of initially, that someone PM'ed me about. When I have some time I will see how that goes or if they want to post here they can.
  7. I have not looked into User Manager Pro (nor was I aware of such plugin). My fix is strictly for the most recent version of the Support Manager Pro plugin. If you are looking for a solution to get UMP to work with Blesta 4.x feel free to PM me and we can discuss the matter. I really don't want to side-track this plugin's support with something else.
  8. Here's the fix for the issues I've seen posted here so far, and have experienced personally. This runs just fine on PHP 5.x and 7.x, and Blesta 4.0. This requires some DB modifications and file changes so if you don't feel comfortable doing that you can either reach out to me for assistance or post here. The below is from a fresh install of the plugin. YMMV but I hope this at least helps bridge the gap between those who can and can't upgrade Blesta over a plugin. * When creating ticket, says ticket was created but no ticket actually shows * No tickets also show in admin panel * No ticket # is generated ERROR: ERROR 1364 (HY000): Field 'name' doesn't have a default value The same error occurred for the other 3 columns as well. CAUSE: The INSERT SQL is not using these columns, but they are marked as NOT NULL in the db, which is blocking the SQL from executing successfully. FIX: alter table support_ticketspro modify name varchar(255) null; alter table support_ticketspro modify reading varchar(255) null; alter table support_ticketspro modify readed varchar(255) null; alter table support_ticketspro modify cfields varchar(255) null; * Badge not rendering CAUSE: On the initial load of pages with the tab, there's validation to ensure that the user is a client or staff, where as the $this->{type} property does not exist. Which is causing PHP to throw an error. An alternative fix is to have property_exists($this, {type}) before the $this->{type} but seeing as how everyone is wanting to move to 4.x I decided to ignore that solution. FIX: Edit file support_managerpro_plugin.php Line 1209: remove "&& $this->staff" (property does not exist anymore on class) Line 1233: remove "&& $this->client" (property does not exist anymore on class) * Enabling this causes extra padding at top of page due to jQuery to get the ticket count due to response being full HTML page instead of expected single line, so instead of just rendering the badge data it's rendering a full HTML page CAUSE: I'm not really sure what the cause is here. It's basically an HTML page without any real content, but it was breaking the design. But, since this was an Ajax call being made anyways I don't know why the original author just did not go this route to begin with. The method has existed since Blesta 3.x FIX: Edit file support_managerpro_plugin.php Line 1218: change newRowCount.trim() to newRowCount.content.trim() Line 1223: repeat change above Line 1242: repeat change above Line 1247: repeat change above Edit file controllers/admin_tickets_count.php At end of index() method add this: return $this->renderAjaxWidgetIfAsync(true); Edit file controllers/client_tickets_count.php At end of index() method add this: return $this->renderAjaxWidgetIfAsync(true);
  9. I'm a little confused as to what is being asked here. So, correct me if I'm wrong. If a payment is being made on an invoice, and it is <= invoice amount, then set applied date to the current date If a payment is being made on an invoice, and it is > invoice amount, then don't set the applied date You also mention credit, so would the apply date in scenario #2 only be set on the credit amount?
  10. Pushed up a fix so you go to http://<ip>/ instead of /blesta now.
  11. There's 3 images on the Docker Hub for Blesta, 2 of which were invalid for me and another that ran in PHP 7 and seemed to come with the kitchen sink. That didn't sit well with me so I decided to create a bare bones instance of Blesta that also passes all required and recommended set ups. The end result is here: https://hub.docker.com/r/velaware/docker-php-blesta/ It does assume some knowledge of Docker (i.e.: how to find the IP and image ID). But, overall, it will get you up and running. This currently comes pre-packaged with 4.0.0 ready to install, but will be improving on this soon. Changing this isn't that difficult. This is in the README.md file too (just go to the GitHub repo) but to access this for now you need to go to /blesta. This will be fixed soon.
  12. To be fair Blesta, from what I can gather, doesn't use stream wrappers anyways, thus the dependency on cURL on install. So, they won't benefit any from that regardless.
  13. Thanks for the clarification; didn't know those files were hotfixed every new release of some sort.
  14. Yeah but you don't have to plop the hotfix in every single time you upgrade, as long as app/app_controller.php and app/app_model.php isn't overwritten you're good once. Plus the hotfix is only for 5.5 (not 5.6 or 5.4), because with 5.5 ionCube had to do some different stuff. However the standard Blesta files will work up to 5.4 without having to worry about the hotfix.
  15. Actually only if the app_controller.php and app_model.php files are modified. Those are the only 2 files I know of in Blesta that are encoded and those are the only 2 in the hotfix folder. If those files aren't touched the encoding is going to stay the same after all.
  16. Yes, but with Blesta supporting 5.1.2, it has to use an older version of phpseclib that supports 5.1.2 as well.
  17. While I understand your point, here's basically another way I can think of to look at it: Blesta uses phpseclib to do a lot of (if not all) the encryption and ciphering of sensitive data like CC numbers. In supporting 5.1.2, Blesta also has to use a version of phpseclib that supports 5.1.2. What this means is that if PHP 5.1.2 isn't compiled with a newer version of say OpenSSL then things in phpseclib and PHP itself that use OpenSSL functions are potentially vulnerable to the hearbleed attack. Thus rendering any sensitive information completely null. This isn't to say that it would happen this way, but this is a major security risk that shouldn't be ignored until something happens (and Blesta gets blamed for carrying an outdated version of a security library).
  18. Has this worked for you? Didn't know this is how the PDO objects were created in Blesta.
  19. To make this short, as a developer I've ran into situations where I've had to connect to a different database within Blesta before. Right now I'm having to manage the PDO stuff myself, which gets ugly and troublesome. Basically what I would like to see is the ability to use the Record class to connect to more than just the Blesta database.
  20. I like. But will this also bring in the more recent features (namespaces, closures, etc...) to both Blesta's core and the developers, or no?
  21. Hell, even put support to 5.3 instead of 5.1.x. At least 5.3 will still be supported for now, and I don't even know of a host that does (or at least should) support 5.1 or 5.2. Even on shared hosting, if people won't upgrade their sites to use something more stable, then you're putting 10 people at risk to please 1.
  22. Yes, the point though isn't what can be used, its that for both security and development reasons supporting versions of PHP that are 8 years dead shouldn't be there. There's a reason why people don't use libraries that haven't been updated in years. In reference to the link you posted/edited afterwards, 5.6 was just released within the past week. You asked when it was still in testing. No company should logically support testing-phase software, but now that 5.6 is officially out for everyone ready for production, they should support it.
  23. According to here: http://docs.blesta.com/display/user/Requirements Blesta supports PHP versions as low as 5.1.3. Looking at the end of life (EOL) of PHP's releases (http://php.net/eol.php), which means absolutely no support anymore except for MAYBE security releases, here's how it breaks up: PHP 5.1 EOL: August 24, 2006 PHP 5.2 EOL: January 6, 2011 PHP 5.3 EOL: August 14, 2014 Now there's some points here: Blesta doesn't take advantage of some of the nicer features of PHP 5.3+, namely namespaces (release notes on 5.3: http://php.net/releases/5_3_0.php) The fact that Blesta supports such outdated versions of PHP leaves itself open to some vulnerabilities due to also having to use old/outdated scripts that still support legacy versions as well 5.3's EOL just happened, and has been stated by the PHP team that they are only focused on security updates for it now, and 5.4 is not far behind 5.6 just came out, with talks already of either a 5.7 or finally releasing PHP 7 within the next year or two There's also the problem that now Blesta has to provide ionCube-encoded files for not only pre-5.5 but also 5.5 and potentially newer versions. I.e.: I develop with 5.5, and want to upgrade to 5.6 but can't due to this. From a developer standpoint, using more current versions of PHP provides a lot more opportunities to developers (i.e.: namespaces are amazing for a community-driven project like Blesta gives the vibe of). Granted, compared to WHMCS it already is in a lot of ways, but I feel this is holding Blesta back more than anything. If hosts are using such archaic versions of PHP to begin with then there's more issues than Blesta can deal with. I simply propose supporting the feature set of 5.3 and higher (at least 5.3), has supporting something that was discontinued 8 years ago to this day does make development for it more difficult than it should.
  24. If you can handle completely signing over your IP that's fine. But then you still have to content with how/if you're going to provide support. You can either be truthful and say the IP is yours, so its up to you to maintain it, or you can charge an extra fee for any upgrades to the code base.
  25. As a developer, and someone who has conversing with you via e-mail, I want to address some things you mentioned. There's a reason, as expressed via e-mail, that developers don't really like other people reselling their work. We do the programming and hard work for $xx, and you resell it for $yy (or even free). Some of us make a living out of developing for Blesta, and some don't. Whatever the case may be, however, that is still profits that we won't be seeing. I personally have asked numerous clients for different projects if they would mind me sharing whatever it is I've done for them, and the answer has 99.9% of the time been "no". Usually with the statement of "we paid you $xx for this, we don't want others to be paying $zz or getting it for free." That is how it is for us as well. If developers were to start allowing others to resell their work, then there would have to be measures in place such as ionCube encoding and licensing to help protect their IP. Personally I don't like locking down my code like that. I'm a firm believer of open source. Say the person who developed your code for you yesterday is no longer reachable the day after, what are you going to do? Even worse, then the support goes down the pipe to you to people you resold it to. It just becomes an ugly mess no matter how you look at it. I've had other people offer to resell stuff I've made before and I've turned them down stating these reasons. In some aspects is more of a liability for you than it would be for me. Its very rare to find a developer who will support someone else's work. Especially if they're not going to see a profit from it and have a massive work load as it stands. Heck, I had to modify Blesta's SolusVM for some specific needs a client wanted as the Blesta team was very busy. I'm not speaking on behalf of every other developer out there, as some will do more than another. But, as a developer business, we are in it to make money. Freely supporting products we didn't create essentially takes a separate team since coding style alone is never the same.
×
×
  • Create New...