The blog addons that come bundled with warehouse is documented in "Simple blog module with documentation/documentation" when you unzip the theme. There's loads of things you can configure there.
However if your main business is blogging you're probably better of with wordpress+woocommerce
@Webshoptime You didn't paste the file requested.
The file you pasted is controllers/front/CategoryController.php
The one we need in order to help you is override/controllers/front/CategoryController.php
Try editing the file admin/themes/default/template/controllers/products/helpers/uploader/ajax.tpl
(if you have renamed admin, of course use the renamed path instead of admin)
find the line:
maxFileSize: {$postmaxsize},
replace it with:
{if isset($postmaxsize)}maxFileSize: {$postmaxsize},{/if}
Does this help?
Ah, so the whole stored was just moved from one host to another. That would obviously bypass all the installation checks.
That's an interesting use case that the code doesn't take into consideration now.
In general when something crazy happens it's a smart thing to go into the thirty bees admin, and then to the page 'Advanced Parameters' 'Configuration Parameters'
This page would have reported the missing bcmath addon.
@Anima did you install thirty bees using the command line installer?
install/index_cli.php
@mdekker if yes then he probably hit the bug in https://github.com/thirtybees/thirtybees/issues/181
phpMyAdmin is able to connect to MySQL using the parameters you provided?
A tips, not related to your problem, you should enable the Zend OpCache in the Uniform Server admin, PHP runs a lot faster then.
@dynambee I agree with all your points.
I'm surprised the focus is so much on performance, when the low volumes we're talking about here is just a joke both for ES and Algolia.
A couple of years ago I setup a ES-based search system that needed to search a database of 150 million complex records. The performance was excellent and the memory- and CPU-consumption was nothing to talk of. We ran it all on two cheap 16GB servers. Just to put things in perspective...
The focus here should really be on functionality, ease of installation and ease of use, not on all the technical issues.
No error messages in the TB log directory or in the PHP errorlog?
If you compare the pre-update root directory to the post-update (you claim this root directory shouldn't be touched), was anything still changed, like the .htaccess file?
Don't know what the problem is, just trying to figure it out...
@Traumflug Could you elaborate on "For handling complex PHP it’s not always up to the task"?
I know some people advocated this some years ago, but this was often for enterprisey supercomplicated setups they hardly understood and didn't dare reconfigure, often with weird apache-specific modules thrown into the mix.
Nginx and phpfpm has also come a long way since then.
From my experience running a pure nginx+phpfpm setup for PS/TB is no problem whatsoever.
It works fine using PHP 5.4 to 7.1.
Your host must have an old module. The PHP 7.0 support was added in the imagick 3.4 version that was released winter 2015.
See https://pecl.php.net/package-changelog.php?package=imagick for all the gory details.
Which features, if any, from ultimate are not already implemented in TB?
I'm askiing because we purchased ultimate from you some time ago, and we´re now moving over to TB.
If you intend to use GA or Piwik, why not just disable all the Analytics and Stats modules?
That way the database tables never grow in the first place, and you avoid some processing overhead too.
@kpodemski It´s not 'thirty bees' wasting time. This is a classical case of a developer scratching his own itch. This is covered in classic open source documents like Dave Thomas "The Pragmatic Programmers" or Eric S. Raymond "The Cathedral and the Bazaar"
In my opinion it´s crucial that developers scratch their own itch, and that thirty bees accept such contributions. It´s what will grow the community and make this much better than Prestashop in the long run.
@Traumflug This module was developed for PS 1.6 and just quickly moved over to thirty bees. I agree with your comments. I was in fact quite shocked when I discovered that PS didn't keep the original image.
I have around 5000 images of all sorts of origins, mostly from professional women's fashion photographers, and I'm using these settings:
Enable ImageMagick: Yes
Use progressive JPEGs: Yes
Strip image: Yes
Resize filter type: Lanczos
PNG data encoding filter: Adaptive
Blur: 0.9
Trim whitespace: Yes
Fuzz: 10%
Original copy: Yes
The technical help and compatability forum areas both are split into subforums.
Looks like there's some bug or config error in the forum software that makes it impossible to open new topics in these subforums.
@alwayspaws The module gives sharper looking images with correct colors. This is especially noticeable if you have high-resolution professional photograper images as your source.
Try this one, it's free, and Vekia normally makes good stuff:
https://www.prestashop.com/forums/topic/200124-free-module-european-union-cookie-law-block-responsive-17-16-15-14/
I always use the command-line installer, it allows you to skip demo-data install, just include an option like:
--step=database,theme,modules,addons_modules
If this type of dependency on PrestaShop file locations are typical in third-party modules...
Perhaps add empty PHP-files at the legacy PrestaShop locations for the files that are deleted and not needed in thirty bees?
It´s silly ofc, but if it helps with compatability why not?