Wordpress plugin approval standards: ## Calling file locations poorly - php

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__) );

Related

wordpress plugin - how do I make it so only my plugn can access its own files

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.

wordpress custom rewrite rule to external non-wordpress php page

Hello Everyone and thank you for your help!
I have an external (outside wordpress in root directory) php file that I would like to use the custom_rewrite_rule function to make the url pretty as well as pass on information for variables that will look up an API record from that URL. You might ask why I haven't done it the regular way and made it a page template inside wordpress, and that is because I am using a custom JQuery slideshow that seems to have trouble running inside a wordpress environment.
So what I have in my child themes functions.php is:
function custom_rewrite_rule() {
add_rewrite_rule('^yacht-details/([^/]*)/([^/]*)/?','yacht-details.php?info=$matches[1]&boatid=$matches[2]','top');}
add_action('init', 'custom_rewrite_rule', 10, 0);
and in the php file am using the standard $_GET to acquire the information.
$info = $_GET["info"];
$boatid = $_GET["boatid"];
My actual problem is what I am actually getting is literally $matches[1] and $matches[2] instead of the variables.
What am I doing wrong? Does this need to be done with .htaccess instead of functions.php? The problem I run in to going that route is wordpress does not seem to like more than one subfolder.
Thank you again.

Why WP_CONTENT_URL is based on option `siteurl` instead of `home`

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' );

IPB - Access member data PHP outside IPB root

I have IPB and I have an PHP application which is outside of forum ROOT and on another subdomain as well.
In application I need to have access to member data, eg. posts count, email etc.
I have the latest IPB version and PHP 5.6
I googled a lot for solution, and finally I found this one:
Accessing IPB Classes Externally From Main Website
However, it didn't worked at all. There is no errors, just redirection to main forum URL.
Does anybody have experience wit IPB classes and or it's API?
Can somebody help me to reach the goal.
Solution is probably just one line of code.
EDIT:
I found work around, check out my answer below.
However I'm still interested for "nicer" solution.
After some research, I configured out that IPB redirects because board url doesn't match with current URL/subdomain. (my case)
So... There is workaround, not so nice but works at least, and is one-line solution:
<?PHP
$_SERVER['HTTP_HOST_R'] = $_SERVER['HTTP_HOST']; // Keep original info in another index.
$_SERVER['HTTP_HOST'] = "www.your-ipb-forum.com"; // Work-around
$forumPath = '../forum'; //FORUM FOLDER
define( 'IPS_ENFORCE_ACCESS', TRUE ); // Important so it does not redirect to forums
define( 'IPB_THIS_SCRIPT', 'public' );
require_once( $forumPath.'/initdata.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsRegistry.php' );
require_once( IPS_ROOT_PATH . 'sources/base/ipsController.php' );
$ipbRegistry = ipsRegistry::instance();
$ipbRegistry->init();
// Init done
$member = IPSMember::load($memberName, 'all', 'username');
print_r($member); // For demo purposes only
The third line is work-around with which we cheat on IPB.
The second line is "moving" $_SERVER['HTTP_HOST'] data to $_SERVER['HTTP_HOST_R'] so if you need current(real) URL in your application, you may use this variable instead because HTTP_HOST one is changed. (needed for workaround).

WordPress login screen database issue

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).

Categories