I'm migrating a working module from ThirtyBees to Prestashop 1.7.6.8 - the purpose of the module is to display selected categories on Manufacturer pages.
The problem is, I cannot seem to get the grasp of the new SearchQuery mechanism. It seems like a great upgrade but ....
I can specify 1 category by using:
$query->setIdCategory($category_id);
Query being of type ProductSearchQuery
Is there an example somewhere on how to combine Queries?
(In the working module, I just do a id_category IN (2,4,6) for instance
Related
So I am modifying a module and I've successfully queried the product ID. So if I am browsing products and go into the product details page, I can see my product ID using
JRequest::getInt('product_id');
but for some reason I cannot get the category ID. I've tried.
JRequest::getInt('category_id');
and it always comes out to zero no matter what category I go to. Anyone else experience this? I could get it from the nonSEF url but there's gotta be another way. My goal is to basically query the category ID when I am browsing that category or if I am in the product details of a product.
I assume, you're using some OpenCart component for Joomla. In this case, you have to look into controller and model files for OpenCart. It's not THAT easy to get certain values sometimes, because these are 2 different engines.
In short, you may have to use VQMod for OpenCart, add category_id to data array and only then JRequest it. Solely depends on task.
I used MVC before. Now I am a learning HMVC.
I have product, product_category, product_description and product_images tables in my database.
I want to display list of products in my website with basic product information. Clicking on a product will redirect to a different page and will display all the product related information.
What is the best way to achieve this according to HMVC(Modular MVC) pattern?
Should I create different modules for each table like product module, product category module etc..?(In this case I will have one model class in each module/model. I found this idea when searching internet)
Should I create one module called products and put all the files related to this in that module? (In this case I will be having all the product, product_category, product_description product_images model classes under products/models)
Should I follow a completely different implementation from the techniques I've mentioned above? (Please provide specific details to build this module)
(I'm using codeignitor for my development)
Thanks a lot!
Lets simplify the things for you.
If you have category as menu (Same as magento), i will recommend you to create new module for cateogry
Coming back to product, you can manage all things with the 1 product controller.
In category, category will have its own model to interact with database.
In your product model, you can manage all kind of transactions in one model because they are part of product only.
If you want to move bit advance, you can have a sql folder in each module so that you can install the and create tables when you just drop folder to modules. For this you can create a small script where, in regular interval of time, it will check the new modules, and if that script found some new modules, it will install the .sql file in the sql folder, which will update the database schema.
Hope this will help you
really could do with your expert advice / knowledge & help...
We have a client who we built a magento site for. He sells parts for motorbikes, jet-skis, motocross etc..
We set up three attributes "Manufacturer" then "Model" then "Year" - and this was the selection process inside each product to drill down a price (as price changes on the models year) to achieve the pricing structure he wanted we used a simpler config products plugin that worked a charm. (which I found searching through these forums)
Problem.. The "Model" attribute is getting way too big (crashing the browser and timing out - and approaching what I have been told is the limit for attributes) so we have to rethink the logic (as last resort is to change the whole site and add them all as simple products and use filters instead - which the client does not want)
After days fo stress and researching we are still none the wiser...
one idea would be to split the model attribute into manufacturer.. so "Hond_Model" .. "Aprilla_Model" and so on.. but then we cant keep the structure of one product with all the options inside, be great of we could have inside the product (front end)
select honda model
select aprilla model
select Can Am Model
Year
but the user can choose one model from any three of the "model" drop downs, then it blanks out the other 2 model attributes and lets the user select the year to get a price.
But in the back end when I try this all three "Model" attributes have a red asterix and require an input in all three..
HELP!
Sorry if some of this is basic I am a designer who is learning magento with the help of my developer for the past 6 months so still new to this but already way out of my depth.
Any help would be so appreciated.
Given the level of complexity, the relative newness of your company with Magento, and particulars of the automotive fitment domain, it might be wise to buy an existing fitment module (e.g. Year Make Model Extension - not an endorsement - i have no firsthand knowledge of this extension) to bootstrap your development or to learn from. You should check with module vendor first to make sure that the code is suitable for this purpose (not obfuscated / encrypted, written using Magento conventions).
There are several approaches which can be taken depending on how frontend presentation and backend reporting should work, but these are too broad to be discussed here.
there are some default attributes in reviews and rating section, they are Product,Posted By,Summary Rating,Detailed Rating,Status,Nickname,Summary of Review and Review. now i want to add one more attibute named "selected size", how can i finish that ?
Reviews are not EAV entities. So extending this is somewhat easier.
1) You can add a new field in the review_detail table and extend the module to also save this new field. You will not need to do too much work at the module level (mostly the effort is to display this new field in new review form and related views).
2) You can create a new table (don't alter Magento's core db Tables) with a reference to Review (review_id) and your custom field. This also means to extend Review model's and use afterSave, afterLoad functions to save/retrieve your data...
3) Duplicate entire module logic with custom tables (I've seem some more than a few commercial extensions that have this approach to do stuff with reviews, inventory and so on). Not recommended.
you should create a module with a sql upgrade script. it's covered in tutorials by alan storm and in the database section of the videos series provided by magento, available in your account section of their site. these 2 resources both cover the rest of the skills you'll need to finish your work in accordance with magento programming practices.
In Magento 1.x review attributes are managed under >Catalog > Ratings > Manage Ratings.
In Magento 2.x they they are managed under Stores > Atrributes > Ratings.
There you will be able to add, edit or remove review attributes such Price, Quality, Value, etc.
I'm trying to develop a Magento plugin which involves using coupons. Apparently after looking around I found a source that mentions use of a 'salesrule' table for coupons. However when I looked at my database i couldn't find it. However I did find 3 tables that had mention 'coupon' called 'coupon_aggregated', 'coupon_aggregated_order', and 'coupon_aggregated_updated'.
I just wanted to know what is the difference between the 3 tables so I can start using them? I am on the latest version of Magento.
The table you're looking for is indeed named
salesrule
There's also a table named salesrule_coupon, which contains specific coupon codes linked back to the main salesrule definition.
If your database is missing this table, something bad has happened to your system. Go to
Promotions -> Shopping Cart Price Rules
and create a new coupon code with a distinct title. Then dump your database content and search for the text of your distinct title. That will let you know which table your system is storing salesrules in.
The tables you mentioned above are aggregate data tables used for reporting only.