Upgrade notices describe the reason a user should upgrade. No more than 300 characters.<\/p>","0.5":"
This version fixes a security related bug. Upgrade immediately.<\/p>"},"ratings":{"1":"1","2":0,"3":0,"4":0,"5":"1"},"assets_icons":[],"assets_banners":[],"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.0.2"],"block_files":[],"assets_screenshots":[],"screenshots":{"1":"This screen shot description corresponds to screenshot-1 , 2 3(png|jpg|jpeg|gif). Note that the screenshot is taken from\nthe \/assets directory or the directory that contains the stable readme.txt (tags or trunk). Screenshots in the \/assets \ndirectory take precedence. For example, User Frontend Post Submit This plugin gives you all the post create scope, for any post type and any other extended options for displaying your very important post, post title, message body, captcha securities, choice catagories select ,set feature Image with fontend setting etc . \nBuild with shortcode for content section.<\/p>\n\n Key Features & options:<\/p>\n\n Set feature image<\/p>\n\n Note that the If no stable tag is provided, it is assumed that trunk is stable, but you should specify \"trunk\" if that's where\nyou put the stable version, in order to eliminate any doubt.<\/p><\/li>\n<\/ul>\n\n You may provide arbitrary sections, in the same format as the ones above. This may be of use for extremely complicated\nplugins where more information needs to be conveyed that doesn't fit into the categories of \"description\" or\n\"installation.\" Arbitrary sections will be shown below the built-in sections outlined above.<\/p>\n\n Ordered list:<\/p>\n\n Unordered list:<\/p>\n\n This section describes how to install the plugin and get it working.<\/p>\n\n e.g.<\/p>\n\n You can ask question and get support all the time. \nThis plugin does not match to your site style? Is this script not quite working as it should? Having trouble installing? Or need some custom modifications that are not already included? \nOr you want more features on next release? if any help need please contact with me : sadidcse8320@gmail.com<\/p>\n\n\n\/assets\/screenshot-1.png<\/code> would win over \/tags\/4.3\/screenshot-1.png<\/code> \n(or jpg, jpeg, gif).","2":"This is the second screen shot"},"jetpack_post_was_ever_published":false},"plugin_section":[],"plugin_tags":[63044,86,63046,63045],"plugin_category":[],"plugin_contributors":[93037],"plugin_business_model":[],"class_list":["post-38839","plugin","type-plugin","status-publish","hentry","plugin_tags-category-base-post","plugin_tags-post","plugin_tags-post-with-set-feature-image","plugin_tags-user-fontend-post","plugin_contributors-templatesplugin","plugin_committers-templatesplugin"],"banners":[],"icons":{"svg":false,"icon":"https:\/\/s.w.org\/plugins\/geopattern-icon\/user-frontend-post-submit.svg","icon_2x":false,"generated":true},"screenshots":[],"raw_content":"\n\n
readme.txt<\/code> of the stable tag is the one that is considered the defining one for the plugin, so\nif the \/trunk\/readme.txt<\/code> file says that the stable tag is 4.3<\/code>, then it is \/tags\/4.3\/readme.txt<\/code> that'll be used\nfor displaying information about the plugin. In this situation, the only thing considered from the trunk readme.txt<\/code>\nis the stable tag pointer. Thus, if you develop in trunk, you can update the trunk readme.txt<\/code> to reflect changes in\nyour in-development version, without having that information incorrectly disclosed about the current stable version\nthat lacks those changes -- as long as the trunk's readme.txt<\/code> points to the correct stable tag.<\/p>\n\nArbitrary section<\/h3>\n\n
A brief Markdown Example<\/h3>\n\n
\n
\n
\n
1.0<\/h4>\n\n
\n
0.5<\/h4>\n\n
\n