Tag Info

New answers tagged

0

You should do it with after_setup_theme action: function remove_inactive_widgets() { $sidebars_widgets = get_option( 'sidebars_widgets' ); $sidebars_widgets['wp_inactive_widgets'] = array(); update_option( 'sidebars_widgets', $sidebars_widgets ); } add_action( 'after_setup_theme', 'remove_inactive_widgets' );


1

There are two ways to see it: Sidebar as a general area of site layout Sidebar as container, filled with WordPress widgets Or maybe combination of the two. The prime reason to use WordPress widgets is that they provide roughly consistent experience, can be easily used multiple times, and can be enhanced with related functionality (such as ...


0

Can I use this function (wp_get_sidebars_widgets) if the WordPress codex tells me it's marked as "private"? (here) Best regards, Gabriela


0

This is mostly a case of trusting the arguments. Or not trusting. You can assume that you have received meaningful arguments, ready to be used. You can assume they are arbitrary and possibly grossly invalid. I would say in this specific case it hangs if the code is public or private. In private site you have the full control over it, from sidebar ...


0

I think the simpelest solution would be to use the generated RSS-Feeds and integrate them somehow with an RSS Widget Plugin. A plugin search could help you here, I guess.


0

That's expected behaviour, since you're calling wp_enqueue_script mid-page, so at that point the <head> ship has sailed, and the only other option is to enqueue in the footer, which is fine. I didn't spend too much time reading the actual script that you're enqueuing, but it seems like it it's doing some document.write() as soon as it's loaded, which ...


0

Change this code add_action( 'after_setup_theme', 'right_sidebar_widget' ); with add_action( 'widgets_init', 'right_sidebar_widget' );


-1

Neither wp_enqueue_style() nor wp_register_style() have a parameter to allow them to be loaded in the head, rather than the footer, as their script counterparts do. The only solution is to have some of your CSS (or all of it - which would be bad) inside a style tag inside head, added with the wp_head action hook. I used this technique for a while but at some ...


0

With your code given in OP, it is hard to exactly tell you where you are going wrong. One note on what I can, you should never use create_function(), it is a security thread that can be exploited by hackers. You should avoid using that completely. Rather make use of proper closures that was introduced in PHP 5.3. To help you, here is a basic skeleton which ...


0

I was having the exact same problem while querying post and pages, but also the jetpack-portfolio post type in my custom widgets. I was using $query = new WP_Query( $query_args ); in both cases. For me the fix was to change $query to $query_entries and $query_projects. It works as expected now. I see you're already using $products, but maybe it conflicts ...


3

widget() method is called when widget is rendered, so the style you're enqueuing are printed in the footer (header is already printed at that time). Even if majority of browser can render styles linked from page body, that's invalid HTML because, according to HTML standards, unlike scrypts, styles must be placed in page <head>. (Try to validate your ...


0

I just understood what happened: The custom widgets were using short tags (<?) to split up the HTML output, which directive (short_open_tag) is disabled by default in the production environment. Problems like this are a pain to spot and I can do nothing but laughing thinking what we tried to understand the issue.


0

This is more of a pure PHP than WordPress. You are implicitly creating $ranNum as local variable in function scope. $Example_Widget won't access widget instance in PHP. What you should be using is $this->ranNum, for reading and writing. That will create object's property implicitly, but you likely should declare it explicitly in your class definition ...


1

Thank you all. I just took code from codex, I've changed id footerBoxOne to footer-box-1 for all four widgets, and it's working now. I guess uppercase chars were the problem


0

The output from a shortcode should be returned, not echoed. Echoing output in a shortcode will have unexpected output like you are seeing. the_widget() echos its output which is causing the issue. Unfortunately there is no similar function for returning the wdget output. Luckily you can make use of a output buffer to overcome this issue. You can try ...


2

the_widget() is used to display a specific widget outside of a sidebar. To be honest, this function serves no valuable purpose as you need to hard code the widget $instance parameters, this means that you will need to manually change the code every time you need to change something. So much for dynamica. It would just be easier to simply code a custom ...


5

Via using the dynamic_sidebar() you can change/edit the widgets in the widgets area of the appearance settings. If you use the_widget() you hard code it straight to template so you need to modify the code to change what is displayed. Both have their uses. Too many sidebars tend to clutter the widgets area, but is very good for users that don't want to mess ...


0

This needs to be implemented at the widget code level for which the code in the question you start with is not a good match. The easiest way might be to decouple the widget content editing and the widget placement. You can set up a specific page in which it is possible to manage the content of the widget, and set the access level to that page to one which ...



Top 50 recent answers are included