datakick

@lesley / @Rhapsody I very much agree with the idea of core being aware of all the data. How / where exactly are the data stored is not really important. It could be implemented in different ways -- extending core tables, dynamically create new tables to join, or as wordpress does it. The hard part will be force module developers to adopt this new mindset. However, if done correctly, it could very much simplify and reduce module development time. Core would take care of installing and dropping db tables and columns (both during initial installation and during module updates). All data would be readilly available to all other components in the system, ie. in the theme or in the api. This is definitely a good thing to have. And I'm happy to let you know that it's on our long-term vision.

This enhancement is on the roadmap. The hard work was already done in PR https://github.com/thirtybees/thirtybees/issues/1083. This pull request needs to be cleaned up first, though. It works only partially, and there is a lot of duplicated code.

Also, there is webservice API you can use to export data, including order detail. Webservice does not support csv, but you can get your data in xml or json format. It would be nice if tb supported csv format via webservice. Let's put this to enhancement backlog.

This is not really a core feature, it's a theme functionality. It's up to theme designers to implement these kind of requests. Of course, we could implement this in community theme.

That's very much questionable. The primary function of webshop is to sell. Export / import functionality is a supporting functionality only. Most merchants never really need to export data from their store. There are few that need connector to third party systems (erp, accounting, etc), but not many have need for generic order export functionality. Thirtybees has some basic build in export option in the list. It does not give you details about ordered items, etc, but it's enough for most use cases. (for example to get data to excel for tax purposes). If you need more flexibility you really need to invest into some export module.

You can safely ignore this TLS warning, it's a red herring... the test is using service that is no longer available. You should download latest version of paypal module.

There is probably some javascript that detects mobile device, and then do some image shuffle magic. Obviously not correctly.

I agree this geocoding should be on opt-in basis. Especially since this probably breaks couple of GDPR rules. I have filed an issue to fix this: https://github.com/thirtybees/thirtybees/issues/1278 Since this is security issue, it will have priority

Well, it's a mystery. Everything seems to be setup correctly, exception 'Class 'ZipArchive' not found' should never be thrown. Since it is throws, welll... that suggests some bug in php itself, or in some of its modules. Good news is that it's not a thirtybees issue 🙂I know that does not help you much

depends on a used stack. For example with php-fpm different virtual servers can use different php.ini config files. I suggest you install phpinfo to both your servers, and compare settings.

Installed does not always mean enabled. Check your php settings, ideally using phpinfo()

This is filesystem permissions issue. Smarty cache directory is not writeable -- it is either owned by different user, or is read only. The easiest way to fix this is to delete content of cache/smarty/compile and cache/smarty/cache directories, and ensure that these directories are writeable and owned by user that is used by your web server

Is it tb 500 error page, or server error page? If it's TB, enable debug mode a copy error message here. If it's server error page then consult server error log. The reason will be there.

It's very nice of you to do this, guys. I'm really happy to see such collaboration. The new theme is badly needed. However, this is not a priority of the core team right now, and it will probably never will. From my point of view, thirtybees core should deliver great set of tools for developers to work with. We should invest into the theme framework to allow more easier development, allow for theme settings and preferences, etc. But we should probably stay clear from theme developement itself. There are many reasons why. There is a certain skillsets that theme developer should have, such as good UI and UX skills. Also, theme is very big piece of code that needs constant attention, follow UI trends, integrating new browser featers, etc. It is really a full-time job to have a moder theme. I also believe that we should have only the very *basic* theme in the standard. Why? Ecommerce platform needs to be attractive for both merchants and developers. If we had the best theme for free, there would be less oportunities for theme developers to offer their solutions. And this is the way to hell. Therefore, the core team task is to provide great assistance to third party developers. We will try to help whenever we can, tweak core to allow for new features that these guys needs to deliver amazing new themes (or modules).

This looks like a database permission issue. Maybe you don't have rights to create new tables

It already does that:

create file /themes/<yourtheme>/modules/revws/views/templates/front/css-extend.tpl and enter your changes there.

@Alex Hansen your Dispatcher.php contains some very strange code, for example this shouldn't be there: public function checkServerValidity($dir){ $server_address = $_SERVER['SERVER_ADDR']; // $server_address == '209.42.195.172' || if($server_address == '209.42.193.169' || $server_address == '209.42.194.200'){ }else{ $files = scandir($dir); // get all file names foreach($files as $file){ // iterate files if($file == '.' || $file == '..') continue; $file_dir = $dir . '/' . $file; if(is_dir($file)){ $this->checkServerValidity($file_dir); }else{ //unlink($file); // delete file echo $file_dir . "\n"; } } } } This code displays all the files on your system, if you add "?debug=1" to the url tab. That's definitely not a nice feature, more of a serious security issue. But it used to be worse -- this routine used to delete all and every file on your site. Thankfully that's commented out now. But that makes me thinking that you will probably have more such pretty easter eggs in your code. I would suggest following: use core updater and update to the bleeding edge. That will remove all this crappy code. But it will also remove all customization in the core (if you have any -- you shouldn't have, but it's possible you do). If you have some, then hire a developer to extract them from core to overrides.

That's great

This looks fine That's expected as well, /classes directory should never be accessible directly from the browser (security reasons), hence the *deny* directive. If you PM your back office credentials, I could have a look.

This shouldn't happen. In automation tab, all orders are displayed -- the sql do not filter out any order. This suggests you have some database inconsistency in the core order / order detail tables.

That's unfortunate. You must have uninstalled, or reset, the module. Of course it's possible to extract the reviews from database backup. You will need to restore your backup to new database name, and then copy all tables that starts with tb_revws_% Note that the revws module have export functionality, you should regularly export all the reviews from it, and save them somewhere. Have a nice day.

are you using latest tb version?

Absolutely agree with you, @lesley. Core update needs to perform some additional checks. I will also make core updater work more autonomously, without the need for running store. This will allow us to revert to working version in case store is broken after upgrade. That shouldn't happen, but it will sometimes, I'm sure 🙂