monkeyhouse

Ew my gawd.

I had a typo in my function. That’s all it was.

D’oh!

So much hope! Crushed into dust… ??

This didn’t work for me. Here’s my scenario:

Instead of using functions.php for custom functions, I add them to a plug-in. So, inside the PHP for the plugin I have soemething like:

add_action('get_header', 'my_method');
function my_method() {
  if (is_home()) { //have also used is_page('home') to no avail
    ..do stuff..
  }
}

The “stuff” in question is bit of enqueuing and localizing scripts as well as supplying a function for processing AJAX calls. I will fall back to calling it from the header, but I’d rather not, mainly because the client hasn’t settled on a theme and by moving the custom functions plugin, I can have custom development be more instantly portable (vs. editing the header each time).

Any advice would be awesome. Even a totally different way to enable WP Conditionals for use inside a neo-functions.php file.

In my case it was the deregistering and re-enqueuing jQuery. I was not using the !is_admin() conditional described by cxd.

It could have taken a while to debug, too, since I did that all in a plugin outside of the theme (in a mu-plugins folder); however thankfully I was smart for a change and searched the entire project folder for the text ‘wp_deregister’ and quickly found it.

Cheers for the solution; saved me a major headache!

Well, I’ve gotten somewhere.

Our site redirects from site.com to https://www.site.com (I know, it really should be the other way around; not my call!). I don’t know why, but people who visit site.com (and get the redirect) can’t access the page properly.

It’s a bit unseemly to complain too much without offering a fix, but it strikes me that the page-based password protection is super-fragile if that’s all it takes to break it. A friend helping me to identify the issue also noted that if you password-protect multiple pages with the same password, you can access them all. In our opinion, you should be asked for the password each time, which further points to the idea that this particular feature isn’t implemented ‘properly’.

Off to the bug-tracker…

Sorry for the bump, but just wanted to see if anybody out there may have run across either the problem or the solution. It held up more people over the weekend, meaning I have to now make that page public, which obviously wasn’t part of the original site design.

There’s obviously some sort of bug, but I hesitate to make an official bug report without reproducible steps. I don’t honestly KNOW why some people are being redirected to the wp-login, and I can’t reproduce in my local environment. I’m hoping someone out there has reproducible steps so that I can file a proper bug report. ??

I’m having an identical problem to hdhd411. However, I’m a bit thrown off by the terminology and unsure how to solve.

What does the “display name” refer to that could be causing a mismatch? Also, when there’s a mismatch and a page can’t be found, wouldn’t a 404 be displayed instead of a login page?

I have a protected page, and only SOME of the users see this exact problem, though. Two people, both with Win7 and Firefox 3.6 (identical sub-version), and one person sees the problem and the other does not. It seems to be some sort of setting on the client side more than anything. A session within a session? I don’t really know.

All I know is that the functionality is a bit broken right now, and the page I’m trying to protect is critical for a certain category of end-users. If it doesn’t work for 100% of the people using it, there’s a big problem. I would use something traditional like .htaccess to protect the page, but as you know there’s no physical asset that I can protect; it’s content being served through a php application tied to a database!

Assuming I get the terminology sorted out, is there a way to “re-create” these pages so that the ‘display name’ and URL line up?

Thanks!

citizenchan: glad to have helped!

ulf: the forum itself has some answerin’ to do. ??

Well I guess I’m a stubborn so-and-so, but I found it. Looks like my search tools just didn’t find the text string I was searching for. Not sure why I trusted Desktop search instead of just firing up Notepad++ or an IDE.

In any event, the problem is in this function in the main file (wp-dtree.php):

function wpdt_js() {
	if(is_admin() || is_feed()){return;}
	$opt = get_option('wpdt_options');
	$deps = array();
	if($opt['animate']){
		wp_deregister_script('jquery');
		wp_register_script('jquery', 'https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js');
		wp_enqueue_script('jquery', '', array(), '1.4.2', true);
		$deps = array('jquery');

You can see that if the animation option is true (selected), the plugin will deregister, reregister, and enqueue jquery. What the original developer or Ulf may not have taken into account is that if the end-user is using enqueue for their other scripts (and they SHOULD be), this version will always take precedence.

The way to handle it is to simply enqueue jQuery, full-stop. I imagine there could theoretically be an ‘if’ statement somewhere that tests for jQuery first, but I think that would be a waste of cycles since jQuery is already enqueued to the ‘internal’ version, and the place to deregister and re-register it is typically in functions.php. In other words, someone has to actually go out of their way to have no jQuery, in which case they’re probably not using the animate function of this plugin anyhow.

I can’t claim to be an enqueue expert, so I’m not sure if there’s any value in passing the optional parameters, either, so I’m only passing it the ‘jquery’ handle for enqueuing.

The resulting code should simply be this:

function wpdt_js() {
	if(is_admin() || is_feed()){return;}
	$opt = get_option('wpdt_options');
	$deps = array();
	if($opt['animate']){
		wp_enqueue_script('jquery');
		$deps = array('jquery');

Hope this helps somebody some day. ??

Still didn’t give up yet… I’m hoping I can find the solution so that I don’t have to burden you with it… but coming up short.

I’m using only one of the widgets, and it turns out that it didn’t even have cache enabled. So maybe the cache is barking up the wrong tree again?

OK, I’m stumped. ?? I poked around a bit and found a method that drops the tables when there’s a change. Simple, it gets the DB, retrieves the DB name, and then issues a DROP.

I mimic this by going into MySQL, finding the table, and dropping it. The Google 1.4.2 still appears on refresh.

Wish I could have been more help!

Now that I’m digging a bit deeper, I see that there’s a wpdt cache. I suspect it’s actually the caching mechanism that’s causing the headache.

If there’s no way to change the enqueue method, perhaps a button to clear the cache on demand, without needing to update the site to do so?

This forum is brutal… but just in case someone else ever reads this, might as well post the solution.

As suspected, the short PHP function 2 replies above was the culprit.

By replacing it with:

<?php the_content(); ?>

The whole issue was resolved.

Seems to me something that anybody with more than my beginner’s level of knowledge would have known. Surprising and disappointing that this forum couldn’t come up with the answer….

Greg

*sigh* Lost in the huge and enormous WP.org forum…

A different tack, then–

Which pages and functions would go into the building of a page using the template “about”?

I see:

header.php
about.php
footer.php
functions.php (in theme directory)

Since the plug-ins work in other themes, it won’t be related to any code outside the theme directory that I’m aware of. But that might be a false conclusion?

Greg

Actually, I wonder if it’s right in these few simple lines:

<div id=”subcontent2″>
<?php
global $post;
echo nl2br($post->post_content);
?>
</div>

Without using the php n12br function, there’s still no love (“echo $post->post_content” just generates a block but still no plug-in). But is the $post->post_content correct?