PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

Support for custom content directory

  1. Anonymous
    Unregistered

    Hi,

    The way we have our wordpress installations is that we use a custom wp-content directory:
    /public_html/
    /wordpress
    /wp-content
    /wp-admin
    /wp-includes
    /wp-content <!-- this is the wp-content used, path is defined in wp-config.php

    this allows easy wordpress upgrades as its as an svn external and we get to keep our project repositories separate from wordpress.

    However, when previewing a from for example it queries directly gravity-forms/preview.php
    which can't find wp-load.php.

    Is support for custom content directories something that we can expect in future version. Are there any easy changes we can do to the code in the meanwhile?

    thanks

    Posted 10 years ago on Sunday November 13, 2011 | Permalink
  2. WiklanderConsulting
    Member

    I’m having the same problem. My public_html contains:

    assets // what used to be wp-content/upload
    custom // what used to be wp-content/
    wordpress // The rest of WordPress, unchanged from upstream
    wp-config.php

    The code in question is in the top of preview.php

    <?php
    for ( $i = 0; $i < $depth = 10; $i++ ) {
        $wp_root_path = str_repeat( '../', $i );
    
        if ( file_exists("{$wp_root_path}wp-load.php" ) ) {
            require_once("{$wp_root_path}wp-load.php");
            require_once("{$wp_root_path}wp-admin/includes/admin.php");
            RGForms::maybe_process_form();
            break;
        }
    }

    instead of wp-load.php, I think the the script should look for wp-config.php

    Posted 10 years ago on Monday November 14, 2011 | Permalink
  3. WiklanderConsulting
    Member

    BTW, the same problem is in download.php and print-entry.php.

    Posted 10 years ago on Monday November 14, 2011 | Permalink
  4. Yes, we realize calling these files directly is a problem. We are looking for ways to change that so that those pages run within WordPress. That will solve all these problems. This change will be done for 1.7 or even before that.

    Posted 10 years ago on Monday November 21, 2011 | Permalink
  5. As Alex mentioned above, we are aware of this issue. It impacts any functionality that calls PHP outside of WordPress which is isolated to a handful (not all, and not the primary) of features in Gravity Forms. We will be correcting this in an upcoming release and it only impacts sites where the wp-content folder is being called from a custom location.

    Posted 10 years ago on Monday November 21, 2011 | Permalink

This topic has been resolved and has been closed to new replies.