korythewebguy

We recently had this same issue (all users would get locked out by JetPack) because we use nginx + Varnish in front of Apache on our hosting server.

I looked within /plugins/jetpack/modules/protect/shared-functions.php and found the jetpack_protect_get_ip() function, which seems to defer to a WP option, called trusted_ip_header, in order to decide which key to use from PHP’s $_SERVER array.

Since our server reports the public IP using $_SERVER['HTTP_X_REAL_IP'], I simply changed the option within the database to be ‘HTTP_X_REAL_IP’ instead of ‘HTTP_X_FORWARDED_FOR’.

Now everything works great, and the issue is resolved. ??

My question is this, though: Is there a way that I can ensure that Jetpack won’t change that option back to ‘HTTP_X_FORWARDED_FOR’? ??

Thank you!

@rossagrant – You’re the man!

Taking <input type="hidden" name="testcookie" value="1" /> out of the code for the login widget solved the problem immediately.

Much thanks!!

I appreciate your concern, WPwebbouw – Quite honestly, though, I found the $settings['webkit_fake_resize'] = 1; snippet on some blog (for which I cannot remember the name) on the Internet, and expanded upon it slightly by adding the filter function.

I also didn’t have anything to do with authoring/contributing to the the TinyMCE JS function(s) which $settings['webkit_fake_resize'] = 1; enables that makes the Webkit-magic happen.

As I see it, the nature of all WordPress-related code is that it stands on the shoulders of the GNU General Public License, so while I could put my name/pseudonym to something, in actuality the only credit I can take is the effort put into it; the code itself is really not mine in any way.

I’m really just happy that I could offer something to the community that is benefiting others ?? Whether that just makes things a little easier to use and/or puts a few dollars in their pocket, either way I’m glad it did something for someone somewhere.

The best fix is to upgrade to IE9 or IE10, or use Google Chrome or Firefox instead.

If you were a desktop app developer, and someone called and insisted “We run Windows XP in our office and your program doesn’t work!”, or *”Our office uses OS X 10.4 and and your program doesn’t work!”*, you’d probably take a deep breath and explain to them they were 7 years behind the times, and that there’s a minimum-expected standard of technology they need to meet to use the latest software.

IE7 is far past it’s shelf life, and IE8 will be coming up on it’s end-of-life as well. Less than 1/8 of the entire Internet is using Internet Explorer (any version) now, with Google Chrome being the dominant browser.

I’m not trying to be a jerk, nor am I a developer of the “Front-End Editor” plugin, but anyone who insists that Internet Explorer 7/8 be supported is obviously not terribly computer savvy and needs to be given a wake-up call.

UPDATE #2:

Today I decided to try to resolve the JavaScript error myself, and for whatever reason, it isn’t happening now. I cannot for the life of me figure out how or why it’s suddenly resolved.

I cleared the cache and sessions from each one the browsers I tested this in (IE, Firefox and Chrome) yesterday when trying to duplicate the issue, and no matter what I did the div is not defined error kept happening.

Then out of the blue today, everything just works.

Can anybody, or perhaps one of the NextGen Gallery devs, shed some light on why?

Update #1

I’ve (sort of) fixed the issue where 2 appointments are added instead of just 1.

It turns out that the $wpdb->query($AddAppointment_sql) line is being run twice when an appointment is submitted. I believe this is because I am using PHP output buffering ( ob_start(); ) but cannot confirm this until I have tested things further.

For the time begin, I’ve fixed the issue by changing this line…

if( $wpdb->query($AddAppointment_sql) )
{

… to this:

$key_exists = $wpdb->get_var('SELECT id as "true" FROM '.$wpdb->prefix.$table_name.' WHERE appointment_key = "'.$appointment_key.'" LIMIT 1');
if( $key_exists != "true" && $wpdb->query($AddAppointment_sql) )
{

This isn’t the most elegant way to fix the problem since it adds another DB query to the process, but everything seems to work fine now.

Like I said above, I’m going to do some more testing and modify some code to see if I can’t help the authors out a bit.

I thought I’d update this post and note that as of “Custom Field Template” version 2.04, the conflict with “Ajax Event Calendar” appears to have been resolved.

As such, the code-hack described above is no longer necessary – My sincere thanks to Hiroaki Miyashita for this truly fantastic plugin, and for working to resolve the issue!

Eran and I recently looked into this conflict, and I have posted a feasible solution that allows Custom Field Template and Ajax Event Calendar to both work without having to disable Custom Field Template’s date-picker functionality:

https://www.ads-software.com/support/topic/solution-conflict-work-around-for-ajax-event-calendar-custom-field-template?replies=1

Well, I figured it out… I think.

The element seems to actually be part of the Mozilla code, technically referred to as a “grabber”, and comes from within the Mozilla built-in WYSIWYG resources.

Here’s the breakdown:

*[\_moz_resizing] ? Class applied to an element being resized
*[\_moz_abspos] ? Class applied to an absolutely-positioned element
span[\_moz_anonclass="mozGrabber"] ? The class for the “absolute position” handle (aka “grabber”) I referred to above.

Using the Firefox ‘Web Developer’ plugin, I noticed the classes _moz_abspos and _moz_resizing being added to absolutely-positioned elements when I clicked on them.

Plugging those classes into Google led me to find a CSS file called “EditorOverride” that’s being used on the OpenCD project.

As it turns out, these elements can still be styled with CSS. ??

So I just inserted the following into the /plugins/tinymce-advanced/css/tadv-styles.css file and now the grabber is layered above everything else:

span[\_moz_anonclass="mozGrabber"]{z-index: 2147483646 !important;}

WORTH NOTING: I used the number 2147483646 because Mozilla WYSIWYG assigns a z-index of 2147483645 to the absolutely-positioned element. Also, 2147483647 is the maximum z-index in most web browsers because it’s the largest possible 32-bit integer value. Any number higher than 2147483647 will automatically revert back to 2147483647.

Did you run https://www.WhateverYourSiteIs.com/wp-admin/update.php ?

First, what are the DB used for?

The DB is your “database”. Think of a database like a collection of Excel spreadsheets, and each spreadsheet (which we call a “table”) holds certain pieces of info. For example, the “users” table holds info like username, first/last name, e-mail address, and scrambled passwords.

One DB is capable of holding over 1000 tables, though you will usually only have (or need) less than 100 tables.

Secondly, is that enough for me?

If you only need to be able to run 1 website on the hosting package, it would likely be fine.

On the other hand, if you’re a developer like me, you may eventually want to try out new web applications or setup “test bed” sites for your clients to view. For this, it’s always best to give each installation it’s own DB, so that each is confined to that DB.

You could install several web applications and have them all rely on 1 DB, but to me that’s a security issue, because if any of those applications got hacked (or had bad code) it would give the hacker access to ALL of your other tables, or the tables could be accidentally modified/deleted.

When I install on godaddy servers.

Dear God, please tell me you’re kidding. ?? Do not use GoDaddy for ANYTHING – They are to “web hosting” like AOL is to “Internet service provider.” Seriously, if you just signed up with them, call and get your money back.

Just my suggestion… Take a look at HostGator. ( https://www.hostgator.com ) They have excellent servers and give you UNLIMITED space / bandwidth / databases / e-mail / etc. for around $9.00/month without a contract. (Also, add the coupon “slickdeals” at checkout, and you’ll get a $25.00 credit, which is like 2 free months.)

I’m submitting this to the “Ideas” section if it’s not already there – Useful as exclude_tree is, it would be nice to also have an exclude_children argument for wp_list_pages that excluded ONLY the children and not the parent as well.

Update 5/12/09:

After some research, it seems that this is a limitation of PHP. The limitation is not expected to be remedied because many sysadmins feel this is a security feature to prevent massive SQL injection attacks.

While PhpMyAdmin appears to be able to run multiple statements at once, in reality it’s because phpMyAdmin parses the statements into individual queries, then runs them.

For the moment I guess I’ll just accept this and look for a work-around, but I’m greatly hoping someone will come along and prove me incorrect.

Many thanks to everyone who has taken the time to read this, and even moreso to those who offer suggestions or information.

Great revisions, janapriya – Thanks for making note of them!

Here’s the snippet from above, but with janapriya’s update to ensure only PUBLISHED top-level items are shown, and shown according to the WordPress menu order:

<?php
	// Query the database for all top-level page IDs, and store them in the $menuPages array under the [ID] sub-array
	$menuPages = $wpdb->get_results("SELECT ID FROM $wpdb->posts WHERE post_parent=0 AND post_type='page' AND post_status='publish' ORDER BY menu_order ASC");

	// For each element in the $menuPages array, get the value from the [ID]-subarray to create the top-level menu and it's children
	foreach($menuPages as $menuItem){
		$menuItemTitle = get_the_title($menuItem->ID);
		$menuItemPermalink = get_permalink($menuItem->ID);
			if (isset($menuItemTitle)){
				_e('<dl class="dropdown" id="wpMenuItemID_'.$menuItem->ID.'">'.PHP_EOL);
				_e('<dt id="'.$menuItem->ID.'-ddheader" onmouseover="ddMenu('.$menuItem->ID.',1)" onmouseout="ddMenu('.$menuItem->ID.',-1)">'.PHP_EOL);
				_e('<a href="'.$menuItemPermalink.'" class="topLevelLink">'.$menuItemTitle.'</a>'.PHP_EOL);
				_e('</dt>'.PHP_EOL);

			// Run wp_list_pages to fetch any children, and put the HTML <LI> list results into $menuItemChildren as a string
				$menuItemChildren = wp_list_pages('title_li=&echo=0&depth=1&sort_column=menu_order&child_of='.$menuItem->ID);

			// If results were returned, $menuItemChildren is now a string with HTML in it, so create a drop-down and echo out the HTML
				if($menuItemChildren){
					_e('<dd id="'.$menuItem->ID.'-ddcontent" onmouseover="cancelHide('.$menuItem->ID.')" onmouseout="ddMenu('.$menuItem->ID.',-1)">'.PHP_EOL);
					_e('<ul>'.PHP_EOL);
					echo $menuItemChildren . PHP_EOL;
					_e('</ul>'.PHP_EOL);
					_e('</dd>'.PHP_EOL);
				}
			// Otherwise, let's call it a day... err, end the loop.
				_e('</dl>'.PHP_EOL);
			}
		}
?>

While it’s a solution, it’s a pretty lame solution (not to point blame at mfields) and for two reasons…

• External links have to be hardcoded into the template, undermining WordPress’ dynamic nature
• External links are forced to either the beginning or end of the menu, and cannot appear anywhere in between without considerable CSS tweaking

Next version of WordPress needs to have this functionality built-in. (Or I suppose someone could just create a plug-in…)