We have two Wordpress (3.5) blogs in a network setup. We recently installed the Custom Permalinks plugin, https://wordpress.org/plugins/custom-permalinks/. It all works fine locally (Mac) and even on production for one of the blogs. For the other blog however, changing the URL slug using the Custom Permalinks plugin, gives: "This webpage has a redirect loop". If it makes any difference (even though it shouldn't) the blog is in Arabic and the posts' URL slugs are in Arabic. I have tried:
- Just going to the permalinks admin pages and hitting "Save", it worked for some people with similar issues.
- Tried to clear cache and cookies.
- Checked .htaccess
UPDATE
If this makes any difference, I noticed that on one of the blogs on our production set up, for which I get the "too many redirects" error, if I switch to using English URL slugs, it works. This blog is in Arabic, and we are using Arabic URL slugs.
I am running out of ideas, any help would be much appreciated, thanks!
Problem is caused by the custom permalink (edited in post itself) having characters invalid for the plugin logistics (even spaces).
The plugin registers a hook:
add_action( 'template_redirect', array( $this, 'make_redirect' ), 5 );
template_redirect occurs during template load, as provisioned by the plugin's hook into add_filter( 'request', array( $this, 'parse_request' ) );.
Due to plugin not supporting encoded url's, it fails to perform the database query.
The fix was fairly simple enough.
Adding urldecode() to the spots required for proper logistics.
/frontend/class-custom-permalinks-frontend.php
Line # 167 becomes:
$request_no_slash = preg_replace( '#/+#','/', urldecode(trim( $request, '/' ) ));
Line # 369 becomes:
$request_no_slash = urldecode($request_no_slash);
Line # 432 becomes:
substr( urldecode($request), 0, strlen( $custom_permalink ) ) != $custom_permalink
Line # 440 becomes:
if ( substr( urldecode($request), 0, strlen( $original_permalink ) ) == $original_permalink
Line # 441 becomes:
&& trim( urldecode($request), '/' ) != trim( $original_permalink, '/' )
solved for me instantly.
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/
Hi I am looking how to get a permalink to a woocommerce my account page endpoint. For example edit-address or orders.
I tried this which I know can't possibly be right, it also appends a 0 onto the end of the link.
get_permalink( get_option('woocommerce_myaccount_page_id') )+"orders";
You should use wc_get_endpoint_url(), it will get endpoint value you set in Woocommerce settings so if you change it one day, your URLs will be updated.
wc_get_endpoint_url('orders', '', get_permalink(get_option('woocommerce_myaccount_page_id')))
Available endpoints are :
view-order
edit-account
dashboard
orders
downloads
edit-address
payment-methods
customer-logout
Replace your code with this
get_permalink( get_option('woocommerce_myaccount_page_id') ) . "orders";
PHP concatenation is dot symbol not plus symbol. https://stackoverflow.com/a/1866194/1593365. Your code seems right only
I'm using wordpress with Advanced Custom Fields plugin v4.4.2
I need to modify the user select fields, so that it displays not only display_name, but also the user_login.
I found the bit of code that handles this, and it is here:
wp-content/plugins/advanced-custom-fields/core/fields/user.php on line 223
And i changed the default code from:
$field['choices'][ $label ][ $user->ID ] = ( $user->display_name );
to:
$field['choices'][ $label ][ $user->ID ] = ucfirst($user->user_login) . ' - ' . ucfirst( $user->display_name );
Now, everything's working fine, but, as you probably already know, changing core files it's not the best way to modifying things in wordpress, but i have to use filters or actions.
Now, simple question, is there a filter or action that allows me to change this bit?
I searched a lot but i couldn't find anything useful.
thanks for your help.
I quickly go through this plugin and I found that (although I haven't tested this) :
There is a filter acf/load_field_defaults. This filter hook can be used for this purpose.
I found this in file core/fields/_functions.php line number 546
When non-admin users upload media, They get the following error:
Things i have checked:
Wp-content/uploads and all sub folders have permission 755.
Core capabilities and custom for a test user ( who gets this error) is set for yes for media_upload
Refer to the image below:
Deactivated all plugins, issue remains same.
To my knowledge, users were able to upload images earlier last week. No change has been done in the code since then.
If anyone has had a similar issue, I'm open for suggestions. Thanks.
UPDATE
From wp-admin/includes/ ajax-action.php, I removed the following part:
if ( isset( $_REQUEST['post_id'] ) ) {
$post_id = $_REQUEST['post_id'];
if ( ! current_user_can( 'edit_post', $post_id ) ) {
echo wp_json_encode( array(
'success' => false,
'data' => array(
'message' => __( "You don't have permission to attach files to this post." ),
'filename' => $_FILES['async-upload']['name'],
)
) );
wp_die();
}
}
I realize that this is just sort of a checkpoint to see user capabilities but I dont fully understand why removing this part helped solve the issue. Now test user can upload media successfully ( media upload was successful earlier too) and there is no permission error and "UPLOAD MEDIA" button at the bottom is not greyed any more so I can upload as normal.
Thanks
Removing core WP code isn't recommended at all!
The cause of this kind of error is often a PHP upload limit in your hosting environment. See here an example of how to change your PHP values : Change the maximum upload file size
But looking at your capabilities screenshot for posts Post Type, it seems your Role doesn't even enable to edit a post. I would first at least enable this Capability : edit_posts. And maybe some other posts-related Capabitilies.
For reference, here is a useful table to help understand Wordress Roles and Capabilities : Capability vs. Role Table
Just Update the wp-admin/includes/ ajax-action.php file, instead of 'edit_post' it should be 'edit_posts'
if ( isset( $_REQUEST['post_id'] ) ) {
$post_id = $_REQUEST['post_id'];
if ( ! current_user_can( 'edit_posts', $post_id ) ) {
echo wp_json_encode( array(
'success' => false,
'data' => array(
'message' => __( "You don't have permission to attach files to this post." ),
'filename' => $_FILES['async-upload']['name'],
)
) );
wp_die();
}
}
There are multiple solutions depending on the root cause.
One solution that seems to work if your roles get corrupted is install a plugin that edits WordPress roles. I don't know the exact role you need but I think it is one of these. I just noticed that you checked these so you might be beyond this, did you use a role editing plugin?
I would guess a user would need edit_post because uploading an image and attaching to a post IS editing the post.
unfiltered_upload
upload_files
Another solution is by adding some PHP code if you are allowed or have access to it. Add this to a PHP file, for example the header.php (temporarily) and run it.
$user_role = 'author'; // Change user role here
$contributor = get_role($user_role);
$contributor->add_cap('upload_files');
This will give the role of the author the ability to upload files.
Third solution that sometimes solves it is to try adding the full file path for the uploads directory in Settings -> Media.
As mentioned in the question update, I removed the set of code from my file and it worked for me. I am not sure how it worked and I wont recommend this solution to anyone but if you are in a bad situation, I guess you could give it a try. I am still looking for an explanation as to what changed when i removed the code. If you are a wordpress or php expert and you understand what I did, please let me know.
Can we talk about WordPress revision? How do I save the metadata revision of a WordPress Custom Post Type?
I have searched for it for endless hours today and other days, I have found one decent article about it that I will cite it below. I believe this could be helpful to many, mainly because there is not much out there that talks about this feature and how to save revisions of a meta data field. WordPress revision feature seems to be left behind sometime ago, unfortunately.
My case
In my particular case, I am creating a Wiki-style plugin that manages information of a custom post type. Besides the basic fields of a custom post type ( title, author, content, featured image), I have a few other fields that I would like to keep track of versions.
My attempt
As I already mentioned about, I have found an article by John Blackbourn (and thanks John!) from back in 2012 that pointed me in the right direction. But yet, I can't get it to work. I might be missing something, maybe I have a misconception of how WordPress revisions work, or maybe I just need to sleep on it and it will come to me in the morning. Who knows, but I truly need your help. Here is what I got so far:
To save a metadata revision of a single field, straight from the article mentioned above:
function my_plugin_save_post( $post_id, $post ) {
if ( $parent_id = wp_is_post_revision( $post_id ) ) {
$parent = get_post( $parent_id );
$my_meta = get_post_meta( $parent->ID, 'my_meta', true );
if ( false !== $my_meta )
add_metadata( 'post', $post_id, 'my_meta', $my_meta );
}
} add_action( 'save_post', 'my_plugin_save_post' );
It looks really straight forward, right? But guess what, it fails at the if ( $parent_id) {...} condition. Because $post_id isn't a revision. How is this suppose to work if it is never a revision? I don't get it. I thought the hook 'save_post' sends the current $post_id and not a child-revision. What am I doing wrong?
The save_post hook is fired when you save a post, but it gets triggered not only for the actual post but also for the revision that gets inserted at the same time.
So wp_is_post_revision( $post_id ) will return false when WordPress saves the actual post to the database, and it'll return true when it inserts the revision. This is when the code in the conditional statement will fire.