cmarshall

Okay, that went pear-shaped. WP completely ignores this:

<?php
/*
Plugin Name: localhosts
Plugin URI: https://sasna.org/
Description: Makes things local, for testing.
Version: 1.0
*/
function GetMainURI( $ret )
    {
    if ( preg_match ( '|10\.211\.55\.2|', $_SERVER['REQUEST_URI'] ) )
        {
        $ret = "https://10.211.55.2/.../public_html/main";
        }
    elseif ( preg_match ( '|127\.0\.0\.1|', $_SERVER['REQUEST_URI'] ) || preg_match ( '|localhost|', $_SERVER['REQUEST_URI'] ) )
        {
        $ret = "https://localhost/.../public_html/main";
        }
    return $ret;
    }

add_filter ( 'option_home', 'GetMainURI' );
add_filter ( 'option_siteurl', 'GetMainURI' );
?>

The plugin is installed and activated (I redacted the interiors of the URIs).

Obviously, “add_filter(‘option_xxx” isn’t working. Either I misread the docs, or I’m just thick. I can’t find examples of this particular capability no matter how hard I Google…

option_home and option_siteurl give me what I need, but the E3Calendar plugin is doing some whacky stuff that I’ll have to dissect…

That looks like what I need. Let me experiment…

Thanks!

I’m not sure I understand.

I need to intercept it so that the “native” WP code uses my reassignments.

I don’t want to do any hacking at all in the native code (I could quite easily do it by messing with the main function). I want to overload the main function, so that it returns localized versions of the URI, if I am running it on my laptop (localhost) or I’m accessing the laptop version from a Parallels VM (10.211.50.2).

I know that get_bloginfo(‘home’) and/or get_bloginfo(‘siteurl’) are called from within the code, because I see my pages getting really screwed up in the Location Bar, and everything goes pear-shaped.

Just FYI. I did take your advice on b), and wrote the most pathetically basic plugin ever: https://cmarshall.com/misc/paragrapher.zip.

The problem with a) is that you need to install filters and themes in conjunction. They must be a set. You also need to activate the filter first from another theme, or you get a PHPuke when you run your theme. (or you need to call the admin system directly.)
b)…hmm… I had thought that add_filter() was a plugin-only thing (couldn’t figure out otherwise from the docs.) If I can do an add_filter() from the theme file, then I can do that.
That being said, why was it that we can’t apply filters and hooks to the “get_” versions again?
The reason for the header thing is that you can’t set a cookie unless it is done before *ALL* connection text. It needs to be done before all other headers are sent. My plugin relies on a cookie.
Thanks for the feedback. I’m really not calling anyone’s baby ugly. WP is a great tool, and I have used it in a couple of blogs. The ugly baby was PHP-Nuke, which I had to practically rewrite from the ground up to get halway decent code.

These are just basic usability comments. Some of them will apply to the actual wiki code, some to the content itself, and some to the structure of the site.

First, let me say that I am fairly new to using a wiki. We use one for our software development, but I haven’t really used one elsewhere. Please forgive me if I don’t have the terminology right, or if I don’t “get” some basic concepts.

I am starting with the main codex page: https://codex.www.ads-software.com/Main_Page

The section headings are pretty clear, but there are too many of them, and they suffer from a fair amount of “functional crossover.” Also, the main heading names are not clickable, even though there are pages that correspond to them. The little arrows after the names are clickable, but the results are inconsistent.

Various sections are laid out in places that may not be immediately obvious. For example, I wanted to find a list of hook calls. There seems to be no immediate link for that in the main page. Fair enough, so I look for a subheading that may contain this list. I assume that “Advanced Topics” may have what I need. Nothing there that fits the bill, but there is a section called “Plugins and Customization.” Maybe that’s where it is. I click on that. It takes me to the “WordPress Plugins and Customization” anchor, on the “Advanced Topics” page. It must be here.

Now, here you have a problem. Almost all of the articles here are about *using* and *finding* plugins and themes. They are not about *writing* them. There’s “Anatomy of a Template Tag,” but that is in the previous anchor, not “Plugins and Customization.” As far as I’m concerned, that is *definitely* a topic for writing a plugin.

However, that’s not the worst of it. Everything is all jumbled together. You need to create a couple of main headings: i.e. using plugins, and writing plugins. You need an architectural overview (there may well be one, but I have yet to find it.)

The long and the short of it is that I had to click all over to find the minimal amount of information I needed to get started writing a plugin. I think that all the information is there, but it is not well indexed. Basically, you need to have an information architect review the entire codex, and organize the information according to a set of use cases. I only represented a very specific one. It is possible that it is already laid out for more common use cases.

There is a lot more, but I thought that this little anecdote would give a good overview of some of the issues as I see them.

Let me take some time to go over it constructively, and give some objective feedback. I am a usability engineer, and I might be able to come up with a couple of ideas. I don’t want to just whine, so I want to have some time to evaluate it. Is this weekend too late?

Well, I have it pretty much working. It still needs some refinement, but the whole site is under construction, so it will coalesce quite well, I’m sure.
You can see it here: https://www.tcryan.com/blog/?p=5
Right now, it shows the whole library, but I’ll uncomment the line soon that does this, so it will only show what has been added for the particular visitor.
It is fairly basic: The plugin code sets a cookie with the current visitor timestamp, but it will only update it once in 24 hours, so the visitor can go back and see the same images more than once in a given time period. This means that the post will appear differently for each user. If someone visits every day, then they will only see a few images. If they visit infrequently, they will see a lot more images.
In this particular case, I am checking a partner installation of Gallery 2 (Bingo release) for new images, and displaying thumbnails of those images, along with links to the full-resolution images within the Gallery. It’s a nice shortcut for a personal site that probably won’t be featuring too many new images. If this were a pro gallery, then I would probably use the Gallery implementation, which is more robust, but a lot more complex for the user.
I did this by creating a blank plugin with a “your content here” type HTML comment. The plugin will process this, and replace it with content as necessary. I used the “Adhesive” plugin to make the post “sticky.” I will probably create an excerpt for the post that indicates the number of images therein. As I said, I still have a fair bit of work in refining the functionality.
I ran into a very nasty problem in WordPress, and was a real puzzler for me. I’d suggest that you consider addressing it. I had originally used the “add_action” and “add_filter” functions to register the plugin hooks, but they didn’t work. I went nuts trying to figure out why, but then I got it: WordPress does not call the hooks for the “get_” versions of the processing functions. I need to use these because I massage the content heavily (notice that all pages validate XHTML 1.1 and WAI AAA). I don’t want to just display it. There also seems to be no hook for a “pre-header” operation. I set a cookie, so I need to do that.
This means that I directly call the plugin functions from my template code. Yucchy, but still within the parameters for a “non-hack” modality. The templates and the plugin need to be installed as a set. I’m not particularly happy with the solution, but it works, and it will still allow WordPress to be updated, which is what I want.
I think this kind of functionality is a pretty important “basic” capability of a blog. Many blogs seem to have it built in, and, quite frankly, I was surprised that WordPress didn’t. I’ll be happy to provide any code to anyone who wants it, but it may not be very useful, as it is directly relevant to this particular site’s customization.

Yeah, I’m trying to obey all the rules, so I can upgrade seamlessly. I rewrote Nuke once, and got my site taken down by a script kiddie hack because I didn’t apply the fix. Never again.
The more I think about it, the more I like the idea of creating an empty “stick” entry that has its content built on the fly. I can create an on-the-fly plugin for my particular need (I have a peer Gallery 2 installation, and I want to create a “Newest Images” post). I’ll be happy to share what I learn. I’m not sure if a single plugin will be useful, more like a set of heuristics.

Thanks! I got it, and I’ll look it over. It probably won’t give me exactly what I need, because I’ll bet that it uses posts in the database. Remember that I am trying to avoid creating a database post, although I may be able to create a blank post (like I do for intouch) that has the content dynamically generated. In that case, this is exactly what I need.