Kleines Projekt <800

Geposted am

2014-06-26 09:45:45.0



Dieses Projekt läuft

Schreiben Sie ein ähnliches Projekt aus und erhalten Sie Angebote von Freelancern. Unverbindlich. Kostenlos. Schnell.

Jetzt ähnliches Projekt einstellen


Hallo lieber Entwickler!  


3 genau spezifierte Anpassungen für Wordpress Plugin + readme.txt  

Wir würden gerne unser Wordpress Plugin in das Wordpress Directory eintragen. Jedoch hat noch einige Änderungswünsche bevor das Plugin aufgenommen werden kann. Außerdem würden wir auch noch eine saubere readme des Plugins brauchen und das Layout könnte noch etwas schöner gestaltet werden. Setzen Sie dies bitte um und passen Sie das Wordpress Plugin so an dass es konform. Anbei ist noch der Text von Wordpress in welchem ihre Anforderungen stehen.


Die Änderungen im Detail:

## Uploadify  The plugin calls Uploadify. Historically, we've had lots of security issues with regard to plugins that include "uploadify" because they don't consider the security ramifications of allow any file to be uploaded.  For example, some web configurations will do things like execute example.php.pdf as a PHP file. Now, the underlying problem is indeed in those configurations, but the problem still exists and needs to be accounted for as well, in any good upload code.  Generally speaking, we prefer plugins to not attempt to handle "uploads" themselves, but to use the built in WordPress media functionality for that. WordPress has many functions to handle both media uploads (image, video, audio) as well as to handle just raw "file" uploads, which a PDF would likely fall under. Additionally, WordPress has a media management system built in, where users can upload files, and those files will be indexed by the system as "attachment" posts.  We would highly recommend using this built-in functionality instead, as it accounts for security issues like these, and takes things like user permissions into account as well. No need to roll your own code if you use this sort of functionality.  We recommend looking at the wp_handle_upload() function and the various calls made to it in WordPress, as well as the media system in general. Using functionality like this can simplify your plugin quite a lot, and also mitigate any potential security issues that you might accidentally introduce to a site.  ## Including your own copu of jquery  WordPress includes its own version of jquery and many other similar JS files, which have all been rigorously tested with WP and many of the most common plugins. In order to provide the best compatibility and experience for our users, we ask that you not package your own (especially not an older version) and instead use wp_enqueue_script() to pull in WordPress's version.  Please review and update your plugin accordingly. You need to both change your code to use our jquery as well as remove the unused files. Remember! Keeping unused files out of your plugins makes them smaller and less potentially vulnerable! if you have any jquery files included in your plugin that WP core has, just delete them.  Offloading jquery js, css, and other scripts to Google (or or anywhere else frankly) is similarly disallowed for the same reasons, but also because you're introducing an unnecessary dependency on another site. If the file you're trying to use isn't a part of WordPress Core, then you should include it -locally- in your plugin, not remotely.  If your code doesn't work with the built-in versions of jquery, it's most likely a no conflict issue. If you can't guess, we -really- want you to use our JS files, and if you can't, we need to know why so we can fix things for everyone. If you're just including it because you want to support old versions of WP, or because you think they may not have jquery, please don't. If they don't have the default jquery, a lot more than your plugin will break. And if they're on older versions of WordPress, they need to upgrade, and we don't recommend you support anything except the most recent version of WP and one release back.  ## Including calls to wp-load directly  Including wp-config.php, wp-blog-header.php, wp-load.php, or pretty much any other WordPress core file that you have to call directly via an include is not a good idea and we cannot approve a plugin that does so unless it has a very good reason to load the file(s). It is prone to failure since not all WordPress installs have the exact same file structure.  Usually plugins will include wp-config.php or wp-load.php in order to gain access to core WordPress functions, but there are much better ways to do this. It's best if you tie your processing functions (the ones that need but don't have access to core functions) into an action hook, such as "init" or "admin_init".  Please consult the Plugins API reference for more information:  If you're trying to use AJAX, please read this:  For other possibilities, or to better understand why we disallow this, read this:  If you're trying to use it because you need to access WordPress functions outside of WordPress, we'd actually much rather you didn't do that at all. Your plugin should be inside WordPress, only accessible to people who are logged in and authorized, if it needs that kind of access. Your plugin's pages should be called via the dashboard like all the other settings panels, and in that way, they'll always have access to WordPress functions.