Jump to content

EnigmaPsi

Members
  • Posts

    4
  • Joined

  • Last visited

EnigmaPsi's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. As far as I know, user amwdesign is working on an advanced CMS module, that he says it will be released this year. Just a little bit of patience is needed, I suppose (and hope )
  2. Thanks for your invitation, mr. amwdesign. I enterd skype quite late, and seemed you logged out by then. Maybe tomorrow...
  3. Indeed, you don't need to search for an item in a category with, let's say, 10 items. But when you have, for example, 100 types of items (we have this on our shop - over 100 UPS-es and UPS related products), no one will look for it by reading the specs, they would rather filter this big result. For the moment, because the lack of this feature, Prestashop is suited to shops with categories with not very many products (I would say 10, maybe 15 is a maximum a potential buyer will tolerate without filters).
  4. Well, configuring this in the module configuration doesn't seem such a good idea to me. The filters should be category-specific, not sitewide. A short example: for "Laptops" category we can filter after RAM size, but this is irrelevant for "Monitors" category. If we configure filters in the module "configure", RAM size will appear regardless of category (this is, for any product). At least this is what I understood from your approach, please correct me if I miss anything. I suppose that by "databases" you meant tables. It is a good suggestion, but new problems would arise: aggregated data should be updated every time a product is added, and doing this means I should also alter "add product" function(s). After all, making a new table from 5 or 6 is not such a difficult task (powered by JOIN ). Also, the location of this widget is not a primary concern, as far as I could see, a block can be placed anywhere on the page (left, right, etc.). This should be configurable (native, if the module is written correctly). I would place it on the product page because it is category-specific but, again, this is not mandatory. Thank you for your answers.
  5. I have seen a lot of topics on the forum about this basic capability that Prestashop lacks, and I decided it could be a good idea I write a module for this, until the dev team decides to build the func into the core, maybe, or come with it's own module. The only problem is that I can't seem to find a module HowTo. What should this module do? It should allow filtering products based on owner-specified criteria (this is, only display the products that match, not sort them). See Magento Layered Navigation. This criteria should be defined on a per-category basis. Moreover, products in any category should be able to be filtered by manufacturer. E.g.: We have a "Laptops" category. When we click on it, we see all the laptops our shop has, and can sort them (at this time) based on different criteria: price, name (A-Z), etc. Well, if we have, let's say, 200 laptop models, no one will browse pages to find one that's in the middle of the list. So, the first step in the shopper filtering process would be to select a manufacturer. This filter could be invariable (i.e. category-independent, hardcoded). Next, we will select a processor type, a monitor width and so one. These parameters should be defined in the backoffice, based on existing attributes and be category-dependent. Another type of filter should be a price-range, also category-based and also defined in the backoffice. In the front-office, a set of SELECT boxes should appear somewhere (e.g. near "sort by" box), having a label named after the attribute name (e.g. "Manufacturer", "Processor type") and values - the DISTINCT values in the DB for that attribute ("Manufacturer" should contain all distinct manufacturers in that category). Of course, the presentation could be different (for example a left-block), but you get the idea. When selecting any of those values, we should see only the products that match, in that category (and the value should remain selected in the box). Also, the filters have to be cumulative. Appearance Back office: each category (and subcategory) should have options to configure filter attributes and a price-range (add, edit, delete). Front office: the filters should be placed somewhere on the page (left block, near "sort by" field, etc.) ----------------------------------------------- This is not a feature request. I'm interested in programming this module, but I need some guidelines for that: 1. Where to hoook this module ("Extra action on the product page" - is it a good position?) 2. What DB tables are involved 3. Any other interesting info. If any developer or PS [spam-filter] out there could provide any information, I'm glad to hear it, and thanks in advance. If this capability is being implemented right now (this is, you work on it, not planning), just let me know. This is the only and only missing (basic) feature that stops my company to swith to prestashop from ZenCart. And it's not only our case. Thank you.
  6. I subscribe to this. Any e-shop I have seen has this option - even ZenCart. This means, you should be able to sort by (or filter by) ATTRIBUTES, supplier and maybe features. Maybe a module can be done, (is there a hook available?).
  7. Right! This is a valid question. Suppliers should only be used in the back office, and maybe to update information directly from them, in the DB (like stock, prices, etc). Is there any way to make them invisible in the frontend? Thanks
  8. Well, it seems that Romanian translations are quite outdated or a little bit too personalized - not to say spamy (see the above link for details - I've found a few links to adult-shop[dot]ro in the error messages, for example). I am implementing this e-shop now for the company I work in and they are very strict about Romanian grammar rules and diacritics. This is, the translation is going to be very accurate. It'll take a few days to finish and review everything for v 1.0. For every stable release, the translation files will be updated in no-time. I'll come back with details, such as the download link. For developers: how can we know which version to translate, in order to perfectly merge the latest stable version before it is released? (e.g. what should we translate to fit version 1.1? 1.1 beta or better wait for a Release Candidate?) Thank you.
  9. Well, I don't know if you have solved your problem, but in case you dind't, here's what you need to do: 1. Request a unique IP from your hosting provider. That is, a dedicated IP. SSL on Apache does not work with shared IPs. 2. You need to generate a private Key (if the host runs CPanel- very common nowadays) this is very simple - just fill your information there (see SSL manager). Otherwise, search on google on how to generate it. You should avoid public online tools that do this. Take care to generate the key with your exact domain name (that will be used on your e-store). Kepp this key private - do not ever share it to anyone. 3. You need to generate (based on your key) a certificate signing request (CSR). This is easily done from CPanel interface, but there are other ways to generate it if this is not available. Just check Linux openssl docs. 4. Buy a SSL certificate. There are very cheap providers nowadays - the cheapest ones are about 19$ or so per year. Take care that, if you buy from cheap providers, you need to do more work - you need to install what is called a certificate chain together with your own cert (providers give you information about this on their website once you bought a cert). Try to buy your cert from a Root Certificate Authority, even if they are a little bit more expensive. The SSL certificate is generated based on the CSR generated above (see pt. 3). 5. Install the SSL cert. In CPanel, this is easily done, from SSL manager. Otherwise, the host might install it for you (they usually do this, in order for users not to mess up their servers). Manual instalation means editing your Apache vhost configuration file. Keep the key, as you will need it in order for the cert to work. A final note about certs: cheap certs are only useful to secure your connection (through SSL/TLS) and certify that the cert matches for your domain. More expensive certs ($500 or so) certify that the domain really belongs to your company - you need to mail documents to the provider to certify this, and they will check if you really have a legal entity that bought the domain. Hope this is usefull.
×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More