Obi

Just so you know, this is NOT the way it is done in the TB 1.4 release that I recently downloaded. My slider images were broken as well until I replaced the aforementioned code line with this one in both the module location as well as the theme/module location.

C'mon Nickz... I specifically said that I am migrating from PS 1.6 to TB 1.4, which inherently means I am running PS 1.6 and have installed the psonesixmigrator module on the PS 1.6 cloned site but cannot proceed because of the fopen error on the PS 1.6 clone site. IF, on the other hand, your comment above was to imply that I should install psonesixmigrator onto a TB 1.4 site and attempt to clone the data from the cloned PS 1.6 site, according to the psonesixmigrator description that isn't the way the module works - it requires that it be installed on the PS 1.6 site so that it may CONVERT THAT site TO a Thirty Bees installation - quote from github (first emphasis mine): So my question again is: Is there any way to get around the fopen error using psonesixmigrator module to convert my PS 1.6 shop to TB 1.4?

Is there a data transfer or synchronization module available for thirty bees where I can install on TB and then connect to the database of another site, like a PS 1.6.x site to migrate the data over - without a whole bunch of fuss or risk? I did find a module that claims to do this, but the reviews had numerous posts about it destroying the data in the source database - not sure why that would happen with a simple transfer - so I moved on, but that got me to thinking somebody must have done something similar that only READS from the source database... ie: bring data over from a production server to a development, beta, or clone server for testing / modifications with same or different Prestashop based DB versions.

So I have run into an issue with the onesixmigrator: I have checked that [allow_url_fopen = On] is set in the php.ini file... but since the configuration page on both the clone and production site say that fopen is not allowed: I can only assume this is a setting established by the host provider - who I am sure will not change this setting for security reasons if that is what it is... So the question is: Is there a workaround to get the migrator to perform the migration without fopen() ??

You can't run Prestashop 1.6.x on php7.4 and the migrator doesn't give you an option on the version of TB either.

I completed a migration last year that took a whole week on a PS1.6.1.4 / Panda 1.2 site that I ultimately rejected because the presentation was simply NOT reliable (images mostly - sometimes appeared correctly, sometimes not, etc.), anyway I just started a new attempt to migrate from PS1.6.1.4 / Panda 1.2 to TB 1.4 by cloning the production site (which I checked after the cloning process thoroughly to ensure it was complete), but after installing the psonesixmigrator.php module, I still get this: ...even though my php.ini does contain "allow_url_fopen = On". magic_quotes_gpc = Off allow_url_fopen = On expose_php = Off post_max_size = 8M upload_max_filesize = 8M max_file_uploads = 20 default_socket_timeout = 180 mysql.connect_timeout = 180 memory_limit = 1024M max_execution_time = 180 max_input_time = -1 max_input_vars = 5000 suhosin.memory_limit = 4096M suhosin.post.max_vars = 5000 suhosin.request.max_vars = 5000 display_errors = Off enable_dl = Off file_uploads = On session.gc_maxlifetime = 1440 That said, when I view the configuration page for both sites, I see this: ...So I have to assume it is a setting my hosting company will not change... Any way to get around this??

Posting the answer to my question so it will hopefully help someone else with a same/similar issue: Code comments should answer any questions about where and what... // Execute Hook FrontController SetMedia Hook::exec('actionFrontControllerSetMedia', []); // Added custom stylesheet here to insure it is last to load - Obi // module css files still load after this - not sure where $this->addCSS(_THEME_CSS_DIR_.'dws-custom.css', 'all'); $this->addSyntheticSchedulerJs(); return true; }

The title pretty much states my question, but for the sake of clarity. . . Has the Image Hover feature that is/was available in Prestashop 1.6.x ever get "ported" over to Thirty Bees? The last time I did a migration attempt, this feature was missing in TB1.3. I began using the image hover capability for product display in my Prestashop 1.6 store for two different purposes and have been waiting for Thirty Bees to implement this feature before attempting another migration. My catalog has around 17,000 product records, most of which use custom "product templates" displayed in the "pa_content" container to give the products in any given range/group/category a more immersive and distinctly identifiable presentation. This was accomplished primarily thanks to Panda Theme v1.2. Previous migration efforts proved to be a touch more complex than anticipated, and while a migration was ultimately successful, it was not stable. The Panda theme used (1.4 IIRC) did not work as it should with the most difficult to correct being the image display along with a few other elements did not work reliably (their change of the style class names between versions made the old css unusable which required a rewrite of 2000 lines of css code) but even then, the unstable display of images (sometimes would display correct, sometimes not) ultimately forced me to abandon that migration. I've since decided I am willing to revisit this issue without using Panda going forward, and may be willing to discard some of the highly customized and unique overall presentation of the current site if necessary, but I refuse to give up what I consider to be basic features that afford better user, customer service/interaction, and administration functionality to my site because of "upgrades". (I also use a few modules that I have since ported to run under TB.) To illustrate the unique nature of the site and why this is such a difficult move for me (because I am losing so much in the visual sphere): (home page) Product Listing Page (pre-hover): Product Listing Page (post hover): Product Page (above fold): Product Page (below fold): Photo to illustrate the UI of the backoffice implementation of the hover feature:

For some reason, this issue seems to have gone away on it's own. My language translations for the theme were somehow lost and after I restored them, the images now appear normally in the back office product page, even for newly uploaded images. I am really confused now because I see no reason why language files would have any connection to the display of images - but that is the ONLY thing that I changed as I was waiting for an answer here in the forum of what else to check - so I moved on to making a couple of css tweaks - which is how I discovered the theme was using the default language translations instead of the custom translations I applied weeks ago.

Ok, another issue that I don't understand ... Since completing the TB 1.3.0 install, most things have been pretty quick and painless (403 error on SEO & URLS page just got fixed with a simple setting change) but just prior to this I came across an issue in the products page of the back office. This part of the installation hasn't had an issue - at all - until today. As a matter of fact, a couple of days ago I created and uploaded a few more items to the catalog with photos without a hitch. Today (before change the mod_security yes/no switch in the back office) I decided to add another item to the catalog the same as I have done with the 183 previous products I have added - only today when uploading the images I get this... I get this when I do a [view image info]... And as this screenshot indicates - if I click the broken-link image - the image loads... and as you can see by this filezilla screenshot - all of the images are indeed on the server where they belong... I'm running the community default theme copied to a new name - which has been installed now for about a month with no known issues. I've regenerated product images with no success - the broken-link-image is still present. I suppose I'm at a point where I am not sure where/how to debug this issue except that it looks like TB is using the .htaccess file to locate images - but that hasn't changed either to the best of my knowledge. As a matter of fact, the site sat idle for a few days since my last product add session because I had other non-website tasks to deal with, and this is the issue I came back to when adding the next product. Suggestions??

Not sure if you meant to disable under cpanel or via the page... However setting "Disable Apache's mod_security module" to [Yes] seems to have solved the problem.

My server is also a Linux server running Litespeed and PHP 7.4.32 UPDATE: I've also tried changing the permissions on .htacces to 666 as per the "information tip" instructions embedded in /controllers/admin/AdminMetaController.php - no change in behavior, error still presents. I have also discovered that I receive the same 403 error when clicking the "save" button for the [Set up URLs], [Set shop URL], and [Schema of URLs]. I am however, able to edit and save page modifications (changed the meta description for the index entry) as well as generate robots.txt and .htaccess files.

What exactly should I be looking for? I've already change the root from 750 to 755 (and only the root), and the .htaccess from 644 to 755, and still get the same error. I have changed those permissions back to their original settings as I know for sure that the .htaccess file permissions set at 755 is not a good idea.

Thank you for that information - very helpful. I do understand that the theme author can change the rules - part of the painful issue that has caused me to abandon panda for use with this new website. Besides various other issues, they changed the specificity on a large number of declarations breaking the custom css that gives my other site it's very unique appearance - 1800 lines of css morph the site from a bland out of the box default looking theme into what I ended up with. [screenshots attached] (Face it all of Panda's themes were more or less black and white variations of the original - but with lots of extra modules and the custom css and js fields in their editor - the theme worked and it worked well.) I praised them for quite some time for having a theme tool that allowed me to create such a site with almost no core code customization - but when I hit 1800 lines - because they stored the css code in the configuration table... it broke. That forced me to utilize the technique above moving that code into a custom.css file and loading it for proximity override. It's been through 2 upgrads of the theme and all was well until I attempted a migration from PS 1.6 to TB 1.3.0 with that site - boom! doesn't work... after a month - I'm done - I'll find another solution. And this is where your specificity COULD have helped, but they changed the selectors substantially so specificity would not have overcome that issue. I did not however give up on Thirty Bees, and because of the PHP version issues the hobby site is now facing - I chose to select TB for this new site rather than deal with Prestashop's stupidity in the 1.7 codebase. But I digress... I actually have my custom css working now using an override and I'm happy with that result. I may look into option 2 for a more flexible solution in the future - maybe - probably not though since option 3 does exactly what I was after. Screenshots of the other site created with Panda (Demo 7 theme was the style I started with): Listing Page: Product Page (above the fold): Product page (below the fold): The site gets a decent amount of traffic (server logs indicate 4.6 million hits this year with nearly 750k pages served). This is what that Demo 7 theme looks like out of the box ... Every page in the site has been customized with that proximity loaded custom css stylesheet... and if it weren't for the php issue with PS1.6 - I wouldn't even be considering making any migrations with that site. Hopefully this conversation can give others some inspiration in developing or customizing their themes. I'll come back and post what I've done with the community-default-theme if anyone is interested. Thanks again for providing the information, it should help others in the future.

Hello, I'm trying to move the wishlist button on the product page but can't seem to find where to hook it to move it next to the print button. I think transplanting it to $HOOK_EXTRA_LEFT would do the trick but can't seem to find a location that uses that hook for the wishlist block. I've created a new theme (mostly just a copy at this point) from community-theme-default if that makes any difference. Thanks!

In order to prevent breaking the theme customizations on upgrade, I believe using proximity is best (your point on including more specificity isn't a bad idea) - but proximity has worked well for me for years using the Panda theme. However the new Panda 1.5 incarnation doesn't work correctly with TB 1.3 and based on the installation, it looks like they have injected some license validation code somewhere - total showstopper for me as I just went through that with the eMagicOne Presta Store Manager crapping out on me until they fixed their license validation server. I had to resort to shipping and processing orders and inventory management via the old backoffice screens - painful. So to my simple question which has really not yet been answered: How DO I ADD a custom css stylesheet file to the $css_files array (and where) so that it is loaded LAST from/within the setMedia function? (I assume this is at least close to where the magic should happen.) I've gotten the file to load after the hook in the setMedia function by using: $this->addCSS(_THEME_CSS_DIR_.'my-custom.css', 'all'); ...but all the module css files still load after that, which is a problem for me. Thanks

That would work except that I need to ensure that my custom.css file loads last for inheritance reasons.

I recently installed TB 1.3.0 and began configuring for a new store and when I get to the SEO & URLS page and try to save anything, I get a 403 Error - any ideas? Permissions are 0755 on the admin directory and sub-folders and 0644 on files. I haven't encountered this issue anywhere else in the backoffice. Store front seems to be working fine.

I don't have a loading problem and have over 1 million visitors this year on my other site using the same technique... What is bad is serving that "custom css" from the database, which Panda does.

Following...

Thanks - I thought adding at line 1078 and copying to the /override/classes/controller/ location would do the trick, but my custom css file is not getting loaded. // Added custom stylesheet here to insure it is last to load - OBI $this->addCSS(_THEME_CSS_DIR_.'dws-custom.css', 'all'); This is what I am using to load that stylesheet - I've aslo checked to make sure the dws-custom.css file is located in the /themes/themename/css/ directory and it is there - can you tell me what I'm doing wrong?

Is there a module that will allow you to override the theme code with your own CSS file? I managed to accomplish this using the Panda theme by removing the database storage and adding the desired custom css filename to the $css_files array (about line 8218 in /modules/stthemeeditor/stthemeeditor.php) - it works nicely, but there is no stthemeeditor.php equivalent that I have found so far in thirty bees community-default-theme. I really don't want to spend the time to write the module for this, especiallly if one already exists, so any help would be appreciated. Thanks

Actually, the Panda MegaMenu will auto add if you set it up correctly. That said, I'm looking to move away from Panda because of the changes they made in the TB compatible codebase. I attempted a migration on one of my sites that has about 16k products in the catalog and which has a custom front-end that you would not recognize as a Prestashop based store (the possibilities with Panda in this regard are almost limitless)... After nearly a week of just rooting out the css element changes they made, the images still would not display correctly because of their "mobile first" modifications (I believe). I also discovered they are coding to a license server model, and while it is possible to remove that, why would I? It only means there will never be support for MY code version... So I've cut my losses and am crossing my fingers with the hope that someone will come out with a "Panda" similar theme that won't lock me down like Sunnytoo has. Oh yeah, about that "support" and "lifetime license" ... A Panda "lifetime" license is only good as long as you don't have to upgrade... which in this sphere is about 2-5 years depending on where you started. And about that support . . . Sunnytoo wanted to charge me to fix what they changed in the code that would not allow me to migrate what I have directly over to the new version. I don't know whether this was by design or simply because they have no regard for the thousands of websites that use the previous Panda implementation to cusomize the presenation layer of their websites - Caveat emptor.

I'm having trouble finding where the $css_files array gets populated - can someone point me to the php file please? Thanks