I have a list of latest projects displaying on the home page of my wordpress site. I can see the section that calls for the projects, but not sure where I can reverse the order.
I know this works for posts.
<?php query_posts($query_string . "&order=ASC"); ?>
but don't know where to add it. This is the code that calls the projects:
$wpGrade_Options->get('homepage_portfolio_limit') ? $projects_nr = $wpGrade_Options->get('homepage_portfolio_limit') : $projects_nr = 3;
wpgrade_display_portfolio( $projects_nr, true, true); ?>
You are probably using plugin or a theme.
You need to find this function in the plugin/theme files: wpgrade_display_portfolio
From command line you would simply do:
grep -ir "wpgrade_display_portfolio" wordpress/dir
Inside that function there is either a direct call to DB, or if writer of that script was wise built in wp get_posts, WP_POSTS, or query_posts functions.
IF you find any of these wordpress native functions than you can easily reverse order by adding:
'order' => 'DESC',
If there is a mysql query, then I will have to see it first to give you meaningful answer. I also need to see DB and how you actually would like to order things.
Related
Complete message:
Notice: WP_Scripts::localize was called incorrectly. The $l10n parameter must be an array. To pass arbitrary data to scripts, use the wp_add_inline_script() function instead. Please see Debugging in WordPress for more information. (This message was added in version 5.7.0.) in /home3/dduconne/public_html/wp-includes/functions.php on line 5313
Appeared just after updating wordpress to 5.7.0
Ok since there quite a few views and the previous answer just throws it under the rug.
Yes it is a warning now, but who knows what will happen, it is a warning for a reason, disabling something is not resolving it, there is a reason devs set it as a warning for now.
While we wait for plugin developers to resolve it on their ends, you can find out the source of the problem by enabling php_xdebug in php. I recommend not leaving it after debugging, as I am not sure about the performance cost of it being enabled.
php_xdebug will return a stack of all files affected, from there you can trace it to the source of the problem. The fix once found the source is quite easy. Culprit most likely is wp_localize_script() which requires last parameter to be an array()!
So you would find something like this:
wp_localize_script( 'handle', 'object_name', 'l10n_culprit_string' );
Which should be turned into:
wp_localize_script( 'handle', 'object_name', array( 'l10n_culprit_string' ) );
Solution to problem came from here
This is a new warning appearing in Wordpress 5.7. If you don't want to see it, and still want to have WP_DEBUG set to true, it is possible to disable the message by adding the following for example in your theme's functions.php:
add_filter('doing_it_wrong_trigger_error', function () {return false;}, 10, 0);
It is now a notice if you are using wp5.7 and php7.4, but changing to php8 it may gets reported as error. For me, when i changed (in my own code) the passed value to array (yes, probably some changes also needed in the involved js), everything worked just fine.
This is because one of the PHP script in your wordpress installation uses wp_localize_script() to pass some PHP variables to a JS script through AJAX request, and it's not good practice anymore.
This can be inside a plugin or inside your custom theme or child-theme's functions.php.
If wp_localize_script() is not in a child-theme or custom theme's functions.php, try this :
backup your website
deactivate all plugins
reactivate them one by one until you get the notice again
when the notice shows up again, this means the plugin you just reactivated uses wp_localize_script() the wrong way
if it's not up-to-date, try updating it (if you want to) : maybe the notice is going to disappear
if it's already up-to-date, or you don't want to update it, search inside wp-content/plugins the corresponding plugin's folder
open it and try to find the file(s) where wp_localize_script() is called, you can also use CLI with your server's terminal to find string in files. For example, if your server runs on Linux : grep -H -r "wp_localize_script()" /root/pathtopluginfolder | cut -d: -f1
Then, replace the code as follow :
Old one should look almost like this :
wp_enqueue_script( 'wpdocs-my-script', 'https://url-to/my-script.js' );
wp_localize_script( 'wpdocs-my-script', 'MYSCRIPT', array(
'ajaxUrl' => admin_url( 'admin-ajax.php' ),
'otherParam' => 'some value',
) );
New one :
wp_enqueue_script( 'wpdocs-my-script', 'https://url-to/my-script.js' );
wp_add_inline_script( 'wpdocs-my-script', 'const MYSCRIPT = ' . json_encode( array(
'ajaxUrl' => admin_url( 'admin-ajax.php' ),
'otherParam' => 'some value',
) ), 'before' );
Note that you need to add 'before' as the third parameter to the wp_add_inline_script function.
Once it's done, the notice shouldn't show anymore. If so, contact the plugin dev to tell him about this so that it can be part of the next update.
For more informations, see Jules Colle's comment on this page : https://developer.wordpress.org/reference/functions/wp_add_inline_script/
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);
I am creating a blog using only Wordpress's backend. I have found functions to get latest posts (wp_get_recent_posts) and all the required data I need. I do this by including wp-load so I have access to WP's functions.
However I cannot find anything that allows me to perform a search outside of Wordpress's theming loops as I have for the rest of the data.
I was hoping there was a search function where I can pass it a search query that could be in title, body content or tag name.
Am I missing something blindingly obvious in the documentation, there seems to be a function for everything else I need outside of WP's "loop".
Does that work for you?
// query for a given term ("search_term")
$search_query = new WP_Query();
$search_posts = $search_query->query('s=search_term');
Source
Answered by sanchothefat:
You can use get_posts() with a search parameter:
$results = get_posts( array( 's' => 'search term' ) );
https://wordpress.stackexchange.com/questions/74763/search-outside-of-the-loop/74766#74766
I'm developing a Wordpress plugin that requires updates, although the plugin version is being checked from my server. There are several plugins that I have developed which use the exact same server to check for new versions. The problem I'm experiencing is that when all the plugins require an update and I click View Details, one of the plugins will show details of the update (version, description, and etc), but the other plugins won't show any information. After some debugging I can see that the server is returning data for sure.
My question is, how can I apply the plugins_api filter multiple times without it conflicting with the other plugins?
Your observation is right. It is not obvious. Even the book of Brad and Ozh (Plugin development ed. Wrox) includes an error in the example on page 267 in the chapter "make your own API repository".
Like you, I spent (lost) time to find the issue with a two plugins in alternate API...
The solution:
Remember that that first parameter in the WP filter is the original value passed to the filter.
So to concatenate the filters (listed by plugins using alternate api)... the first line must be:
function xiliw_altapi_information( $false, $action, $args ) {
$plugin_slug = plugin_basename( __FILE__ );
// Check if this plugins API is about this plugin
if( $args->slug != $plugin_slug ) {
return $false; // var to conserve the value of previous filter of plugins list in alternate api. fixes book error not val false
}
// POST data to send to your API
$args = array(
'action' => 'plugin_information',
'plugin_name' => $plugin_slug,
'version' => $transient->checked[$plugin_slug],
'registration' => $this->registration
);//../..
By doing this test, each time the list of hooks is called, only one - the concerned plugin - gives the right answer to display the information for the splash window.
If I have time, I probably will publish soon a more complete article about a class to manage this alternate powerful API and how to add it to a -private- plugin.
Good morning all.
I'm having some issues while trying to make the function "field_file_load" work in a php script I've done to process an AJAX call.
I've read about bootstrapping drupal core elements inside, but it doesn't seem to work.
So far I've succesfully populated a Select Box using the data from another Select Box, making an AJAX call to this php file (which is in the drupal directory folder, in a theme to be precise)
<?php
$var = $_GET['q'];
$con = mysql_connect('*******', '******', '********');
if (!$con)
{
die('Could not connect: ' . mysql_error());
}
mysql_select_db("drupal", $con);
$sql="SELECT DISTINCT xc.field_brand_value FROM node
INNER JOIN term_node AS tn ON node.vid = tn.vid
LEFT JOIN content_type_extra_content AS xc ON node.vid = xc.vid
WHERE tn.tid IN (SELECT th.tid FROM term_hierarchy AS th WHERE th.parent = '149')
AND xc.field_location_value = '".$var."'";
$result = mysql_query($sql);
echo(' <select name="brand" id="brand">
<option value="default" selected>Select a brand</option>
');
while($row = mysql_fetch_array($result))
{
echo('<option value="'.$row['field_brand_value'].'">'.$row['field_brand_value'].'</option>');
}
echo('</select>');
mysql_close($con);
?>
And this is working like a charm because all I have to do is connecting to the drupal db and fetch the desired values.
The problem arises when I want to fetch the url of some pictures (with a query that uses values from the first and second dropdown) and use the "file_field_load" to load the url of the given picture.
I get (obviously) a "call to undefined function" error.
So I tried bootstrapping drupal.
But it doesn't work anyway.
/** bootstrap Drupal **/
chdir("/path/to/drupal/site/htdocs");
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
Since I don't have full access to the server where the site is hosted, assuming that drupal is convenientrly installed in the root, how can I figure out the path to drupal site htdocs ?
Moreover, does calling a full bootstrap (instead of just the needed part) can cause some problems?
So, to be brief:
1] how can I call a drupal function (in this case which comes from the filefiled module) in a non-drupal php script which resides however in the drupal directory?
2] Which is the correct way of bootstrapping?
3] Do I need to connect to the db (like in the previous working example) IN ADDITION to bootstrapping?
Or, finally. there's a different, speedier way you know how to do what I need to do?
Thanks in advance for any reply.
Hmm that's weird. If the FileField module is enabled, the function should be available. So maybe FileField is not actually enabled?
If that's the case you're gonna have to manually add the file that contains the function definition, which is the field_file.inc file in the module's directory, so you'd add that dependency to your bootstrapping code:
<?php
/** bootstrap Drupal **/
chdir("/path/to/drupal/site/htdocs");
require_once './includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
module_load_include('filefield', 'inc', 'field_file');
AFAIK what you're doing for bootstrapping Drupal from an outside script is the "correct" way.
Now, I'm not sure if, on a big picture level, whatever you're trying to do is a good idea at all... That is: You're making a little nonDrupal script which:
manually connects to the Drupal database with plain mysql functions instead of Drupal's DB API functions, in order to
fetch CCK information using a query that's 100% vulnerable to SQL injection, and
all of this put in a theme directory no less!
So you might want to rethink your angle of attack here, you know?. Maybe making a custom module for this.
But if you just have to do things this way (for reasons I can't think of), then at least use db_query so you don't have to do the whole mysql_connect() stuff, and do something like
<?php
db_query("YOUR BIG QUERY HERE... xc.field_location_value = '%s'", $var);
...for at least some degree of security.
I would also recommend that you browse the involved modules a bit (FileField, etc) to see if they have APIs (or at least some internal functions) that might return what you're trying to get through plain DB querying.