I have been working my way into Magento2 for quite some time. From time to time I find new URLs by accident - mostly when I Google for a function or feature.
So that I don't forget to style anything in a new store or also to test functions I would like to have an overview of all automatically created pages which can't be maintained in the backend.
As examples these URLs would be here:
/sales/guest/form
/contact
...
Should the whole be version dependent gladly from 2.4.0 and upwards
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 trying to figure out in which file I need to add the Google remarketing tag. I know it needs to be added before the closing of the body tag. Can anyone point me in the right direction?
Thanks
here is I did in the past:
Depending on what kind of google tracking you are using you have a few different way to use:
1) If only add a custom code and should be in all the Magento page, use the "Miscellaneous Scripts" value going to admin section, System > Configuration > Design > HTML Head - Miscellaneous Scripts. (This will be included before head closing tag in page HTML.)
2) By native Magento already have Google Analytics tracking code and you can find this configuration going to admin section System > Configuration > Google API - Google Analytics.
3) If you are looking something more complex and use the Google adWords I used the extension magento connect link. For a particular Client I did some extra modification to include some extra code if a client subscribe to newsletter or a new client etc.
I hope you can find something helpfully in the post.
Best,
GrinGo.
There are different template file for different pages in magento so at first I think you should decide where to place it.For example if you want to place it in footer than you should place that code snippet in
"app/design/frontend/base/default/page/html/footer.phtml"
Similarly you can check other different template files to place your code.
NB:Best practice is to overide the core file of magento before making changes to it.
Hope this will help.
There's no indication as to which Magento version you're using 1 or 2. At the end of the day it depends how much technical knowledge you have and if you're using a version control system to manage your Magento build.
Miscellaneous Scripts as another answer mentioned earlier, this approach is straight forward and very easy to use to plug and play your code.
Google Module depending which version of Magento you use (CE/EE) there will be a built-in section for you to plugin your account ID in backend Magento configuration and then the platform will generate necessary code for you.
Write custom module by writing your own module you can place it the snippet anywhere on the page by targeting before_body_end node in your layout XML file. This is more technical but gives you more control over what you can do.
Google Tag Manager this also depends on if your Magento version comes pre-built with Google Tag Manager module, then you can create a container and place all your logic in there. This is also more technical and require the output of some values in JS format on the frontend to let GTM read the values.
At the end of the day go with what is easy to setup, portable and easy to manage. I usually go with Google Tag Manager as it takes time to create initial setup of exposing data on the frontend but then I have full control of what I want to do with that data through tag manager. In most cases you'll end up using the same data (ex. totals, shipping method, product IDs, SKUs, cost, etc.) in more than one third party API so this gives you flexibility to do just that.
How are people managing multiple API versions with API Blueprint?
It doesn't seem that the format supports version sections within a single file, so I'm left thinking that multiple files with indicators in the filename are the best option.
We want to leverage the tools to create a central mock-server and doc commons, and will need to handle evolving multiple versions of each API.
Managing multiple versions via branches seems inconvenient for us, so we render the entire document with multiple versions of APIs in one page. Our users need to be able to read both versions by just prepending v1 or v2 in front of the URL. So, we have a node app that handles the documentation requests and renders the doc via aglio node module.
The following is how we organize the docs.
Users can request /docs/en/spec.
The en part determines the language of the document as we support different languages.
Because the entire document is pretty huge we split it into files based on the Blueprint Group (the thing that starts with # Group GroupName)
When a request comes in, we first look if we have previously compiled the doc and have a cached version, so we don't recompile every time (it's pretty intensive work especially when the doc is large).
If we have no cached version, we read all *.md files in the docs/en directory.
Sort the filenames alphabetically, concat their contents, and pass to aglio which produces a nice html content. We cache this content into a file and later pipe it to the client on each request.
The UI provides the table of contents (side menu on the left) which has, for instance, the following format.
Auth
Projects
Project Users
...
Groups
Groups v2
Now each Group of APIs has a distinct URL which is prepended with /v1 by default. When we introduce a new version of a specific API, we create a new # Group Groups v2 which is prepended with /v2. This way our users can see and choose multiple versions of the APIs in one page.
The nice things about the aglio node module is that it provide multiple themes for the UI which provides a nice navigation so that our users don't feel the page is too overloaded. Among the themes you can choose either single-page UI or multi-page UI where on selection of the API the page with the corresponding API is loaded and the URL is changed.
Implementing this logic is very simple. Hope this helps.
There is another idea which we are considering right now but haven't started just yet. It is to avoid splitting APIs into different # Groups and instead modify the Jade template used by aglio and make sure it supports multiple versions out of the box.
It might be best to version the blueprint file in a versioning repository and treat different branches as different API versions. You can even have the blueprint in the same repo/branch as the API server implementation.
If you're versioning using GitHub, Apiary can connect to GitHub and you can setup different branches to be picked up by different documentations in Apiary.
DocPad is described as being comparable to other static site generators, but it is also described as being "not limited to static site generation".
I've been browsing the DocPad website and other documentation and haven't yet been able to find anything that seems to explain how to incorporate dynamic content, and what types of limitations may be involved?
As a relative beginner, I am wondering if anyone can help me better understand the methodology whereby dynamic content would be incorporated into DocPad...? e.g. AJAX, and dynamic server-side scripts for doing things like dynamically loading pictures from Flickr into a webpage when a certain tag is clicked...
Thanks.
So there's a few ways DocPad facilitates dynamic content:
Via the regenerateEvery configuration option. This will regenerate your website every so often you specify. This great when combined with plugins like feedr for pulling in data from remote feed sources (like your latest social activity), as well as repocloner which clones out and keeps a git repository up to date inside your project. The benefit of this option is it's really easy to do and provides the illusion of a dynamic website. For instance the Benjamin Lupton Website applies this method to keep it's statistics on the home page, as well as the social data in the sidebar up to date. Every hour it regenerates with the latest information. Making it fast, and also illusively dynamic.
Via the dynamic meta-data property. When set to to true this tells the DocPad server we should re-render that document on each request, rather than just once. This works great inside the Kitchensink Skeleton for search pages and misc forms. This way is most similar to PHP development.
Via the serverExtend event. This event allows you to hook into and extend the DocPad server, allowing you to add extra server-side logic, handling, etc. Common use cases is to add extra routing to your server to handle route aliases, adding form processing such as a contact form, or to add a RESTULful interface for a Backbone.js application. The DocPad Website uses this to add extra routing and a regenerate post-receive hook for the documentation. The NodeChat Skeleton uses this to add the Socket.io server-side logic.
Via the API. This way is the most involved but can be quite rewarding if you just wish for DocPad to be a small part of an existing node.js application. With this, you can create a DocPad instance in your code and interact with it. The grunt-docs grunt task utilises this :)
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.