I am working on a Magento 2 project and have been having trouble saving category descriptions.
In the Catalog Save controller action (Magento\Catalog\Controller\Adminhtml\Category\Save), I was logging the request parameters:
$this->getRequest()->getParams()
On most categories all of the request parameters would come through, but certain ones would completely ignore the POST parameters.
After playing around with the description value being posted, I noticed that the request would not come through when my text had an instance of the text select followed later by an instance of from.
My text was something like the following:
"We carry a selection of knives from satin to mirror finish"
I checked the modsecurity logs. It had filtering the requests, mistaking them as SQL injections.
To fix the issue, we add configuration to remove the ModSecurity rules for our specific domains with:
<LocationMatch .*>
SecRuleRemoveById 950004
</LocationMatch>
More on removing ModSecurity rules:
http://www.inmotionhosting.com/support/website/modsecurity/find-and-disable-specific-modsecurity-rules
Related
I'm working with Cloudflare and one of its benefits is caching. There are certain areas of my site that shouldn't be cached as the results need to be seen by the user. I run an online store and images for products are stored in directories which are also designated by the product Id, this means there are quite a few directories and I don't want the images to be cached.
Here are a few example URLs of product images on my website.
www.mysite.co.uk/images/products/87/image300.jpg
www.mysite.co.uk/images/products/88/image300.jpg
www.mysite.co.uk/images/products/94/image300.jpg
www.mysite.co.uk/images/products/27/image300.jpg
To get around the caching of the above directories I tried adding page rules within the Cloudflare dashboard, despite my best efforts I cannot get Cloudflare to stop caching all the images within the products directory.
My first attempt was to use a wildcard and prevent caching across all pages on my site, the pagerule I used was:
mysite.co.uk/*
However, the above rule didn't seem to do anything. I then attempt to get more granular with it and opted for a rule like this:
mysite.co.uk/images/products/*
This rule didn't seem to work either. I then looked at more advanced wildcard use but I fear I got out of my depth:
mysite.co.uk/images/products/*/$1.jpg
Needless to say, the above rule didn't work either. So, my question is, what rule should I use to prevent caching of my product images?
Assuming your site is published at www.mysite.co.uk and the images you don't want to cache are under www.mysite.co.uk/images/products/... then, you would create a page rule such as:
This rule will tell Cloudflare to not store the resources matching the expression on the CDN. You can also change the rule to match www.mysite.co.uk/images/products/*.jpg if you only want to match jpg images under that folder.
Finally: if there are more page rules defines, it is recommended ordering them from most to least specific, as only one rule is matched for every request.
I'm trying to maintain the "search_filters / facets_search_wrapper" status of the checks after changing between categories, for exemple, when the user selects "size: L" and changes the category to t-shirts, keep the "size:L" check active.
I've been thinking of saving some part of the URL that identifies the selected search filters, but I don't manage to find any solution for this.
Any ideas?
Thanks for your time!
Don't use any URL parameters, think about using Local Storage where you can filter out results on DOMReady, or you can use cookies and alter results with PHP.
Facet module is completely different in PrestaShop 1.7, there i'd suggest to use cookie method, if you are working on 1.6 tho, i'd go for a JS solution.
I've been through a few similar posts,
Facebook Like Custom Profile URL PHP
Custom URL / Apache URL Rewriting
But its still not clear, the actual method/process is not available..
Guys , little more guidance would do a lot..
I would like to put forward the questions here:
Users should have a chance to decide what is their url, Just like in case of fb, twitter
for example: www.facebook.com/harry.inaction
I am using the linux, apache, mysql, php environment for this.
Users are identified based on their user id's which get created automatically when they join in
And I fail at the very first step, seriously I don't know get started.
Thanks
It's going to be impossible to put any details as an answer because you've got to build this system of yours and there's more than one way to do it. Design decisions will need to be made based on the way you want things to work and what you already have (they're going to have to work together in some way).
Say you've already got a system for creating users (and it sounds like you do) and you already have a system for viewing profiles. You'll need to extend this system so that you store an extra "my_vanity_url" field in your user table in your database. This field needs to be unique. When a user edits their profile, they have the option of changing this to whatever they want (limiting it to only letters and numbers and dashes for simplicity).
Next, when you display this profile, say it is via /profile.php, your code needs to check a few things.
First it needs to check how it's called, looking at $_SERVER['REQUEST_URI'] you can see either /user/some-vanity-name or /profile.php?u=1234.
If it's the latter, you need to redirect the browser, do a database lookup to see who the user with user_id 1234 is.
Pull the "my_vanity_url" column out of the database for this user and redirect the browser to /user/my_vanity_url_value (replacing my_vanity_url_value with the value of that column).
So now, if you go to http://your.domain.com/profile.php?u=1234, your browser gets redirected and the URL address bar will say http://your.domian.com/user/my_name.
Next, you need to be able to take that unique name and turn it back into the old ugly looking profile page. Two things need to happen here:
You need to extend your profile.php once more to take an optional vanity name as opposed to a user_id
You need to use mod_rewrite to internally route vanity names to /profile.php
For the first thing, you simply look for a different $_GET[] parameter instead of whatever it is for a user_id. Say it's called name: so look at $_GET['name'], see if it exists, if it does lookup the user in the user table whose vanity url name is $_GET['name']. Return the profile of that user.
For the second thing, you just need to put this in the appropriate place in your htaccess file in your document root:
RewriteEngine On
RewriteRule ^/?user/([A-Za-z0-9-]+)/?$ /profile.php?name=$1 [L]
This is just an example for how to implement something like this. It may be completely inapplicable for what you have, but it should give you an idea of what you need to do.
I wanted to move a category called "trinkets" before one called "widgets". Instead, it somehow ended up inside of "widgets." When I moved it back out, the url key was changed to "trinkets-1". How do I get it back to "trinkets"?
Here is something I found - http://www.yireo.com/tutorials/magento/magento-administration/664-fixing-url-rewrites-with-magento
Quoted from the above website:
Sometimes when you make changes to your products, or enable a certain extension, Magento might start to rewrite all your URLs to include a suffix "-1" or some other number. Within the URL Rewrites, Magento differentiates between System URLs and Custom URLs. If the System URLs are broken like this, you should not fix this by adding new Custom URLs.
Instead, open up phpMyAdmin, create a backup of your Magento database, and flush the Magento table core_url_rewrite (so that it becomes totally empty). Immediately afterwards, refresh the Catalog Url Rewrites under Index Management. This will regenerate all System URLs.
If you are comfortable to take a backup and try removing all the records from the above table (obviously preceded by any table pre-fixes), it sounds like a quick fix.
When you rename a category an URL Rewrite Rule is generated so you don't loose the traffic that is incoming on the original category url (see Catalog -> Url Rewrite Management, search for Request Path: trinkets).
Now, when you move it back it checks if the URL Key "trinkets" is already used (which is, because a redirect was generated).
Delete from URL Rewrite Rules the records matching "trinkets" and modift the url key (edit category). Also, when you modify the URL key for the category, make sure the checkbox for " Create Permanent Redirect for old URL" is unchecked.
I what to record all my website searches with google analytics but the problem is my search links look like this
**www.mywebsite.com/search/category/your+query+here**
From what i found out i must give GA the query parameter (mywebsite.com/search.php?q=your+query+here) but i have none (and don't want any).
Is there a way to rewrite the URL with a google analytics filter? If yes how.
Yes, you can create a custom filter that rewrites URL /search/<category>/<query> to ?q=<query>&c=<category>.
Go to Analytics Settings › Filter Manager, and click Add Filter. Choose Custom Filter in the Filter Type drop-down list, select Search and Replace radio button, and then set two Request URI fields with the corresponding values. For further details, see ’How do I create a filter?’ page in Google Analytics Help Center.
Keep in mind! Since past visitor data cannot be reprocessed, always keep a ’raw’ profile that you do not apply filters against. For further details, see chapter ’Best Practices for Filters & Profiles’ in presentation ’Filters in Google Analytics’.
Site Search is processed BEFORE Filters are applied.
I went through a week of testing to realize this. Yes, the Filter logic is correct, but as of Nov 1, 2009 this will not work with Site Search.
We accomplished this by appeding the ?search= parameter to the page URI in the GA script. Then we strip search params in the Profile Settings and we get the pure URI's in the content section as well as the Searches tracked in Site Search.
I know this is old, but to expand on the prev accepted answer, use a 'virtual url' in the _trackPageview call, so for www.mywebsite.com/search/category/your+query+here have
gat._trackPageview( "/search/content/your+query+here?query=your+query+here&cat=category" )
This means that URLs won't be changed, so everything else works (as noted in the previous answer) - if you really want to you could remove the search params, but unless you're running into a URL limit I'd probably prefer to keep them present so they can be seen in the content reports.