I'm using the unyson Framework for WordPress and currently using page options which work just fine on that particular page.
But I want to be able to access those options when on another page.
Here is my php -
$page = fw()->theme->get_options( 'service-settings' );
<?php echo wp_kses_post($page['service']['options']['service-box']['options']['description']; ?>
But this doesn't allow me the content from the array.
Using the following I can see the array, but cannot get the data.
fw_print($page);
Thanks guys
You're receiving just options array by calling fw()->theme->get_options('slug') - literally what you typed in the framework-customizations/theme/options/slug.php file.
If you want to receive the actual data you need to use DB helpers.
$data = fw_get_db_settings_option();
// or even refer to individual options, for performance's sake
$individual_option = fw_get_db_settings_option('option_id');
fw_print($data);
fw_print($individual_option);
Related
I'm new to WP development. I need to write a hook to check if the currently logged in user is viewing a post listed within a specific category, and then redirect user if they're lacking certain meta data.
I tried creating this function:
add_action('init','check_user_post_category');
however inside that function I was unable to get the post object (I have tried everything I found on the web!)
global $post; // This object is not valid at this time
global $wp; // $wp->request is empty
$_REQUEST; // This var is giving me an empty array! Is this normal??? :(
Could you kindly suggest, what hook is best to use in this case, and how to get the post object? Many thanks!
Use 'wp' hook instead of 'init'.
add_action('wp','check_user_post_category');
Maybe this would work for you.
I don't know the exact meaning of the question but someone asked me this question in interview. I just want to know that there's something like that, we use any route algorithm in Wordpress?
This could be a trick question because routing would mean mapping an HTTP request to trigger specific function or method that would handle the request which is not something that WordPress does (there is a section about WordPress at the bottom). In simple word, you read the HTTP request information to decide what function is going to be triggered.
Bit more details in simple words
if you are building a PHP project from scratch and want to display specific content or trigger a method/function there are usually two option (without routing)
Using POST , GET or REQUEST variables and complex conditional statements to achieve what you want, so a result URL could be something like this
http://example.com/index.php?view=pubications&per_page=5
Setting a PHP file for each type of content
http://example.com/publications.php?per_page=5
However, if you created a Router (Routing algorithm as you named it or routing system) then pushed all requests to index.php and have the latter include let's say something like this:
// Include the Router class
require('classes/router.php');
// Include functions responsible for display our content
require('view/display.php');
I'll not go into how to build a router, just giving examples assuming that you already have one just to give you an idea how routing works.
So assuming you have a router and function to display a contact form for example, you'd also include something like this:
Router::add('/contact-us', get_contact_form(),'get');
Router::add('/contact-us', handle_contact_form(),'post');
Then initialize the Router
Router::initialize('/');
Again assuming you have a complete Router, the above function would tell the index.php file to handle HTTP requests on this URL differently:
http://example.com/contact-us
If it's the default request type GET, trigger this function get_contact_form(), but if the request type is POST trigger this one handle_contact_form() which will act and display content differently depending on your needs.
That's great because it would be instead of something like
http://example.com/index.php?page=contact-us
index.php content would handle the request differently since there is no router.
// Include functions responsible for display our content
require('view/display.php');
if( isset($_GET['page']) && $_GET['page'] == 'contact-us'){
echo get_contact_form();
}
if( isset($_GET['page']) && $_GET['page'] == 'contact-us' && isset($_POST['contact_submit']) ){
echo handle_contact_form();
}
Imagine how long and ugly this would look like if you have a lot of pages and a complex site.
So back to WordPress
If you have a new installation you'd notice that the URLs looks something like this:
http://example.com/?p=62
http://example.com/?cat=1
http://example.com/?author=3
So it would just take URL parameters then build a WP_Query based on that, if is p then look for posts in database by ID, if cat then look for categories by ID and so on... (that's the simple explanation, there is a lot going on of course in the back-end, but just to give an idea).
You might notice after changing permalink structure that the above examples would now look something like this:
http://example.com/post-slug
http://example.com/author/name
http://example.com/category/uncategorized
This might look like routing, but it isn't, let's go in a bit more details about how this works.
When requesting a (pretty-link) URL on WordPress, first thing that happens is that the .htaccess looks for a folder/file with same name on the server, if it exists it will served, if not, it would send that request to the index.php file which does one thing:
/** Loads the WordPress Environment and Template */
require( dirname( __FILE__ ) . '/wp-blog-header.php' );
loading the wp-blog-header.php file, which will make a small check to make sure the code only run once then the following:
// Load the WordPress library.
require_once( dirname(__FILE__) . '/wp-load.php' );
// Set up the WordPress query.
wp();
// Load the theme template.
require_once( ABSPATH . WPINC . '/template-loader.php' );
Let's not go deeper into these files, what's concerns us the most is what 'wp-load.php' and 'template-loader.php' does
wp-load.php
This one among other things, looks for wp-config, make sure everything is set correctly, then connect to the database, of course after a lot of initialization, setting up constants loading a lot files that handles different parts of WordPress structure. Part of this process is that WordPress tries to match the request URL with a large set of rule called rewrite rules which are set of regular expressions, when a match is found WordPress will translate that URL into a database query using [WP_Query][1] class which is located at wp-includes/class-wp-query.php and this class will save the query results among other things (query type...etc)
template-loader.php
This one handles the display part, it uses some WordPress function that make use of WP_Query (eg:is_home()) to find out what type of content is to be displayed, then loads the the correct template based on that, and finally the template will use WP_Query to show the result.
I am not sure if this is an issue with my current setup, or what I want to do.
I have a module that is programatically creating nodes in my Drupal 6 site, and within each I have to provide links in between various nodes.
I basically have a few foreach loops, and within each I have the current path.
For instance:
foreach ($page->category as $category) {
$category_link = "category/" . $category['id'];
// generate category pages
...
$content = "<a href='$category_link'>".$category['name']."</a>";
_create_node($content);
foreach ($category->article as $article) {
$article_link = $category_link . "/article/" . $article['id'];
// generate article page
$content = "<a href='$category_link'>".$category['name']."</a>";
$content .= "<a href='$article_link'>".$article['name']."</a>";
_create_node($content);
}
}
The issue that I'm seeing is that the link seems to be continually built up.
For instance, in the main category pages it is fine (I'll see category/1234), and the article link will be fine, but the category link will seem to be longer than it should. Basically, I'll end up seeing:
category/1234/article/5678/category/1234
My first thought was to make use of $base_url and just create absolute paths, however whenever I try printing that variable from my module it is completely empty. This is on a local server, however when I move it to production Drupal isn't installed at the root, so I can't simply add a slash to the front of the link.
Try using $GLOBALS['base_path'] to get the base path.
$GLOBALS['base_path'] will work, but you are accessing a global variable that ALSO contains some things like your database connection info and some other important stuff. So with a slip of the finger you could muck up other things. I prefer base_path() which does the same thing but is a modicum safer.
Use
global $base_url;
For path to themes folder use
path_to_theme()
You can use base_path() but that will not provide you with the domain name.
Base url will provide you the complete url like : www.example.com
base_path() will give you : /
path_to_theme() will give you : sites/all/themes/yourthemename
I am using a custom shortcode plugin. The plugin allows me to run some php. The php queries a non-wp database to build a page of vehicle specs and everything works great. The issue is that all of the information needed for the page title and description is contained within the data coming from the database. I've tried some of the standard wp php filters but the title does not change.
Is this not possibly because of the execution timing of the shortcode?
TinyMCE in WP admin. Shortcode
-----------------------------------------------
[myplugin data_id='42']
PHP window in shortcode editor
-----------------------------------------------
$GP=array_merge($_GET, $_POST);
echo "hello word" //works
echo $data_id; //works
echo $GP[some_post_data]; //works
//connect to database (irrelevant)
echo "the title from data table for data_id 42 = ".$data[title]; //works
// the following has no effect on page title even though $data[title] contains valid data
add_filter('the_title','myCallback');
function myCallback($data){
return $data[title];
}
The problem is that $data[title] is out of scope, and that your filter callback is set up incorrectly. Also, you SHOULD encapsulate associative indexes with quotes.
When adding a callback to an existing filter, the arguments within the callback are passed by the filter definition. Case and point: Filtering The Title
The arguments within a standard filter for the_title are $title and $id. If you want to return the title from your $data array, you can do it the sloppy way using the global scope:
add_filter('the_title','myCallback');
function myCallback($title, $id){
global $data;
return $data['title'];
}
But personally, I would look into avoiding globals altogether and concentrate on utilizing custom filters. Look into Adding Your Own Hooks. After getting a handle on action hooks, Filter Hooks are pretty easy to grasp.
How can I build a block in Drupal which is able to show the node ID of the view page the block is currently sitting on?
I'm using views to build a large chunk of my site, but I need to be able to make "intelligent" blocks in PHP mode which will have dynamic content depending on what the view is displaying.
How can I find the $nid which a view is currently displaying?
Here is a more-robust way of getting the node ID:
<?php
// Check that the current URL is for a specific node:
if(arg(0) == 'node' && is_numeric(arg(1))) {
return arg(1); // Return the NID
}
else { // Whatever it is we're looking at, it's not a node
return NULL; // Return an invalid NID
}
?>
This method works even if you have a custom path for your node with the path and/or pathauto modules.
Just for reference, if you don't turn on the path module, the default URLs that Drupal generates are called "system paths" in the documentation. If you do turn on the path module, you are able to set custom paths which are called "aliases" in the documentation.
Since I always have the path module turned on, one thing that confused me at first was whether it was ever possible for the arg function to return part of an alias rather than part of system path.
As it turns out, the arg function will always return a system path because the arg function is based on $_GET['q']... After a bit of research it seems that $_GET['q'] will always return a system path.
If you want to get the path from the actual page request, you need to use $_REQUEST['q']. If the path module is enabled, $_REQUEST['q'] may return either an alias or a system path.
For a solution, especially one that involves a view argument in the midst of a path like department/%/list, see the blog post Node ID as View Argument from SEO-friendly URL Path.
In the end this snippet did the job - it just stripped the clean URL and reported back the very last argument.
<?php
$refer= $_SERVER ['REQUEST_URI'];
$nid = explode("/", $refer);
$nid = $nid[3];
?>
Given the comment reply, the above was probably reduced to this, using the Drupal arg() function to get a part of the request path:
<?php
$nid = arg(3);
?>
You should considder the panels module. It is a very big module and requires some work before you really can tap into it's potential. So take that into considderation.
You can use it to setup a page containing several views/blocks that can be placed in different regions. It uses a concept called context which can be anything related to what you are viewing. You can use that context to determine which node is being viewed and not only change blocks but also layout. It is also a bit more clean since you can move the PHP code away from admin interface.
On a side note, it's also written by the views author.
There are a couple of ways to go about this:
You can make your blocks with Views and pass the nid in through an argument.
You can manually pass in the nid by accessing the $view object using the code below. It's an array at $view->result. Each row in the view is an object in that array, and the nid is in that object for each one. So you could run a foreach on that and get all of the nid of all rows in the view pretty easily.
The first option is a lot easier, so if that suits your needs I would go with that.
New about Drupal 7: The correct way to get the node id is using the function menu_get_object();
Example:
$node = menu_get_object();
$contentType = node_type_get_name($node);
Drupal 8 has another method. Check this out:
arg() is deprecated