I have a couple of days to get as much done with a localization project as I can before I am off to a new position with a new employer.
We are working on having multiple store views based on locale/currency/(to a lesser extent)language.
We want users to be GeoIP redirected to the proper store view - IE - Australian-English-AUD, US-English-USD, UK-English-GBP, etc. For now, only English is supported, but ultimately this needs to support other languages.
We are working with the custom Acumen 1.2.8 theme from Themeforest, and it is highly customized. This is also Magento 1.6. Acumen 1.2.9 is the proper version to go with Magento 1.6, but the fellows who set these up didn't realize this, and upgrading now is probably going to be a bad idea.
I have managed to display different switchers in the site's header, but none of them work properly. The language switcher displays the proper store views, but is not redirecting properly (currency still shows as US, at least to me, maybe AU users will see AU currency).
All I need is the switcher to display and for it to redirect to the proper store view, taking precedence over any GeoIP redirects.
Any thoughts on this are greatly appreciated, as I'm a bit stuck and would prefer to get this at a point in the next two days where I can hand it off to someone else that can then complete it.
pspahn wrote:
My problem here was that in admin config, I had multiple allowed
currencies chosen for each store view. I changed each view to only
have the current currency as allowable and it started working
normally.
Related
I have a multi-tenant wagtail set up and we are currently working on getting up to date. We've just recently upgraded to v2.15 which introduced audit logging for all models instead of just page models.
AFAICT from looking through the wagtail code, the changes for a page model are only visible to superusers or admins with can_add_subpage or can_edit permissions which seems to effectively support multi-tenancy.
However, for all the other models there is no limitation put into effect. This means that an admin for Site A is seeing when changes are made to Site B or anytime a user is added or edited. We are using email addresses as usernames so this presents a rather major privacy issue.
This method hasn't been updated in any newer version, AFAICT, so I don't believe that just upgrading will fix this.
Does anyone have any ideas on either any wagtail settings we can change to keep Site and user changes invisible to non superusers or how we might localize BaseLogEntryManager.viewable_by_user so we can override the default wagtail implementation to our needs?
We have previously done something somewhat similar with the search available to admins by creating our own src/app/templates/wagtailadmin/pages/search.html and creating our own local version of https://github.com/wagtail/wagtail/blob/stable/2.13.x/wagtail/admin/views/pages/search.py
I had thought about trying to do something similar here however that doesn't seem like a good thing to do given how different those circumstances are and I think it was only possible using the register_admin_search_area hook.
I run a fairly large multitenanted Wagtail site. I have made public gist of the code we use in Wagtail 2.16 to restrict reports.
One of the main things we had to patch is the filters on the reports page. We do not want users on one site to even know there are other users in the system. This is implemented in the site_specific_get_users_for_filter method.
Although our non-page models all have site_ids, it was not possible to filter ModelLogEntries in site, so we settled for hiding that report from everyone except superusers.
I am new to this software. I was just wondering how to create/edit/check header, side, and footer link. What I have noticed so far from numerous searches is that it requires some type of actual manual programming. And also if it is not a template, I would have to add it through Static Blocks or Edit it through a .phtml/.php/.xml file which I have no idea to do. Assume I have the latest software. Any help is appreciated.
You can create a shop in english without manual coding at all. But you will get the result you asked for. A hard application without any customisations which probably will not be valid IRS-wise(for example, the invoices in Greece have to contain very specific things. If not they are not valid and you get fined.). The header and the footer are customised by Static Blocks from the backend of Magento without trouble. You will have to search for a documentation of your template ofcourse. There are so many information and we cannot give it to you with just one post. You will have to study and ask the right questions!
I need to be able to serve different versions of my whole site per client. Certainly beta vs production but it would be nice to serve one or two prior production versions. Client customization is encouraged and I don't wish to force all clients to follow the (anticipated) pace of development.
Which version to serve is stored in the db.
From what Ive read so far a custom view engine may be the most straightforward way to accomplish this but before heading down this road I would welcome any advice and comment.
Thanks for insight!
Eric
EDIT: It isn't just the views that are different; controllers, master pages, images, CSS...
If the rules regarding which version is displayed to which user, I'm guessing they need to authenticate first. If that's the case you'll have opportunity to set a cookie on the user.
I would probably set a cookie on authentication that determines which version to show the user and then use a URL Rewriter like IIRF to direct requests with that cookie set to the beta version of the site.
Has the added benefit of users being able to opt back to the production site if they have issues with the beta.
I went down the view engine route How do I implement a custom RazorViewEngine to find views in non-standard locations?
Basically it's pretty stright forward, we have the same controllers models, etc. All the code is shared. The rendering of the views though is based on a "brand". So the view engine is clever enough to say if I'm brand A then the view will live in {standard view location}/brand/viewname.
It's hierachical though so if the view is in the branded folder it uses that one, else it falls back to the default location. It's basically an extension of the standard model used by MVC to find the location of the view source.
Is there any tutorial available for how do i add custom fields on front end check out step like PO number,Job name , customer comments etc as well as in admin->create->order.
My usual motto is to find (and buy if needed) a module that already has the functionality you seek. Especially when the life of this project involves version upgrades because then you can seek a pre-packaged solution from the provider.
I regret every bit of custom code I have added to our Magento install. Because now I've got to maintain the site to just keep working in addition to figuring out my hacks. Time to devote more time to replacing hacks with off-the-shelf extensions, which would have been much faster in the first place.
I know this attitude goes somewhat against the stack overflow thinking of I can do anything, but really, Magento's job is to enable someone to do less work.
Two years later, an update: after the gentle poke of a downvote (probably for appearing to shrug off the question), I am back to revisit and share some of what I've learned. The programming aspect of additional fields is the concept of persistence of the data.
If you're ok with the custom fields only appearing in the transactional emails following the order, then the task is as "simple" as adding the fields to the form somewhere and then updating the controller to to catch and insert the post data into the email. You can use a custom variable in the back end to readily expose this to the email templates. And a Magento SE on programatically creating a custom variable.
Getting persistence into the back end requires adding database fields via an installer in your module. The iCoreThink blog lays out the steps clearly and explains why, how to confirm your work, and then provides real-world implementation, like displaying to the customer in their account. The "other blog" mentioned below has a great example of this, though his example is specifically related to billing and shipping.
Resources from my upvotes and bookmarks:
» This iCoreThink blog post is my favorite reference so far and what I'm following now.
» I was using Templates Master's FireCheckout which includes their own checkoutfields module, but I've abandoned their single view checkout for the flow of Magento's one page checkout. I'm now trying to adapt their checkout fields (and use their controller) into my template for checkout.
» I thought for sure Alan Storm wrote an article about Checkout custom fields, but I don't see one.
» This Magento SE lists a couple blogs and a paid extension. The excellence blog is ok, but his style is too rote for me and I don't learn anything. The other blog discusses the procedure for building your module and installing the database fields.
» The unexpected-IT blog demonstrates and informal hack to add the code to core files (but sadly doesn't show how to override those files by copying them to app/code/local) and the steps to manually perform to get the column and fields added in the database. Apparently is perfect for 1.4 and below, but comments seem to explain what to do for 1.5 and up.
This last hack-ish change is my personal favorite as it seamlessly adds the extra bits into existing Magento admin pages and "feels like" less work. Caveats: I wouldn't do this without using version control and it will absolutely break if any core code changes happen between version upgrades.
i'm in the process of adding a US site to my current UK site. I'd like to do this as transaprently as possible so that we don't lose any traffic to existing links. We're currently running this under version 1.4.1.1 of Magento on a shared hosting setup.
The new website (US) will be essentially the same as the current (UK) site, but with US Dollar pricing instead of Pound Sterling.
We currently have a GeoIP setup whereby visitors are redirected to either UK or US site whilst utulising the same URL. This essentially means that we have switch statements in our index.php to indicate what run code to use.
Here's my question:
what's the best way of selecting/overriding the GeoIP selection via the standard store switcher selector dropbox? Both websites are being populated in the dropbox, however, since both are utilising the same URL (www.example.com/boutique) the default one is the only one that's being selected.
I've also tried the &_store= as well as the &_website= arguments with no success.
Any ideas? are URL rewrites in .htaccess the answer? if so, any ideas as what to use?
P.S. this is the method that's pretty much being followed however my aim is to let users override their location-specific website (e.g. US) if necessary:http://www.magentocommerce.com/wiki/4_-_themes_and_template_customization/navigation/multiple-website-setup#multiple_website_setup_for_useuuk_storespricing
Have you tried using a getUrl() method to build the store arguments for you? It can help clear up those little misunderstandings, for example I'm pretty sure the store parameter is supposed to have three underscores but cannot really remember so I use the function instead.
The best way to over-ride is to have a little php program, e.g. 'countries.php' that sets a cookie depending on the country code that you choose or 'auto' to test regular geoip. Then in your index.php have an 'if cookie then use cookie code else use geoip code'. Naturally the cookie can only be set by your test program.
And yes, you only need set 'website' not 'store'. There is no benefit in your US customers being able to see your UK prices (and vice-versa) so don't even bother with setting up a frontend drop-down. Or, if you really want, you can have rest-of-the-world customers choose their currency/website and put your own cookie-setting code in the header for them, with a couple of nice flag icons.