othermichael

There’s nothing like a reference to a page with 30 links to scare somebody off.

jult — for what you are looking for (and I’m guessing you’ve figured that out by now!), yes, PmWiki is probably more easily configurable. It has it’s own learning curve, of course, but the SideBars & Menus are not a part of specific themes/skins, for the most part.

>but I find the extra features of v2.x nice. ??

yeah, like Ajax bloat.

hey!!

If you’re upgrading from verison 2.3, the plugin will break, so you’ll need to fill out the options panel again. Other than you should be ok (unless you used parameters). If you’ve embedded flickrRSS in your posts, you’ll probably need to alter each one, or customize your own plugin.

Except that’s referring to upgrading from 2.3 version of the plugin to the 3.x. Dang.

Maybe you can get some more help at the flickrrss forum.

Have you tried deactivating ALL of the plugins, and then reactivating one by one? Also, try in different combinations of activation (er, don’t delete any of them yet — deletion is NOT the same thing as deactivation).

What plugins do you have?

Although the error message you posted seems to indicate that it is one and only one plugin (flickrss.php) that is generating the conflict by declarations on 12 and 15. hrm.

Just a follow-up: by following these directions, you can include a post in a page held in an external directory. Just make sure that your [Path_to_WordPress] is accurate in the require statement.

Perhaps I using the wrong terms.

An absolute URI like “/wp-content/images/2005/pwned.jpg” will always be accurate in relationship to the root, but when the “https://[site URL]” is appeneded, thigns are no longer happy when “mirroring” to localhost or changing domain names.

to do a MySQL replacement in your fields try something like this:

‘update TABLE set FIELD = REPLACE(FIELD, ‘https://www.RemoteHost.com&#8217;, ‘<replace with this string>’) ‘

If your replacement is ” (nothing) all should be well.

SHOULD be well. Try this technique on a local-copy of your DB first, to make sure you’ve got the syntax correct.

Well, I agree. Why does WP have to have absolute URLs on uploads?

When I backup up the db to my localhost, all the image-links break. As when I’ve migrated to different Domain-names.

I can MySQL-change them all, but I wish I didn’t have to.

bump.

I note that I cannot use the Links Manage in an Intranet setting to point to file resources (no “https://&#8221; prefix).

Uh, anybody? “Official” response? etc?

Er, be sure to replace ip_ with whatever your WP-prefix really is

if you use PHPMyAdmin (or another interface to your MySQL database) the following query will strip the unnecessary headers from your URIs:

UPDATE ip_links SET link_url = REPLACE ( link_url, "https:///", "/" );

This seems to be a new behavior since 1.2.1 ??? I have a number of links dating back to 1.2 (okay, not all that old) and whenver they get edited, they get the ‘https://&#8217; thrown in front of them…. which renders them totally useless.

“feature” creep!

hear, hear!

Got a request from one of my clients for this feature just today (5 minutes ago, actually). I want to minimize my involvement.

things like https:// suddenly showing up before my relative (or in-house) URIs and <h2> tags appearing where I don’t want them….

is irritating.

markup tags should not be hidden deep within the software where users cannot change them. I want to control the horizontal and vertical, and not let the software do it.

No weird conflicts, so far. Multiple level-10s are no problem.

I just wish I didn’t have to use external software to set this.