Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/21/2016 in Posts

  1. Very good, thanks for the update!
    2 points
  2. Sorted. It was ModSecurity preventing some forms from being submitted and writing data from /support/ to the DB. Thanks for everyone's suggestions and quick assistance!
    2 points
  3. This issue is most-likely webserver related, possibly due to a conflict/misconfiguration with Wordpress. You should check the webserver's error log for more information.
    2 points
  4. Lets face the fact Blesta's domain management is TOTAL CRAP.. WHMCS and Clientexec do it way better in every way. Blesta does NOT have a proper domain offering, period. seems to be that its just not a priority. Domains are totally unique to generic products and should be treaded as such. For webhosters, domains are part of hosting, the most important part. The enom module for Blesta is 10 years behind that of WHMCS..currently we have the bare minimal basics. What if one wants to only sell a domain ? Does not appear blesta support domain only products. Domain Transfers ? Renew pricing ? Allot of domain renewals cost more than the initial registration fee Name spinning ? Importing and sync of prices from enom & namecheap ? Importing and sync of TLD's and new TLD's from enom & namecheap ? What about .co.uk that requires a 90day before expire renew ? Direct managment of the domain hosted on the registrars nameserver ? Proper whois lookup or usage of dig to check if non api domains are registered/available ? A domain email module, where domain orders are emailed, still does whois checking for availability. Some tld's are still stuck in 1970. Domain availability widget ? ^^ BLESTA FAILS FOR ALL OF THE ABOVE --- I challenge Blesta to make a billing brawl using domain management and include enom's module... btw if you want a reseller enom account, or access to the enom api sandbox , contact me and ill sort you out with an account.
    1 point
  5. Blesta Addons

    Custom Pages

    you can use my admin tools plugins to add a custom page .
    1 point
  6. That fix worked perfectly, thanks Michael! Cheers!
    1 point
  7. Listen to me please. The root is the root not where Blesta is installed, that's why the links aren't correct. And it will only be fixed on new emails. My Blesta was installed at /chroot/username/licensecart.com/html/billing/ so my root was /chroot/username/licensecart.com/html/
    1 point
  8. Bloody ModSecurity again
    1 point
  9. Tyson

    Blesta's Cache

    If you cached the page as I mentioned in post 8, then you can clear it programmatically via: class MyController extends AppController { public function myPage() { $this->clearCache(); ... } } If the URI differs from the URI of the page you cached, you can specify the cached URI as the first argument to clearCache in order to remove it from the cache.
    1 point
  10. Paul

    Blesta Multicraft Dedicated Ip

    You could modify the templates and make all the fields that are not required hidden. In the future, we will be allowing fields to be set to required or hidden via the UI (right now just the Tax ID can be disabled in settings) You still accept payment from them right? I imagine that would be the biggest hangup with kids, rather than supplying their name and address. Chances are, their parents would be helping them with the order. It's pretty much the same no matter what they buy online.
    1 point
  11. activa

    Blesta's Cache

    the emptycache section of amin tools plugin can do the trick ?
    1 point
  12. That's not the settings it should look like this:
    1 point
  13. Tyson

    Blesta's Cache

    The dispatcher fetches cached templates and then displays them. Depending on what you're doing, this may or may not be what you want, as your controller logic will be bypassed. Consider the following scenario: - Your plugin requires an admin to be logged in, and then displays information only they should see. - Your plugin caches the template that was shown (as mentioned in post 8) when the admin visits the page. Now anyone that visits the URI that the admin went to will see the cached data. You do not need to be logged in, as the dispatcher will display the content immediately, bypassing your controller and any other logic that may exist to verify the user's authentication. So, if you are showing static data that any public user should see, caching like this will be fine. However, if you are looking to restrict access to the template, then you do not want to cache it in this manner.
    1 point
  14. i agree with you in this . personally i can't switch to v3 until now just for 3 reason -Domain Management -Multilanguages -Hosting Order Form i know v3 is better than v2.5 , but i can't move from system that i have adapted it to my use (v2.5) , to a new one than i need wait fix's or spend mounth for adding and customizing . time is matter here .
    1 point
×
×
  • Create New...