max_Q

Tested and works fine. Great job, and thanks for the props.

BTW, I’m using a little jQuery to update the buttons immediately, rather than waiting for the ajax round trip. I felt it was a more immediate response to clicking. Would you like the code?

Here’s the site if you want to see it:
https://www.lastminutelauderdale.com

Confirmed.

I can confirm that as of v1.2.0 on WordPress v3.4.1 pagination is broken. The query variable “&page=2” is stripped off the query string, sending you right back to page one of the album.

I was prepared to investigate this as some quirk of my site being on a server running with PHP safe mode enabled, but I see other people complaining of the same issue.

This is pretty basic functionality to be broken in a released plugin. I still have an urge to chalk it up to my particular setup, because I can’t understand how this plugin could make it into the wild borked in this way.

function lcfirst()
Only available in (PHP 5 >= 5.3.0)
Check your version of PHP. Might be the problem.

Hi Rob,

The new class file works fine, no problem with phrases. I like the case sensitive option.

Regards

Yeah, I thought about doing it that way. I wonder how speedy that method is on a multisite with a lot of sites. Perhaps running through a stack of rewrite conditions in an .htaccess file, one for each mapped domain, would actually turn out to be the fastest way to do it. Then you’d have to get your plugin to add the rewrite rules into the .htaccess file for each mapped domain that it found.

Regards

Hi,

Can’t get it to work. Single words are no problem, but the space seems to break it. I’m continually getting “The noise words you entered are in an invalid format.” whenever there are one or more spaces.

Regards

I tried adding the standard multisite line into the standalone .htaccess –

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

and it worked, but my understanding is that when ms-files.php is invoked it loads up WordPress with all of the associated overhead. Kind of defeats the purpose, since every page has some image component. It did seem to be slower, too.

For what it’s worth, WP Super Cache handles it without rewriting, but I don’t know how. The cached pages still have the short /files/ url. I haven’t scoured the code to see what’s going on, but it’s not supposed to be loading any pieces of WordPress when it’s in mod_rewrite mode. Here’s the addition to .htacces that it writes:

# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\”]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\”]+ [NC]
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) “/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz” [L]

RewriteCond %{REQUEST_METHOD} !POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress_logged_in|wp-postpass_).*$
RewriteCond %{HTTP:X-Wap-Profile} !^[a-z0-9\”]+ [NC]
RewriteCond %{HTTP:Profile} !^[a-z0-9\”]+ [NC]
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) “/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html” [L]
</IfModule>

# END WPSuperCache

Regards

So I installed the latest(?) development version (marked 0.9.2.2b) and I get this in my debug code:

Engine: disk (enhanced)
Cache key: _index.html
Caching: disabled
Reject reason: Requested URI has a trailing slash
Status: not cached

Ironic, huh. This is on my home (loop) page. When I go to my about page, which has no trailing slash, here’s what I get:

Engine: disk (enhanced)
Cache key: about/_index.html.gzip
Caching: enabled
Status: not cached

Not cached, no reason given. I’m logged out at the time, and refreshed a couple of times. Don’t see any files in pgcache. Seems like, one way or another, no caching for me.

Version 0.9.2.2 mentions:
Fixed bug with fancy permalinks, sites with or without trailing slashes can now cache pages using disk enhanced.

If this is the same bug it seems like it’s still happening.

Are you able to deactivate sections of the logic? I don’t think “The first post a visitor came to on his previous visit” is relevant to my site, but the other search conditions are. Also, I probably would want to control the application of any more database intensive queries on my site. It doesn’t need to be any slower than it already is!

Ah, thank you. I had forgotten about the cursed 28 pixels of the admin bar. I have it disabled in my profile on my single site, but I’m using a plugin to enable it only for admins on my multisite, so that explains the discrepancy. BTW, I’ve been using WP-Geo 3.2.3 on multisite 3.01 and now 3.1 without any issue that I’ve noticed.

Hey, on another topic, not to rip you off or anything, but I’m curious how you accomplished your “Same Region” sidebar on your site. I’m doing something where location is important, and I love the shaded circle around your post location on the map, and the list of geographically related posts. Care to share? ??

For @vickyayala and anyone else having this problem using TDO Mini Forms on a sub-site of a domain mapped, subfolder install multisite. The two problems I had above were independent and unrelated.

The first problem was TDOMF switching to run in the context of a user on the main site instead of the sub-site during a file upload. I’m not sure the precise cause of this problem, but I think it comes down to the fact that the file upload portion of the form is basically a web page running in an iframe. That webpage is called, and it’s upload action is directed to, a url defined on line 345 of tdomf.php by the constant TDOMF_URLPATH using get_option(‘siteurl’). That function expands to https://www.mainsite.com/subsite on my installation, followed by the rest of the path to tdomf-upload-inline.php. My guess, and it’s just a guess, is the TLD is being echoed in the headers of the upload page and so it runs in the context of the main site. Whatever, I got it working by replacing the reference to TDOMF_URLPATH with home_url() in two places in the files responsible for file uploads;
$inline_path = home_url() . '/wp-content/plugins/'.TDOMF_FOLDER.'/tdomf-upload-inline.php'.'?tdomf_form_id='.$tdomf_form_id.'&index='.$postfix;
around line 570 in tdomf-upload-functions.php, and
$tdomf_upload_inline_url = home_url() . '/wp-content/plugins/'.TDOMF_FOLDER.'/tdomf-upload-inline.php';
around line 100 in tdomf-upload-inline.php. The function home_url() expands to https://www.subsite.com on my mapped installation, and it corrected the plugin’s confusion.

As far as the second problem, failing at “Attempting to create directory”, that was caused by turning on “Enable Extra Log Messages” under “Debug” to try to troubleshoot the first problem. Checking that option enables a whole block of code related to debugging servers with Safe Mode enabled (which mine has), and that block of code, in my case, stops the directory creation process dead in it’s tracks. Fails without even an error message (other than “0”) in the log. Maybe because it uses realpath(), which needs executable permissions on all directories in the hierarchy. Don’t ask how long it took to find that out. That’s one week of my life I’ll never get back.

Disclaimer: Don’t take this as gospel, I’m just a monkey poking at the code with a stick. In this case I got it to work. YMMV. Good Luck.

Yes, I am having the same problem. I have a sub-folder MultiSite installation with domain mapping and two blogs. After enabling verbose logging, and adding additional code to track the process, what appears to be happening is the upload from the form on my sub-site (blog id 2) is failing quietly at “Attempting to create directory”. This is after uploading to the tmp area on the server and before creating the temporary storage area to hold the file. There is no error message, just a single “0” in the log on the line following “Attempting to create directory”. This doesn’t appear to be a server permissions issue, because when uploading from the main site (blog id 1) of my multisite install the plugin writes to (almost) the same area with no issue. Also, I’m getting no errors. The process just terminates.

Another worrying problem, which may be responsible for this failure, is that when the file upload process is initiated, in the log the user changes from my current logged in username on my sub-site to my other logged in username on my main site. In fact, if I log myself out of my main site, log in on my sub-site and try to upload a file (on a form which is set to only allow logged in users to see it) I get a “Someone with no permissions tried to access the inline-upload form!” error in the log and “TDOMF: Bad permissions” in the iframe on my form. This problem is confirmed by querying WordPress for the current_user user_login and and ID during the upload, which returns either the user logged in to the main site, or “0” if there is no user logged in to the main site. In addition, the directory that TDOMF tries to create (which fails) is named after the logged in user on my main site, not the current user logged in to my sub-site.

As soon as the tdomf-upload-inline process fails the user in the log (and in the current_user variable) returns to the correct current user on my sub-site. It seems like tdomf-upload-inline.php is operating in the context of a plugin on my main site, at least when it comes to users.

Could you let me know if you see the same? BTW, it’s network activated, created it’s tables successfully, and as far as I can tell has no other issues with multisite.

Hi Steve,

Just FYI,

I went through every url generated by Wordbooker to communicate with Facebook on my working main site, and compared them with what the variables were being populated with by WordPress MU Domain Mapping rewrites on my sub-site. Everything looked like it should have been working.

In reading everything available I came upon this statement on your website, https://blogs.canalplan.org.uk/steve/wordbooker/ :
“Wordbooker works with WordPress 3.01 in single and multi-site modes but cannot be activated network wide. This will be rectified in Wordbooker 2.0 which is currently under development.”

Now, I had not read this on the installation tab on www.ads-software.com or in the installation section of your wordbooker_user_guide pdf. When I activated Wordbooker I did use network activation. So I deactivated the plugin and reactivated it separately for each site. After that Wordbooker successfully proceeded to authorize and post to Facebook on my sub-site.

I think maybe this information should be featured a little more prominently in the installation instructions, seeing as how network activation broke Wordbooker on my sub-site. But the good news is Wordbooker works (at least as far as posting) on a subdirectory multi-site installation using the domain mapping plugin. Now I’ll be exploring things like cross-pollinating comments.

Regards

Hi Steve,

My options table option_name: site_url for the sub-site (blog_id 2 in the blogs table) shows the siteurl to be in the pattern of
https://www.main-site.com/sub-site/.
I’ll do some work on it and let you know what I find.

Regards