Jump to content

Jono

Blesta Developers
  • Posts

    376
  • Joined

  • Last visited

  • Days Won

    37

Posts posted by Jono

  1. You really don't need

    $this->view->set("package", $package->meta ); 

    Since you can access the package meta from the view if you use:

    $this->view->set('package', $package);

    That first 'package' parameter determines the variable name in the view so if you have two $this->view->set('package', ....); statements then they would conflict.

  2. Are you sure the package group is what you're looking for?  Each service is assigned to a package.  That package has a description.  That package may be assigned to any number of package groups.  To access the $package in the view you would add this to the controller:

    $this->view->set('package', $package);
    

    To display the package description you would do:

    <p><?php echo $this->Html->ifSet($package->description);?><p>

    To display the package group descriptions you could do something like:

    <?php
    foreach ($this->Html->ifSet($package->groups, []) as $package_group)
    ?>
    <p><?php echo $this->Html->ifSet($package_group->description);?><p>
    <?php
    }
    ?>

     

  3. Looking at past forum posts people commonly experienced 1 of 3 issues:

    1. The exec() function is disabled

    2. The escapeshellarg() function is disabled

    3. The web server cannot run mysqldump, either because mysqldump is missing from the system or the web user doesn't have permissions.

    I think based on your error it could be #3 since I believe the first two would cause a php error message of their own.

  4. Ah, now that is an interesting case.  The answer to your question in this case is no, it does not account for daylight savings.  If you set the time to 07:00 PDT then the datebase saves at as 00:00 UTC.  Then outside daylight savings the cron will see that 00:00 UTC as 08:00 PST and I suspect that's also what it would show in the interface so you would have to manually adjust it to 07:00 PST (which would then be stored as 23:00 UTC)

  5.  

    On 9/20/2020 at 7:50 AM, vedova said:

    After removing it from init and structure and htaccess file frontend works, but backend still not.

    I assume by frontend you mean the client interface and by backend you mean the admin interface.  It is important to note that there is a separate structure.pdt files for each at app/view/client/bootstrap/structure.pdt and app/view/admin/default/structure.pdt respectively.  If you have not already, make sure you update that second one in the admin view directory if necessary.  Disclaimer - I have no knowledge of this specific plugin x)

  6. 8 minutes ago, turner2f said:

    How do we make it so that the uploads folder is not publicly accessible ?

    Just make sure the folder is not under your root web directory.

    9 minutes ago, turner2f said:

    I was referring to restricting certain exploit file types directly through the Support Manager interface.

    Certainly could, though I wouldn't call it a major security issue since filenames are already overwritten and there is no way for the files to be accessed unless someone has access to your server.  Still, https://dev.blesta.com/browse/CORE-3903

  7.  

    10 minutes ago, turner2f said:

    Was this a feature in version 4.0.1 ?

    Well it has always had partial consideration because dates are stored in UTC so when these dates are displayed we always convert them to the current timezone (daylight savings or not).  But some of the other issues of saying "today +1 month" and that considering daylight savings was taken care of by using PHP's DateTime class which we started doing in 4.2 https://dev.blesta.com/browse/CORE-2378

  8. 19 hours ago, turner2f said:

    What Upgrades were made to the "PayPal Standards" module between v.1.3.0 and v.1.6.0 ?

    There was one important change from PayPal that may be relevant.  https://www.paypal.com/us/smarthelp/article/important-notice-regarding-upcoming-subscription-changes-ts2239 based on which we created https://dev.blesta.com/browse/CORE-3180.  I don't see how the hit-or-miss behavior could be Blesta side, but perhaps you can look in Tools > Logs > Gateway to see if the IPN notifications are coming in and just receiving some kind of error.

  9. Not totally sure what to say to this.  The password field is split into two in the backend, so that addresses your second comment.  As for the first, the password field is auto-filled, so for it to be empty you would have to manually empty it or otherwise it would have to have been already an empty value before you loaded the page.  As far as I can see in the code there is no such bug.  Yes Blesta always tries to change the password, but it shouldn't matter since the field is auto-filled with the current one.

×
×
  • Create New...