Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

Traumflug

Administrators
  • Content Count

    1,524
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by Traumflug

  1. I'd favor good copy&paste support. These tiny fields aren't ideal for writing serious amounts of HTML anyways.
  2. There's a context menu? Surprise, surprise!
  3. i just need to find out how it works Modules come with their own templates, CSS and JS files. To override them, place like-named files in themes/mytheme/modules, themes/mytheme/css/modules and themes/mytheme/js/modules. Plenty of examples coming with the default theme.
  4. Here we go: https://github.com/thirtybees/thirtybees/issues/285
  5. Another one: having these shortened tags shown as separate tags on the backoffice product page is a hoax, obviously created by JavaScript. Looking into Backoffice -> Catalog -> Tags reveals them as a single tag with commas inside.
  6. The question is how to create a multiple value field and whether/which spreadsheets can do this at all. :-) Right now I'm reworking tag import a bit to recognize a single string with comma separated values, too. I think it's best to allow the same type of entry as when adding tags manually.
  7. P.S.: Found my mistake, I tried to import categories, which have no tags. Trying to import products had tags, then. And the result is: tag imports worked with the modifications guessed above, at least for the one product I tried:
  8. P.S.: the Categories column in this CSV file separates multi-value fields correctly.
  9. Now I actually tried with the CSV above and see, uhm, there is no way to import tags: Twelve fields, none of them for tags. About field separators. CSV means "comma separated values" and that pretty much explains what's expected. Nevertheless 30bz has ; set as default field separator. As far as I can see, one should change this to , and multiple value separator to ;. This matches the given CSV file, then. Now, this CSV has such a multi-value field for tags. But instead of using ;, it puts all tags into one long string. This explains why it's knocked off at 32 characters. For the fix I have to guess a bit (can't test, see above): the field with tags should change from "dog collars, collar charms, charm for collars, patron saint of all animals, St. Francis" to dog collars; collar charms; charm for collars; patron saint of all animals; St. Francis See the quotes removed and , replaced by ;? That's the point. About how to fix this in the spreadsheet. Obviously it's a good idea to set ; as field separator for CSV export to match 30bz' default. That's probably the better choice for languages with , as decimal separator anyways. On how to generate multi-fields in a spreadsheet? No idea. Didn't know spreadsheets actually allow to do this and a quick google brings nothing like this up. Which raises the question: how did the PrestaShop guys expect this to work?
  10. When I edit a file using cpanel I rename with an x in front of the original name Didn't think about adding something in front. I'd also change the suffix, at least for PHP files. There's an autoloader which picks up everything having a .php suffix so keeping the suffix might end up in duplicate code. As a non coder this works for me! Excellent! I’d love to learn better ways though! Even better? Make this whole shop installation a Git repository. Then you can apply patches even without editor and roll back and forth such changes in seconds. If you manage to do this as well, you're no longer a non coder :-) When maintaining servers (general ones, not shop installations), adding the date as suffix has served me pretty well, though.
  11. 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.
  12. @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!
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. @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 :-)
  21. @alwayspaws, perhaps you should provide some of your CSVs for demonstration the problem. The shorter, the better, as long as the problem shows up.
  22. 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.
  23. 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!
  24. 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.
  25. 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.
×
×
  • Create New...