Traumflug

Do I need to edit more than: controllers/admin/AdminPPreferencesController.php ? Yes. You also have to forward this flag to the template: https://github.com/thirtybees/thirtybees/commit/a92b49b75802426443d4d21c67476eee886390a7 And you have to change the template to recognize this flag: https://github.com/thirtybees/community-theme-default/commit/6dfd9d025c5c4b012a79287f56fff2d7a0bd5f11 I think that's it.

@dynambee The problem is @Traumflug writes like he has an authoritative knowledge on the subject of Elasticsearch As far as I understand matters, thirty bees isn't about demo'ing ElasticSearch, it's about good experience for merchants and even more for their customers. Nota bene for shops having this service available and for shops having it not. Just waiving "Yay, we have an ES module!" isn't sufficient to achieve that. Discussing and refining a spec sheet not only expresses user/merchant/donator expectations, it also helps aligning these expectations with the developer's ideas and help him laying out a plan on how to write the code. What's possible to do from within a module, what requires touching general code, what's better done in a slightly different way, what requires additional budget, what can't be done at all. Right now this sheet reads much like "we barely know what we want, but we want everything". A nice recipe for disappointment. Looking at the current discussion style, such specification refinement is apparently no longer possible, so I'll stop discussing here. Good luck!

If you don’t ask for A in the specifications, A won’t be there in the module. He’s not saying if it’s easy or hard. Thanks.

You mean, a malicious module could steal that password? Yes, that's entirely possible. Badly written modules can do a lot of harm, even bring down the entire shop. As far as I can see, there is no protection against malformed/malicious modules, each of them receives 100% trust, no matter where it comes from or who installed it. Mistrusting them opens a large can of worms, just look at all the measures web browsers implement to run JavaScript & Co. inside kind of sandboxes. Guessing by the hook name I assume it wants to enable creating user accounts elsewhere, e.g. on an LDAP server or in a nearby blog, wiki, whatever. For such actions one needs the password.

Switch to remove condition Contributed by Nobodaddy just last week: https://github.com/thirtybees/thirtybees/pull/260 :-) Once solution goes to open file and comment out/change/add…things can go really wrong! Make a backup. Like simply making a copy of the file right where it is. This on the shell (or by some other means): none cp -p product.tpl product.tpl-2017-06-28 Unknown templates get ignored. If something goes wrong, simply copy the file back and start over.

who even seemed confused about how open source licensing works Me? lol I don't think there are many people on this planet who have studied all the flavors of "open source" more than me. I'm doing this for some 30 years now and have participated in more projects than I can count. you sure seem to have a lot of “ideas” today about exactly how everything related to this module should be done. Ah. Pointing out flaws in the above specification upsets you. Good to know. It doesn’t matter if ES is on the local server or a remote server it is still accessed through the API via IP & port. As such timeouts are possible even on a local server. If this is your assumption, please put it into the specification. MySQL is a local server, too, and queries to/from there are expected to be fast and reliable. If they're not, an exception happens, which means a blank page in production mode or this new encrypted error message. Handling such stuff more gracefully needs more code and if this isn't part of the specification, it won't happen.

I forgot one point for the specification: All current search API (hooks, template variables, etc.) should continue to be supported, so current themes continue to work, too.

Not all will be able to use it as a local service. [...] But then there is a possibility to use a hosted alternative. Writing a module which supports both, local and remote services, sounds like a non-trivial change. For example, remote requests have to handle timeouts gracefully and requests asynchronously. With local requests one can rely on a timely answer, which is much simpler. It should be clear whether remote requests are part of the specification or not, before that specification is finalized.

Now being clear it should become a local service, I'd like to add these to the specifications sheet: Use it as a local service (well, obviously). Detect presence of this service automatically. At most, ask for entering a single address/port/name. Abstract the service connector, to make a change to the next generation search engine possible. Make it an extension to the standard search module, so merchants don't have to configure this (choose hooks, define blacklist, define fields to be indexed/searched) twice. Alternatively, provide a common configuration page for all search engines. Keep search engine choice transparent to the theme. Front office themes shouldn't have to care about which search engine is currently at work. Implement features like infinite scroll, cancel button, price slider in an engine-agnostic way. That probably means outside the module. If functionality requires additional hooks, or extension of existing hooks, or new Ajax callbacks, implement that for standard search, too. With dummy answers if not applicable. In order to keep the search engine choice away from the theme and other parts of the shop software.

@dynambee Okay, I’ll take a crack at answering these: Thanks for the effort, even if @roband7 's short note answered most of this already. I just looked up above again, there is no mention that this should be a local service. And looking at the ES site, one sees subscription plans and remote requests as code samples. Looks like a few people forgot the basics in all this buzzword euphoria :-)

@alwayspaws, perhaps you should provide some of your CSVs for demonstration the problem. The shorter, the better, as long as the problem shows up.

Right now you can simply keep a copy of your current shop. In the future? Well, hard to predict. That'd be a thirty bees 1.1.5 to PrestaShop 1.8.3 migration, then? If there is such demand, I'm pretty sure somebody will write a migration tool or offer migration services.

In other words we’re not talking about ES as a cloud service, but as a locally installed piece of open source software, just like MySQL. That's indeed news to me and answers more than half of the questions. Thanks!

The basics of a module, ie. what’s needed for a module that does no core class overrides, should be easy enough. Yes. Core class overrides, it’s probably just impossible to support it all forever Forever? Probably not. For a while? Certainly possible. Current strategy and PS' strategy up to 1.6.1 is to not remove or change functions/methods without an extended deprecation period. For example, 30bz still contains some code for compatibility with PS 1.4. hooks Apparently handled similar to functions, but need changes not as often. Template names assumes by the core Fully hardcoded in PS 1.6 and 30bz. Often in the middle of the code calling these templates. Urps. PS 1.7 made some efforts to relax this hardcoding, kind of a template configuration was introduced: https://github.com/PrestaShop/PrestaShop/blob/develop/themes/classic/config/theme.yml So far for the basic layout, only. Smarty variables passed to these templates Globally available smart variables These are indeed a bitch. Modules send them directly, so their amount and content depends on what modules are installed. There are no "namespaces". PS 1.7 partially introduced such namespaces, e.g. $price became $product.price. Generally, one can do pretty much anything. See how modern Windows' still support Win95 applications. It just adds up. Having all the template variables for PS 1.5, 1.6, 1.7, 30bz 1.0, 1.1, 1.2 available doubles code work and memory usage. So stuff has to go away not tomorrow, but somewhere on the horizon. A partial workaround could be to detect template versions. AFAIK, there is currently no such thing. One can currently install a PS 1.7 theme easily on 30bz, it just doesn't work. Another thing to consider is that PS advances, too. Themes advance. Requirements, expectations advance. Which means, theme makers want no stillstanding either. Which in turn, I think, should lead less to efforts to keep everything as-is as much as possible, more to efforts making transitions easier. To everybody raising eyebrows now: there are no plans to give up PS 1.6 compatibility anytime soon, AFAIK. Thirty bees' stated goal is to be stable and reliable.

For my part I try to think with merchants and with the future of thirty bees: ES is free now, will it be free in 5 years? What if this API changes, who does the migration? Merchants don't care about the technology used behind the scenes, they want a well working search function. For merchants, a requirement to hook up with another service just to get basic functionality is a burden and entry barrier. How can this be avoided? Per the provided feature list, ES search requires a fallback search engine. Which means duplicate code, more code maintenance work. If it's just about great search algorithms, what makes ES better than an on-site Google search? Why are such on-site Google searches used so rarely, despite being free, available for many years and backed with powerful algorithms? How well does the current engine work with state-of-the-art Ajax callbacks? What about privacy? What about other search engines, like Brad, what makes ES better? Can ES searches be integrated into the page at page load time? With a native engine one can prepare search results even before sending the page. Can ES search results be reported back to the next page request? Like featuring products similar to the ones a user searched for before. Like showing a "you recently searched for ..." selection. Can page rendering take advantage of recent search results, like adjusting prices for often searched products or highlighting products which that particular user has searched before? That's all stuff which should probably find reasonably founded answers and weighting before jumping to conclusions on what works best for merchants and thirty bees. P.S.: what I mean here, if a concerted effort for a search engine/module happens, it's a good idea to not build a this generation search field, but to prepare a next generation search field.

“Instant” search results in 30bz using native db searching are too slow to be useful and really are just frustrating. [...] Besides being incredibly fast, Elasticsearch provides OK, you're an ES addict and don't even try to think about a great module without it.

Not front office, but anyways: review this large set of statistics modules. IIRC some of them require collecting traffic in the database, which virtually nobody turns on. Stuff like shown on the dashboard page is still interesting, no Google Analytics can show how many products were sold or how many purchases are waiting for being processed.

It's HTML. Font size isn't set by pixels, but by heading type. <h2> (2nd class heading) for large letters, <h5> (5th class heading) for small letters. If this still doesn't match your idea you have to edit front office (S)CSS. Leftmost of these editor buttons switches to a plain HTML view.

How can I reduce the font size of header tags in the descriptions? That's the HTML editor on the product page, right? This editor doesn't use Frontoffice CSS, so appearance can be quite different from what you can see on the actual FO page. That's why there's this "preview" eye to the right of the dog dress.

Can you me explain please that the function to export a language is for? It should be possible to export a language in the old version, hopefully including these messages stored in the database, and to import them elsewhere or in the new version. I didn't try this, but that's my understanding. BTW., these translation packs (en.gzip, fr.gzip, ...) are in .tar.gz format, despite their suffix. Plain files inside, so one can unpack a pair of them for comparison with a text diff tool (diff -uri or something). Could you please explain the difference between a language pack and a translation pack? A language pack (actually a single file) is what one can see behind this link: https://github.com/thirtybees/thirtybees/blob/1.0.x/install-dev/langs/de/language.xml. Language name, ISO code, date format, left-to-right or right-to-left, that's it. One such pack for every language. Translation packs contain many files with, well, translations.

Tight integration of external services is complicated. At least more complicated than using a local service. If this external service is faster than a local service, there's something wrong with the local service. Fixing that benefits not only searches, but all communications between shop and customer.

A few remarks from my developer view: These have to be done in thirty bees anyways or are part of native search already: Possibility to do: Ajaxsearch Normal search Instant search The possibility to completely disable the module and fall back to standard search during index updates Support indexation defined on cron Manual indexation fired in background with slow server timeout protection Indexation cron links ready to use with ‘Cron task manager’ Support auto indexation on product add/update/duplicate The ability to not index certain fields ElasticSearch log in all available log levels Filter by: Categories Features Manufacturer Ajax filter Price slider Filter on pages: Home Categories Manufacturer Supplier Special pages Best sales New Products Search pages Display selected filter with a ‘cancel’ button Possibility to hook the module to left, right en center Possibility to display the filter result in grid or list view Possibility to select infinite scroll These are easily doable with PHP/SQL onsite code: Possibility to: Search within word Select minimum word length Blacklisted words Combining searches (AND, OR, etc.) Indexing. Leaves these, which either require ElasticSearch or more advanced code: Field weight Seeing the long list of what a search provider does not provide, and the short list what it does provide, still can be done without a provider, I wonder whether it's a good idea to become dependent on such a provider. Maybe the list simply isn't complete, yet. In the earlier discussion response time was mentioned a few times. As far as I know (maybe I'm wrong on this), 30bz runs even Ajax requests through a pretty complex dispatcher, domain name verificator and a lot more. Part of the project work could be to simplify handling such requests, making them faster. As searches happen, a connection to the shop domain is already established, so chances are good it's actually faster than connecting to another server just for searches. So far my $0.02.

Actually I saw such questions coming, so I wrote an updater module over the last few weeks. This allows not only to update from version to version, but also to Git branches (where development happens) and every single Git commit. This way one can always stay up to date. Daily, if you wish. To not mess things up, it also allows rollbacks. Rollbacks restore the store to the previous state. The only thing currently holding me back from publishing this module is the lack of a thirty bees module store. Which means, I have to set up my own store, which takes a while (Germany with their Abmahnungen).

My take is that manually entered translations are stored in the database, so files on disk don't change at all. Accordingly there's nothing to merge. On the translations backoffice page is a function to export a language. Did you try with this? Also: you're talking about translation packages here. A language pack is rather small: https://github.com/thirtybees/thirtybees/blob/1.0.x/install-dev/langs/de/language.xml Admittedly, language and translation packages get confused often.

Another thing to keep in mind is that some markets, e.g. Switzerland, don't round to 0.01, but to 0.05: none 1.00 => 1.00 1.01 => 1.00 1.02 => 1.00 1.03 => 1.05 1.04 => 1.05 1.05 => 1.05 1.06 => 1.05 1.07 => 1.05 1.08 => 1.10 1.09 => 1.10 1.10 => 1.10