There are cases in which a plugin or theme needs to create a php file somewhere that can later include it. For example a captcha plugin, or some kind of a templating system like twig/smarty (In my situation it's simple template engine for a collection of widgets).

Where should be this file created?

The only place I can think of is wp-content/uploads/, but that just doesn't sound right :)

So is there a safe place where you can create files, and not worry about them being deleted on WordPress/plugin/theme update ?

One solution could be to create a child theme / directory in the themes / plugins directory...

6 Answers 6


The appropriate place IMHO would be a custom folder that you create inside the wp-content directory Read this before creating files: http://ottopress.com/2011/tutorial-using-the-wp_filesystem/


While working on a Wordpress plugin, I stumbled across your question. I also first thought about creating temporary files to cache some data my plugin was creating. However, giving it a bit more thinking, this approach seems odd to me as you don't want to have temporary data lying around on one server if you are trying to scale it using a cluster of servers.

So I searched again and it seems to valid solution for such problems is the Wordpress Transients API allowing you to store data in the database with an expiration date. Of course your problem could still require locally cached files, e.g. if they are too large for the database, but at least I suggest to take a look at this option, too :-)


You cannot rely on write access in the plugin or theme directory, so wp_upload_dir() is the only possible directory.
But I really doubt that there is a need to store the information in a new file. If the template is created by the user, store it in an option an parse the content with your regular plugin functions (for example by replacing placeholders with strtr()).

  • yes, that's good for replacing variables (I have something like that now). But if you also want to allow the user to use conditional tags like IF or loop a object, you need to write php code... Apr 25, 2011 at 17:51

I can only think of a few good reasons a plugin would need to create a file. One is to back up complicated options that the user can export and download to move to a new site. The other is a sitemap plugin.

If your plugin has template files that the user can customize you should give the user the option to move the customized file to the current theme directory so when your plugin updates they won't be overwritten. You can try to load the files from the theme directory first then fall back to your plugin directory.

Gravity Forms stores form uploaded files in its own folder inside of uploads. W3 Total Cache uses wp-content, login redirect uses the method I described above.


If you must create files (such as temporary files for a CAPTCHA Plugin), you should definitely use \wp-content\uploads\ (or a custom directory such as \wp-content\plugin-slug-files\).

Most other custom code should really be stored in the Database.

  • 1
    and eval() it? no way... Apr 25, 2011 at 17:44
  • What do you need to eval()? Apr 25, 2011 at 17:45
  • think of smarty for example. Let's say you create a widget and you want the user to have the ability to customize the output in anyway they want. So you add a textarea in the widget options where the user can write his own smarty-like template for that widget. That template needs to be compiled, and the best way to do that is by generating a PHP file and including it inside the widget. Apr 25, 2011 at 17:49
  • That sounds like a considerable stretch of the intended use of Widgets/Widget options... Apr 25, 2011 at 18:19
  • 1
    Certainly not. But IMHO if the user needs that much flexibility in creating custom Widgets, then the user should write a custom Plugin, or add custom Widget code to his Theme's functions.php file. Why have a Plugin, that creates Widgets, that enable users to create other Widgets? Apr 25, 2011 at 19:02

I always suggest a PSR-0 compatible autoloader and a library folder that just works.

Some WP users might shoot you then but perhaps you're not focused on these users, so this can be an option. Especially if you get more and more vendor specific libs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.