roband7
-
Posts
131 -
Joined
-
Last visited
Content Type
Profiles
Forums
Gallery
Downloads
Articles
Store
Blogs
Posts posted by roband7
-
-
We use the webservice API a lot. So far we haven´t had to change a thing when moving from PS to TB. For all practical purposes the APIs are identical.
-
I also get these "Internal Error. Oops! Looks like something went wrong!"
Once every 2 or 3 weeks this happens for a specific topic, and I can then never open that topic without getting the error.
Looks like a bug and/or config error in the forum software.
-
Technically it's quite possible to program a new core, while still leaving a compatibility layer for PS 1.6. Developers hate making stuff like that, but if there's a business case for it, it's sure doable.
-
Thanks for the update. I'll check out the RC when it arrives.
-
I have to set up a new shop soon, and planning ahead a bit, I was just wondering if a 1.0.4 release is planned soonish, say like before christmas?
-
The code in the paypal 6 module, in controllers/front/expresscheckoutconfirm.php, function assignCartSummary(), the assignment: $cart->idcarrier = arraykeys($deliveryOption)[0]
Could that be the problem? Other code in core that picks the id_carrier from deliveryOptions does it differently.
-
I don´t have much to add really. The code looks for classes/controller/cbdom.php and that file doesn´t exist.
You need to ask the people that develop the ccavenue addon.
-
The installation doesn't look complete, or it assumes you have done some sort of post-installation setup that you haven't done. It assumes the existence of: classes/controller/cbdom.php
This file seems to be missing at your site.
Was this addon perhaps just copied over from another site and you missed some files. Is there perhaps an addon install procecure you should have used instead?
Probably better if you check with someone that supports the ccavenue addon than here.
-
Also, if the shop has: "Display unavailable product attributes on the product page" set to NO "Allow ordering of out-of-stock products" set to NO
Then it also doesn´t make much sense to display out-of-stock combinations.
-
It's a known problem in 1.0.2.
The easiest fix is probably to just copy classes/AttributeGroup.php and classes/stock/StockAvailable.php from github 1.0.x.
There really needs to be a 1.0.3 release soon.
-
Crap, looks like the forum software ate some of the special characters in my post.
Just check the similar function at the end of classes/Attribute.php, that one does it correctly.
-
Looks like a regression in 1.0.2, classes/AttributeGroup.php function getHigherPosition() was bugged by:
commit bc9637ba9092ad0ba3a4d5c3744a068e025e58b8 Author: Michael Dekker git@michaeldekker.nl Date: Thu Jun 22 02:42:04 2017 +0200 Cleanup AttributeGroup
To fix it, just replace: ->select('MAX(
position') With: ->select('MAX(position)') -
@vzex said in TinyMCE editor in the back office:
@lesley said in TinyMCE editor in the back office:
Are you still getting the 500 error when you try to upload images?
Yes after a new clean install yesterday
Does TinyMCEeditor require imagic module installed to add images because I did not install imagic
Nothing in thirty bees needs imagemagick, it´s an optional module.
For the 500 error surely you have something logged server-side. Check the log directory in your backoffice and/or the PHP error log.
-
I'm worried this topic is derailing a bit.
@vzex Doesn't really want or need imagick. There should be no need to install the thirty bees imagemagick addon in his case.
We just went down that road because of errors done by the host, the PHP install complained about an incorrect version imagick extension.
-
It is indeed another bug, a regresssion in 1.0.2. I put an issue into github as: https://github.com/thirtybees/thirtybees/issues/328
-
Sorry, I was unclear in my previous message, I meant to say this was a bug in 1.0.2, that was fixed recently. I have edited my reply to make this clearer.
But, since it didn't help it looks as if you have a new but similar bug.
-
That looks like a known bug in 1.0.2. Try this patch see if it helps: https://github.com/thirtybees/thirtybees/commit/c643523a0f8d9325eb4867fededd64181939d141
-
@vzex said in TinyMCE editor in the back office:
Paid until 11/17
In the mean time, is the host php what is causing the issue?
Hard to tell, when you lose trust in the host-installed PHP all bets are off.
Try changing to "PHP Stable (5.6)", see if things improve. Worth a try at least.
-
This indeed looks like a host issue.
Have you recently moved from one version of PHP to another?
Looks like your host has an incorrect version of the PHP extension "imagick" included in the config for the PHP version you´re using now.
-
@yaniv14 Fixed the problem. See https://github.com/thirtybees/thirtybees/pull/325
-
It's a hard problem, you have: PHP installation has maxexecutiontime (default 30) Nginx fastcgireadtimeout (default 60) Apache Timeout/ProxyTimeout (default 60)
Then the PHP code may go on doing something really long-running (like loading the database or resizing images). Or something that blocks on an external resource (like a HTTP request to a dead or slow host)
How to handle this mess in a good way, so it always either works or gives a meaningful error message when it doesn't? And even worse when it's an AJAX-request triggering the above...
-
@lesley Translated into "Bad Configuration File"
-
It is indeed a bug. It´s a regression in TB 1.0.2 caused by the change to classes/Language.php function countActiveLanguages() in commit ID 5b225bb on the 22´nd of June.
I reported it as https://github.com/thirtybees/thirtybees/issues/324
-
https://front.thirtybees.com/ https://back.thirtybees.com/administrator
1.0.4 soon?
in English
Posted
I do remember @mdekker writing someplace (I forgot where) that he wanted to make the installer and upgrader more robust before releasing 1.0.4.
But all the latest commits have been all over the place except in these two components.
So I'm also a bit confused about the plan...