loveetc saidYes that would be more efficient in the long run but there are much bigger problems and more important features that need the marketplace developers attention, especially considering it is something that is so easy for reviewers to moderate themselves.
EugeneO saidNo, they do not need to do that. A much more efficient way would be to make a simple check when a user uploads the item, if the item name is exactly same, it should give an error and not let the user upload the item, and if the name is partially same, it can give some warning. I bet it wont take more than couple of minutes to write this code.
All reviewers have to do is a quick site search for the name when they review the item. It would take a matter of seconds.
Ivor saidAll reviewers have to do is a quick site search for the name when they review the item. It would take a matter of seconds.
The review system does not detect if the name has been taken. We truly wish we could remember the name of ~3MM items, but we can’t. So, yes we can say it’s allowed but better to be unique.
I have step by step instructions in the documentation. There are separate step by step instructions for the FTP upload method and the WordPress uploader install method. I also make sure to suggest using a child theme for all modifications to make updating to a newer version of the theme straight forward. With the above, I very rarely get buyers asking how to update the theme.
I’ve tried an update notification script but to be honest I don’t know if it even worked. It would be easier but I definitely don’t think it’s an absolute requirement.
Veuse saidThat’s a step in the right direction but the whole point was for post format structure to be standardized. If it’s shipped as an optional plugin instead it misses the point.
purethemes saidA plugin with all the new UI is being released, so you can simply ship the plugin with the theme…
And I have ready theme which was waiting just for 3.6 as I wanted to use new Post Formats :/ and do not bloat the code with backward compatibility meta boxes… I’m so disappointed
The rule means you can use the vendor specific prefixes and the validation errors they cause will not have any impact on your item when it is reviewed.
daihlo saidRe: Your second issue.
Update. Not heard back from dev still.
Have found a solution to one issue. When creating an event, the theme pulls a snippet from it to display in the events listing pages. This is where the CSS issue was… If the snippet does not fill the letter count of the default snippet length, it will pull the vid embed also which screws up the whole layout…
Found way round it by adding a manual snippet to the event post which overrides the default settings.
Found where the problem lies for the events filter now working, but would have to change code to fix it. There is an option in some custom page building sections added to the theme to select which category of events is listed on that page. you can only select one though… not multiple.
The ‘filter’ then only picks up that one which makes it useless. Prob an easy fix if you know what you are looking for!!!
Unfortunately has a major impact on the themes functionality as its an event / music listing theme…couple of other small issues, these are the 2 site killers, half way there. Not heard anything back from the author though which is a pain.
If the theme uses a hierarchical taxonomy for the categories shown in the filter menu it sounds like you need to set all the filters you want visible on a page as the child of a main category. This way you select the main category as the category to display and all it’s child categories are shown as filter buttons.
I’m not the theme author or even know which theme it is but this is what I assume based on your post.
If this is the case then it’s not a bug at all.
That didn’t work for me. I think because I’m using the after_theme_setup hook to add theme support for post formats the $post global might not have been defined yet.
I am playing around with post formats trying to set different post formats for standard posts and a custom post type. To do this I want to detect when we are on the custom post type Add New or Edit screen.
Detecting the Add New screen is simple as the
post_type=custom_post_type_name query sting is set however I can not find a way to detect the post type on the edit screen of a custom post type.
Does anyone know of a way? I’ve been playing around with this for a while and can’t find a solution.
RubenBristian saidIf you are using a caching plugin wouldn’t a visitor to your site see a cached version of the page whether they are on a device with a retina display or not.
@Eugene, i’m not sure why it wouldn’t work.. The cookies are not stored in the cache..
Example: Visitor A is the first visitor to a new page. They are using a standard desktop. Page is cached with standard images.
Visitor B then loads the page on a retina mobile device. Because no changes were made to the content in the admin area and their is now a cached version of the page they receives the same version of the page with standard images as Visitor A.