Jump to content

velaware

Alpha Developers
  • Posts

    346
  • Joined

  • Last visited

  • Days Won

    8

Posts 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. 4 minutes ago, turner2f said:

    Thank you both.

    I understand what you mean concerning the limitation, but on the " flip-side of the coin " we also get " junk " or un-useful support tickets that come through as well that we want to get rid of.

    And our ONLY option is to mark them as "Closed".

    What Blesta should at least have is a " junk " folder that we can put these kinds of tickets in.

    ==========

    Is there a download link that already has both of your fixes ?

    I would stress-test the plugin for any possible issues.

    ==========

    Thank you in advance.

    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.

  3. 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.

  4. 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.

  5. Quote

    Are you saying that implementing these fixes will get "User Manager Pro" up and working again  ?

    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.

  6. 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);

  7. I'm a little confused as to what is being asked here.  So, correct me if I'm wrong.

    1. If a payment is being made on an invoice, and it is <= invoice amount, then set applied date to the current date
    2. 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?

  8. 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.

  9. Yes, you MUST overwrite these files when upgrading. Every single time.

     

    Also, to clarify, the hotfix can be applied to PHP 5.4 or PHP 5.5. The standard distribution will work from PHP 5.1-5.4, so it's not necessary to apply the hotfix to PHP 5.4, but you can. Also, there are 3 files, not 2 that are encoded. If you are only seeing 2, you may be looking at a patch where there was no change. Every major or minor release will have all 3 of the files.

    Thanks for the clarification; didn't know those files were hotfixed every new release of some sort.

  10. The default Blesta is encoded with a old ioncube loader, you replace them with the new ioncube loader files in the hotfix, so it works on 5.4 & 5.5+ when supported.

    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.

  11. Yes it needs to be applied to every version.

    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.

  12. Generaly (I will explain why I think Blesta is not in this category) it can be problem for hosting companies which have many clents and don-t implement multi php selectors,

    I have tons of user that uses ....5.1, 5.2 or 5,3 infact 90% of them ar at 5.3 and lower .But since I implement multi php selectors on all servers including cPanel runing on centos(have  two on centos rest run on cloud linux) it is not problem for me,now why I thnk blesta can be safely be excluded from this ,because it is billing software and 95% webmaster host this kind of softwares isolated and not on same server where clients are(this is essential) so in theory they will not have problem to edit configuration without braking clients.

    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).

  13. 
    $db_info = array(
    'driver' => "mysql",
    'host' => "yourmysqlserver.com",
    'database' => "database_name",
    'user' => "database"user",
    'pass' => "password_database",
    'persistent' => false, // or true
    'charset_query' => "SET NAMES 'utf8'",
    'options' => array()
    );
    
    $remote_database = new Record($db_info);
    
    
    

    Has this worked for you?  Didn't know this is how the PDO objects were created in Blesta.

  14. 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.

  15. Does anyone have a good argument for supporting the older versions? Unless you're running it on the same server as lots of shared hosting clients you should be able to keep PHP updated easily. And if that is the case just put Blesta on it's own VM.

    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.

  16. You can use 5.1, 5.2, 5.3, 5.4 with the default files.... use the hotfix-5.5 folder contents to overwrite the licensing files... This will allow you to use Blesta on 5.5, 5.6, 5.x

    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.

  17. 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.

  18. You make some good points. I'm also a developer and what I have sometimes done is told the client they can get the extension developed for $100 and own the IP, or for 20% less I will own the IP. Then I can sell it myself if I want to make some extra money. I work primarily with OpenCart and as far as I know not one extension is ionCube encoded. But I know this won't work everywhere.

    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.

  19. As a developer, and someone who has conversing with you via e-mail, I want to address some things you mentioned.
     

    On page one this comments was made: 'all of us developpers will help you and build it'
    I contacted several developers and before we made a clear overview of what it would cost to have the essential modules developers, we ready to have a module made,
    found out that the general tone isn't to help out the community (Develop the module and make it available (commercially / free) on the forums but they rather keep the modules to themselve,
    we contacted 4 developers and they all mentioned this to us.


    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.
     

    Further more,
    the fact that modules garden left to work exclusively for whmcs is never good for business but at least you could absorb the modules (which they handed over) and keep providing updates etc but what I understood from the page it's basically 'as is'. The same principle applies with a lot of the other modules developers here, a lot of them are 'as is'.

     
    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...