Just wondering why by reading the source code in default-constants.php:
function wp_plugin_directory_constants() {
if ( !defined('WP_CONTENT_URL') )
define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content'); // full url - WP_CONTENT_DIR is defined further up
I have an alias of my site and my homeaddress is different to my site_urladdress causing CORS problems.
What is the best method to make it point to home?
The value that's used by default, the WordPress address (siteurl), covers both of the most common WordPress configurations.
WordPress URL and Site URL are the same
WordPress is running in a different folder
If you were to use the Site URL (home) instead, anybody wishing to run WordPress in a different folder would have to either manually set the content directory constant or move their wp-content directory.
As you aren't running a standard configuration of WordPress, you'll simply need to override the constant yourself.
get_option() isn't going to work inside wp-config.php so you'll need to manually enter the URL or use another method of detecting it. You're probably better entering it manually in my view however it's going to depend on context.
define( 'WP_CONTENT_URL', 'https://example.com/wp-content' );
Related
I've submitted a widget to Wordpress.org and received this guidance:
The way your plugin is referencing other files is not going to work
with all setups of WordPress.
When you hardcode in paths like wp-content or your plugin folder name,
or assume that everyone has WordPress in the root of their domain, you
cause anyone using 'Giving WordPress it's own directory' (a VERY
common setup) to break. In addition, WordPress allows users to change
the name of wp-content, so you would break anyone who chooses to do
so.
Please review the following link and update your plugin accordingly.
And don't worry about supporting WordPress 2.x or lower. We don't
encourage it nor expect you to do so, so save yourself some time and
energy.
https://developer.wordpress.org/plugins/plugin-basics/determining-plugin-and-content-directories/
Remember to make use of the FILE variable, in order than your
plugin function properly in the real world.
Example(s) from your plugin:
my-widget/includes/my-widget-scripts.php:6:
wp_enqueue_style('my-widget-main-style', plugins_url(). '/my-widget/css/style.css');
my-widget/includes/my-widget-scripts.php:8:
wp_enqueue_script('my-widget-main-script', plugins_url(). '/my-widget/js/main.js');
I've followed the link and tried out some of the variations therein, but nothing has worked to replace the code I currently have (found at the bottom of the quote).
What should I replace it with that will be found up to standards for Wordpress.org?
Take a look at the documentation for plugins_url(). The first argument takes a $path argument to a append to the URL. The second takes a full path to a plugin. if you pass the __FILE__ Magic Constant to it, it will be for your current plugin.
You should take advantage of both of those arguments:
wp_enqueue_style( 'my-widget-main-style', plugins_url( '/css/style.css', __FILE__ );
wp_enqueue_script( 'my-widget-main-script', plugins_url( '/js/main.js', __FILE__ );
Here's how I did it in mine:
wp_enqueue_script( 'my-widget-main-style', plugins_url('/js/main.js', __FILE__) );
I'm developing a wordpress plugin and was wondering how I can make it so only my plugn can access its own files. basically looking for something similar to this:
defined('ABSPATH') or die();
I think I saw something like this in someone elses plugin once:
defined('PLUGINNAME') or die();
I didn't understand how it worked, but was wondering if there is anything similar that will only allow my plugin to "require_once(plugin_dir_path(__ FILE __).'secondpluginfile.php');" its own files. (spaces between __ and FILE because otherwise stackoverflow tries to make it bold instead) Not sure if this restriction is built into wordpress(probobly not because some plugins have add-ons), or if I have to add something to make this happen. do I just put the pluginname or something in the "defined()" function, or do I need to set something up first?
So basically, if your plugin was a single php file, all the functions and logic included in the file would be accessible to the rest of the application once the plugin was installed and activated.
Most plugins are not designed that way, however. The plugin filename that acts as the entry point to your plugin usually loads the rest of the files in your plugin directory either by simply including them or calling classes and functions based on events occurring on the site via hooks.
So, if you want only your plugin to be able to access its own files you could do a few things.
First of all, add defined('ABSPATH') or die(); at the top of the main plugin file. As user Ifty wrote, "ABSPATH is a constant defined in wp-config.php line 86. When wordpress will try to execute your plugin, the ABSPATH constant will be defined. But if someone else try to execute your plugins file directly, ABSPATH will not be defined and in that case your script will not get executed."
So that protects your file from being accessed directly outside the context of Wordpress.
To protect your plugin's files from the rest of the site itself, simple wrap any include or require_once statement or code in your main plugin file in a function or class which is only called based on conditions you set. For example
<?php
/*
Plugin Name: Example plugin
Plugin URI: http://stackoverflow.com/
Version: 1.0
*/
defined('ABSPATH') or die();
add_action('your-custom-action', 'protector_function');
function protector_function(){
if ( current_user_can('manage_options') ) { //checks if user is admin you can use whichever conditions you want here
require_once plugin_dir_path( __FILE__ ) . 'filename-with-plugin-code.php';
// any other plugin code here
}
}
You can define your own action and call it using do_action() (reference) so that you can ensure your plugin code is only called where you have specified throughout the application.
Wordpress plugins exist to extend the functionality of Wordpress so if you do not want your code to be accessed from Wordpress in any way at all, I am not sure a plugin is the correct solution.
Hope this helps!
You can put
defined('ABSPATH') or die();
at the beginning of your plugins code. Actually what it does is check if ABSPATH is defined or not. If it's not defined then it will execute die() and stop executing your plugin file.
ABSPATH is a constant defined in wp-config.php line 86. When wordpress will try to execute your plugin, the ABSPATHconstant will be defined. But if someone else try to execute your plugins file directly, ABSPATHwill not be defined and in that case your script will not get executed.
Another way of accomplishing the same result is to check for add_action function.
if ( !function_exists( 'add_action' ) ) {
echo 'Hi there! I\'m just a plugin, not much I can do when called directly.';
exit;
}
Code Reference: Akismet Plugin. You can take a look at their source code. As far as I know this plugin comes with wordpress package.
I'm using a localhost site as the basis for creating other sites from. I'm using php to generate internal links by finding the current domain, and displaying it with a shortcode. I intend to upload my site to a live host and therefore the domain will change, and my internal links won't be broken.
//add shortcode that displays current site name
function GR_site_name(){
$currentDomain = $_SERVER['HTTP_HOST'];
return $currentDomain.'/wordpress';
}
add_shortcode('GR_site_name', 'GR_site_name');
?>
I've tested this by adding the code to live sites and it works perfectly.
I've read the post at how safe is $_SERVER["HTTP_HOST"]? however it details it as 'generally unsafe' due to the script that it runs.
Is $_SERVER['SERVER_NAME'] safer than $_SERVER['HTTP_HOST']? Or are both regarded as bad practice?
Make a config file with define('host','https://example.com') and use host wherever you want and when you upload script to server just change url in config file and you're good to go
Use a combination of the standard WP_HOME & WP_SITEURL constants, along with the site_url() function.
I'd recommend using one local copy of wp-config.php and a different one for the live site, and then add the following to them:
define('WP_SITEURL', 'http://www.example.com/wordpress'); // Or 'http://localhost/wordpress' for the local copy
define('WP_HOME', 'http://www.example.com');
That way, you don't need a custom function or shortcode - you can simply call site_url() wherever you need it to get the URL of your WP site.
Alternatively, if you need to keep the site URL variable and to accept anything that points to it:
define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST'] . '/wordpress');
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST'] . '/wordpress');
If you need to keep the shortcode for use within the context of a post, you can change it to:
function GR_site_name(){
return site_url();
}
Note that setting WP_HOME and WP_SITEURL override any database setting for the site's URL, and if you visit the Settings->General page, you'll see those two fields are greyed out.
Fatal error: Call to undefined function add_action() in D:\xampp\htdocs\excel\wp-content\plugins\DatabaseToExcel\download.php on line 13
I am creating a plugin to export database table to excel sheet. Mainly I have two files in my plugin, I am sending a post request to download.php file with the table name which will be exported. I want to be sure on download.php file that the admin is logged in, but when I am calling any of WordPress Core function, fatal error occurs. I am including wp-load.php and others files like this -
require_once('../../../wp-load.php');
require_once('../../../wp-config.php');
require_once('../../../wp-includes/load.php');
In this case, functions like auth_redirect() working fine without any error. But I want to upload this plugin to www.wordpress.org.
They said that including files using this method is not good and we can not approve it because of file structures in another WordPress installation can vary and in that case it will not work.
Here is the reply from wordpress.org-
In download.php, which is STILL not protected by the way
require_once('../../../wp-load.php');
require_once('../../../wp-config.php');
require_once('../../../wp-includes/load.php');
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: http://codex.wordpress.org/Plugin_API
For other possibilities, or to better understand why we disallow this, read this: http://ottopress.com/2010/dont-include-wp-load-please/
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.
This is my very first WordPress plugin and after many hours of struggling and reading all of these, I do not have solution.
Include your download.php file after WP files are loaded. Here's example of code to place in your plugin's main file (or loader):
add_action('wp_loaded', 'pluginPrefix_include_download_script');
function pluginPrefix_include_download_script() {
require('download.php');
}
You can also use other actions like admin_init if you need this file to be loaded earlier.
You can also specify path to a file using plugin_dir_path(__FILE__) this will return path to your plugin directory and you can use it like this:
function pluginPrefix_include_download_script() {
$pluginDirPath = plugin_dir_path(__FILE__);
require($pluginDirPath.'download.php');
}
this may become handy if your download.php located in subfolder (e.g. inc/). In this case your include function may look like this:
require($pluginDirPath.'inc/download.php')
My WordPress login page at mysite.com/wp-login.php is giving me a cannot connect to 127.0.0.1 error.
The site works, and other WordPress admin pages are available, like upgrade.php. I've done some googling, tried some of the suggestions here: http://wordpress.org/support/topic/error-establishing-a-database-connection-112
But to no avail. Admin has been working for weeks and nothing has been changed. Everything also looks correct in config.php. The site is on AN Hosting, and I logged into the phpMyAdmin on the cPanel and everything seems to be in order with the database
I have very little experience with database issues and MySQL, so I am a little flummoxed.
Same problem. AN Hosting is blocking you. They are blocking any attempt to login on some of their shared servers. I changed wp-login.php page to a new address, and corrected all references in the WordPress folder.
Now everything works fine. However, it will only work until the next update.
AN Hosting says they are doing this only temporarily because they've been facing some type of attack on WordPress logons. If you ask me this is very lame. They need to resolve this issue.
Call them! I will also call them again and complain.
Thats strange if it was working before, and not now.
I'm used to get trouble connecting to my database with WordPress (since I'm installing WordPress websites many oftern), but when ever it failed for me the problem were in the hostname
I would suggest you to check your database hostname, if you can log in to cPanel you can find out form the data base interface
Look here:
Then check this section for the hostname:
If you specified correctly there should be no problem
After seen the comment you left after your question, this came to my mind
Go into
PhpMyAdmin -> Your WP Database -> Options Table and check the site url value, it might be still pointing to your old dev url
So based on the answer given by #user3035755 , I can give you the following work-around:
In your root directory, create a file called(for instance - you can change that if you want to) login.php(not sure if the word "login" would be accepted - you might have to play around with it a bit, until something works). In this file add the following code:
<?php
include_once( dirname( __FILE__ ) . '/wp-login.php' );
This code will include the original wp-login.php file. I'm not sure how their restriction works - if it's based on where the call to the database is being made(as in from which exact file), then it might fail due to the fact that the connection would still be made from wp-login.php(although I assume that's not how they did it). If they instead check the file that is being executed, then you should be fine(since in that case it would be login.php - again, you might have to change that).
Now, that's just the first step - you can either manually go to login.php every time you want to log-in, but it'd be better if the login URL is automatically adjusted. To do that, go to the /wp-content/ directory and create(if it doesn't already exists) a mu-plugins1 directory. In there create a new file, called new-login.php and in that file put the following code:
<?php
/*
Plugin Name: New Login URL
Plugin Description: Makes the login URL /login.php instead of /wp-login.php
*/
function nl_login_url_filter( $login_url ) {
return str_ireplace( home_url( '/wp-login.php' ), home_url( '/login.php' ), $login_url );
}
add_filter( 'login_url', 'nl_login_url_filter', 10 );
function nl_logout_url( $logout_url ) {
return str_ireplace( home_url( '/wp-login.php' ), home_url( '/login.php' ), $logout_url );
}
add_filter( 'logout_url', 'nl_logout_url', 10 );
So what happens in this plugin, is that it simply hooks to the login_url and logout_url filters and changes http://mydomain.com/wp-login.php?test1=23&test4=56 to http://mydomain.com/login.php?test1=23&test4=56.
This way you don't have to take care of always entering login.php instead of wp-login.php.
Again - if that doesn't work, try using a different name for the file, like enter.php(for instance), just remember to change the file name in the new-login.php file as well.
Footnotes:
The /wp-content/mu-plugins/ directory is a special directory. All .php files directly inside it(not in a sub-directory) get included in alphabetical order. So basically any plugin you put in there will always be enabled(the only way to disable a mu-plugin is to delete it's file in the mu-plugins directory). You can read more about mu-plugins here
Been there done that, but that does not mean my guide-lines have the same positive result
for you but maybe it helps a little. Below a small roadmap with steps you could take:
These 2 (site url and home) you could add in wp_config.php.
define('WP_HOME','http://yoursite.com');// blog url
define('WP_SITEURL','http://yoursite.com'); // site url
Did it make any change for login? maybe you check the phpMyAdmin (through cPanel).
Check wp_options ( the $table_prefix = '???_' ??? is what you have put there,
you find it in wp-config.php).
Now look at line 1 option_id 1 / option_name siteurl / option_value here must be your domain url.
Now find around line 36 option_id 36 / option_name home / option_value here should be your domain url.
IF they where not correct I assume you made corrections, saved them into the db and check if you are able to login now.
Stil not working? maybe following would good to check also:
What the .htaccess file shows (correct path?)
Add if not already done some debug "stuff" in wp_config.php:
define( 'WP_DEBUG', true ); // Or false to disable
if ( WP_DEBUG ) {
define( 'WP_DEBUG_LOG', true ); // writes errors down in wp-content/debug.log
define( 'WP_DEBUG_DISPLAY', true ); // shows errors on screen output, set to false so only write into logfile
define('SAVEQUERIES', true); // will have a performance impact so disable if not needed
define('SCRIPT_DEBUG', true); // Use dev versions of core JS and CSS files (only needed if you are modifying these core files)
}
If no debug.log is shown in wp-content you create the file by hand.
Btw, is the wp-login.php having the correct chmod? (644 it should be)
Do you have/use cache plugins if so, could try to disable it by renaming folder.
Do you have some caching options through .htaccess if so, disable it for the moment.
Do you use a login plugin or script? If so, disable it for the moment being.
You could check functions.php (in your theme folder) if there is some code-snippet which could do a redirect for your wp-login.php, if so disable it for the moment.
Last but not least, if all above still not was solving your problem you could rename the plugins folder for a moment and try to login. (don't forget tot rename it back afterwards)
I hope that one of these will help you to find the solution.
Ask your hosting provider what your database host should be and update the DB_HOST line in wp-config.php accordingly.
This is usually localhost or 127.0.0.1 but on some hosts it may be something completely different that you would not be able to guess without asking - for example I've had long weird hostnames supplied by GoDaddy for this before (years ago when I still used GD for anything).