For a marketplace, schema data becomes more confusing. Not only will you want to represent your organization, but you also have the supplier's organization to worry about. Is it bad practice to have all of this data on one page? Should the product page only have product information in the metadata, and the local business only have local business details on it?
Marketplace Org
logo
name
description
LocalBusiness Org
logo
name
description
address
lat/long
product
description
rating
price
I can provide html for all of this, but I am not sure this needs it to explain. I read the schema docs pretty in-depth but it doesn't have great examples of what a marketplace site would do with multiple organizations or what Google will think of it. For instance, if there is a localbusiness with many products, is it proper to have an aggregate rating on the localbusiness page of all of their products combined into one rating?
Is it bad practice to have all of this data on one page?
No. The more the better! (Of course it may be the case that some consumers only like to work with a single item per page, but when it comes to this topic, anything might be possible. So when you are interested in a particular consumer, you should consult their documentation.)
Every itemscope creates a new item. Every item on a page is (… should be) about something different.
So don’t create several items for the same thing on the same page (unless you can use itemid so that it’s clear that the items are about the same thing).
If possible, use properties to relate the items.
For example, LocalBusiness has the property makesOffer to point "to products or services offered by the organization" (i.e., Offer), or the property owns for products "owned by the organization" (i.e., Product).
You can associate a Product via brand or manufacturer with an Organization (resp. LocalBusiness).
Related
We have requirement to handle price dynamic (referring external system).
We would like to know, what is the best way to handle dynamic pricing among below :
Approach 1 :
Creating Price factory extension and overriding getBasePrice() method of customPricefactoryManager. Please confirm if it uses jalo layer.
Approach 2 :
In DefaultSLFindPriceStrategy we can customize getBasePrice() method.
If any other way too, please lets know.
We would like to know which approach can help to handle prices in addtocart operation, checkout and product page details pricing.
It is not good getting price in another system with integration online. ERP system used by few sales people but ecommerce site can be used by hundred customer in same time. ERP cannot be handle huge amount of connections. I prefer pushing price from ERP not pulling them from hybris side. On the other hand customer will be hate changing price while surfing between hybris pages. You need to plan correct time for updating price and re-calculating existing carts.
It is highly unlikely that you would need to override the above classes to get dynamic prices.
Hybris already provides OTB functionality to get prices for different-
Users
User groups
Currencies
Time range
If you are trying to get different prices based on above criterions then you can simply use the OTB price row model.Getting dynamic prices on different pages has many caveats-
The price on different pages i.e. Homepage, PDP, Cart, Checkout,
etc. might show different values confusing the customer.
It cannot
be indexed so the PLP page will almost always show a different price
value.
Here's the setup (using a made-up scenario), but applicable to my real situation:
For the purposes of this explanation, let's say that i design T-shirts (Let's call them ShirtA, shirtB, shirtC). Rather than selling them myself, i have several vendors that sell the product for me (we'll call them Vendors X, Y, and Z).
I have a table in my Joomla database for the vendors, and a table for the t-shirts.
When customers are buying from this vendor, they will visit my site and based on the ID url variable, will display a different vendor's page.
Each vendor can choose to sell all of my t-shirts, or only some of them. Additionally, the vendor can override the price that i have set in the t-shirt table, with their own.
In the admin section of the component, each vendor needs to be able to select which t-shirt they want to sell, and provide an optional price override.
This is how i imagine it looking...
Each vendor will have a column in their table that will contain the serialized data of a multidimensional array. The main array contains a sub-array for each t-shirt that i have in my t-shirt table. Each of those sub-arrays contains all of the override data (price, sizes offered, etc..).
How would i write the model, view, and/or edit page in a Joomla 2.5 component so that a vendor can select all of the options in the component admin page, and have it serialized in a column?
I am sorry if this is poorly explained and PLEASE PLEASE PLEASE don't hesitate to ask if you need further information in order to assist me.
Thanks!
I hate to say it, but I don't think that there is a "standard" method to do this in Joomla 2.5. Joomla has all kinds of ways to interact with the database and use their standard classes, but none of the classes are designed to work with serialized data to the best of my knowledge, so you would be stuck building all of the pieces by hand.
That being said, in general the model, should handle retrieving and storing the serialized data, the view would request any data in the database from the model, and the edit page should unserialize the data and display it in a way that your vendors can add their overrides. Beyond that it would be up to you to code each piece in your own way.
We are trying to do something interesting but challenging:
We have a couple thousand products listed on our B2C site (non-Magento), & are considering moving the site to Magento for a variety of reasons. The product pages provide detailed information about these products. Our user base would now like us to provide local information about retail stores where they can buy these products; the information required would be Retail outlet name, address, zip, phone, & a Google-map display (this last is optional).
In the front-end, each product detail page will display relevant retailers depending on the product AS WELL AS depending on the user's zip. Each user will see upto 5 nearby retailers.
My question is: how best can we set up this in Magento so that we can:
map products to retail_outlets, the way magento allows for mapping of products to categories. Products & outlets will have a many-to-many relationship, & we are looking for something that will be easy to maintain.
Map user's zips to the retailer info.
We are open to using magento 1.7, if that is a better fit.
Thanks in advance.
-TM
This is not the right place for this question as it is not related to programming and does not have code samples and is too general :( read the FAQ please
but in general you need:
add a product attribute (multiselect) with all your retail_outlets and add a possible retailers to a product
ask user to input a zip if he has not jet . you can get this from quote->getShippingAddress()->getPostcode(); if your user is
registered or something
on detail page query out your retailers by zip. This will need you to implement Geo/Spatial Search with MySQL.
I am French, and I am developing a rental vacancies website. I would like add microdata on the rental vacancy offers (house, villa, appartment...), but I don't know which itemtype to use. Offer, Product, or an other?
http://schema.org/Offer
http://schema.org/Product
Thanks for your help.
There are several relevant schemas that apply, and you will be best off using a combination of them to represent your Offers. The Offer should be your root element, because it represents something that ican be purchased for a price. The itemOffered property has the Product type, so it is the logical extension point for embedding product content. Think of the Offer as your sales pitch and the Product as what you are actually selling. There is a metadata schema for Residences which include information about the domain of your Products. You could combine this with the Product itemscope or nest it within the Product (possibly via the model property).
Metadata from the GoodRelations schema can be used to extend schema.org's limited Product vocabulary as well.
I also see an opportunity for leveraging the Review schema (for any reviews in the corresponding Product property), and potentially TouristAttraction, if the rental's proximity to tourist attraction is a selling point. I also noticed that there is a LodgingBusiness schema that inherits from Organization. This should be used to encapsulate content about your actual client (or whoever rents out the apartments/villas to renters).
Use the new version of schema.org (0.99) with the following properties for the http://schema.org/Offer:
businessFunction; use http://purl.org/goodrelations/v1#LeaseOut as the value.
eligibleDuration: The duration for which the given offer is valid.
availabilityStarts: The beginning of the availability of the rental object.
availabilityEnds: The end of the availability of the rental object
If you need detailed patterns, please contact me via http://www.heppresearch.com/contact. We built the new e-commerce module for schema.org.
ok... so I feel really stupid asking this question.. but just wondering about the Allow Countries drop down in the admin panel..
What exactly does this mean?
Does it mean that only certain countries are allowed to purchase from your site? if it does mean that how does it determine where you are shopping from? is it done using a IP Geo locator or is it determined when the user inputs their address on the checkout page?
or does it mean that only customers from certain countries have access to the site?
Regards,
Fiona
I believe it's a list of countries you are willing to ship to. Here's a reference that says this. The available list seems to be limited by locale, so no geolocating involved. No idea why this is done though.
The reason for this feature is so that you can use one Magento website to serve multiple countries with different prices or products. Say you have a German and an English store. You may have different prices and you don't want someone from Germany going to the English store and ordering a product which is not available for Germany or is at a reduced price.