wersh

I figured out how to do it.

In navigo.php, line 172 should be similar to this:

$content .= '<a' . $current . ' href="' . get_page_link($page_id) . '"
title="' . wp_specialchars($cur_page['title']) . '">' . $cur_page['title'] . '</a>';

Change that to this:

$title = apply_filters('navigo_title', $cur_page['title']);
$content .= '<a' . $current . ' href="' . get_page_link($page_id) . '"
title="' . wp_specialchars($title) . '">' . $title . '</a>';

Then in polyglot.php, somewhere around line 100-115 you should find the list of filters. Add this somewhere in there (or anywhere in the file, really):

add_filter('navigo_title', 'lang_picker_respect_more',1);

The nice thing is that this doesn’t break anything if you only have one of the two plugins activated for some reason. ??

The post is now located at https://etc.ecordero.net/index.php/archives/2004/08/17/5/ . The download links to get the script are currently broken, but I left a comment telling the author about it so hopefully they’ll become available again.

Actually, I created a plugin that drops Qdig into WordPress — called Qdig-WP. It requires the devel version of Qdig at present, and as the plugin’s only recently released I can’t claim it’s fully stable yet, but you might find it worth taking a look at.

If there’s some features you’d like to see added to it, or if you find any bugs, please let me know and I’ll look into it. ??

I wanted to do the same thing and fought for a while before I could get it to work, but it seems to be working okay now. Here’s how I do it:

Install wordpress in /wp.

Create a static page in your root with a slug named “home” (or similar) that you want to be the index to your root.

Go to Options in the admin panel, then to Permalinks, and make sure that both the permalink and the archive items start with /blog/ (or whatever section of your site you want your blog stuff to go in).

Go to Options in the admin panel, then to General and change Blog Address from https://example.com/wp to https://example.com

On your webserver, go to the root directory for your site and in your .htaccess, put the following:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ – [S=2]
RewriteRule ^blog/?$ /wp/index.php [QSA,L]
RewriteRule ^(.*)$ /wp/$1 [QSA]
RewriteRule ^$ /wp/home [QSA]

If the request is for a file that really exists, the above does nothing. If it is requesting exactly /blog/ it will show your base blog page (recent posts). If it is any other non-blank request, it will redirect to the /wp directory, where the rewrite rules there will take care of it. If it is a blank request (ie, they just went to the domain without a page request), it redirects them to the static page “home” you created.

I *think* that’s everything I did. If it doesn’t work let me know and I’ll try to figure out what else I might have done.

Important note: If wordpress is installed in /blog/ and you try to have rewrite rules going to things that start with /blog/ then it won’t work because those files actually exist and the bit at the beginning of the rewrite rules will skip it.

Good luck!

Ugh, I just figured out why my other error is occurring. It’s because the scripts are using the _SERVER[“SCRIPT_NAME”] variable all over the place… which means there’s errors all over the place when PHP is run as CGI. This causes links to show up wrong, it messes up the logic in a number of places, and who knows what else.

However, I think I found a solution to this problem (which doesn’t involve rewriting the scripts or disabling the run PHP as CGI option!). In exhibit10.php, add this line right before the line that says “/***** DON’T MODIFY BELOW HERE *****/” (around line 38):

$_SERVER['SCRIPT_NAME'] = $_SERVER['SCRIPT_URL'];

You might also consider adding the same line to wp-config.php to make sure other plugins that use the same coding practices will work. However, that will not work in this particular case because exhibit10.php is directly accessed as a page of its own (in the inline frame on the edit post page, for example).

Sorry for making so many posts in this thread… but hopefully this will help someone else who is having a similar problem.

Aha! I solved part of the problem! My server runs PHP as a CGI module, and that’s why it wasn’t working. In exhibitimg/exhibit10i.php around line 267, you see this:


if(preg_match('|post.php|i', $_SERVER['SCRIPT_NAME']))


On my system, _SERVER[‘SCRIPT_NAME’] is always “/cgi-system/php.cgi”, which obviously does not match “post.php”. To make it work, I just had to change it to something that actually contained the page’s name; I used _SERVER[“PATH_INFO”] and that worked for me. I would expect that these would also work: _SERVER[“PATH_TRANSLATED”], _SERVER[“REQUEST_URI”], _SERVER[“SCRIPT_URI”], or _SERVER[“SCRIPT_URL”]. In any case, here’s what the line looks like when I replaced it:


if(preg_match('|post.php|i', $_SERVER['PATH_INFO']))


This made the box show up and I was able to install the database table. I’m still getting an error in the one inline frame that says Fatal error: Call to undefined function: add_action() in /path/wordpress/wp-content/plugins/exhibitimg/exhibit10i.php on line 38, though.

I’m having the same problem — the exhibit section is not showing on my edit posts page. (Yes, I edited an existing post — it’s not there.) However, if I go to an existing page’s permalink, I get this error:


Database error: [Table 'db.wp_exhibit' doesn't exist]
SELECT ID FROM wp_exhibit WHERE post_ID = 2 and preview = 1 ORDER BY picorder;


I’m using Exhibit 1.1d, WordPress 1.2.2, PHP 4.3.10, and Apache 1.3.31 under Linux.

I’m running into this problem on a fresh WordPress install. The only modifications I’ve done is to install the AuthImage plugin; I continue to have the problem with it disabled, though.

I fought with the issue of it redirecting to /index.php as well. It’s hardcoded in the plugin. If you want it to automatically generate .htaccess rules for /wp/index.php, then you’ll have to search for the places where /index.php?static appears in the plugin file (there are four spots) and manually change them to /wp/index.php?static. Or at least, that’s what I ended up doing to get the .htaccess rules to work. *shrug*