lunabyte

I’ll have to agree that this won’t help much, if at all.

Those who copy are grabbing content via RSS, not directly from the page. At worst, they’re using a scraping program which grabs from the page source anyway.

The only deterrent I’ve found that works is a big ol (randomly generated) copyright notice at the top of a post viewed through RSS.

Most of the copycats haven’t a clue how to strip it out, and they “really” don’t want the world knowing they stole your content.

No, it isn’t exactly the most elegant way on the planet as your real readers see it, but if done at least semi-tastefully it doesn’t hurt much.

In fact, there is already a plugin which adds a copyright notice to each post in your feed, although it would need tweaked to put the notice before the post and not after.

(Also posted on the MU forums)

Problem is: when BB checks the blacklists, it’s own list (pointed at ioerror.com) is the one mucking it up.

I started this morning off with a clients site doing the same things. A quick commenting out of that particular list corrected the issue.

While a temporary fix, I haven’t tried the new upgrade yet.

(edit: it apparently corrects the issue)

If the list the previous version was pointing to was modified so that it would “get your attention”, I’m sure not very impressed with the shenanigans.

You mean that isn’t how it’s supposed to be? Wow.

The only good part to mine are that if I see one, I’ll spring for a full 10 years up front. I had a few that I didn’t do that with initially, but when they came due I upped it. I have a couple small exceptions, but nothing significant.

No, I’d believe it. I know exactly what you mean. Projects planned, but never followed through, and the domain is too good to pass up.

Duh. It’s in your profile. lol

Where are you from?

Well, well well.

I started messing around a couple hours ago with this.

In short: It works, beautifully.
I’ll try to keep this as short as possible.
Here’s what I did.

The set-up:

I used three domains for this experiment. We’ll say md1.tld, md2.tld, and md3.tld.

All three domains point to the root public html directory.

The process:

1) Installed wordpress.

WordPress extracts to a “wordpress” directory. I didn’t feel like moving all the files up a level, so I simply renamed the directory to another name (I used “media”, but whatever), and then moved the index.php file up a level. I have other stuff in the main directory, else I could have just did an mv, and made it the new root html dir. Anyway, for testing this worked out nice since it is different than a completely untouched install.

I did the modification to index.php, to point it to the right place, and put a new index.php in the directory with all the core files that redirect to the one above.

Next, I added the info to config.php, and installed as normal.

I made a few minor changes to the default configuration in the admin panel, as I usually tend to do. These included:

– changed site name to suit the purpose, and description,
– as well as took out pingomatic (no need to ping with test posts),
– as well as changed the permalinks to “/%category%/%postname%.html.

I left the theme set on Kubrick, but I did upload another theme to use later.

Changed my password. (important)

Edited the default hello world, and comment. Left them, just changed the data. Did same for default “about” page too.

Back into phpmyadmin, I edited the user table, and replaced the value “admin” in login and nicename to something different.

Now that I have a workable default configuration, onto step 2.

2) Dumped the current tables

PhpMyAdmin, dumped the tables, saved them in a default local file.

Made a copy, renamed it to Dump-md2, and then did a search/replace to find the original domain and replace it with the new one.

Next, did a search for the original table prefix (i used “md1___”) and replaced it with the new table prefix (“md2___”).

Next, pasted it back into phpmyadmin, and it created just fine.

3) Time to alter the config.

Opened config.php to make the following changes. I will generalize them here, but you’ll get the idea.

– above the db info, i added a 4 sequence if/elseif statement.

I used 2 stristr functions, and checked the $_SERVER variables
HTTP_HOST, and X_FORWARDED_HOST for “md1.tld”.

If it returns true, I set a variable to equal the table prefix for md1
( $tbl_xtest = md1___ )

Then added two elseif statements to the sequence, changed the domain i was looking for, and the resulting table prefix.

The final check in the sequence was a plain old else, which set the table prefix variable to the one i wanted as a default. I used the first one.

Next, the line where it actually sets the table prefix, I removed ‘wp_’ and replaced it with $tbl_xtest.

4) Testing

I uploaded the new config file, and checked the initial domain. Check 1.

I checked the second domain. It worked flawlessly. The third was just fine too.

Now, time to see what happens if I use a domain not listed. Bam. It was the default site, just as it should be.

I logged into the second site, and made a few changes. (Note, with the duplicated tables, your username/pass is the same.)

I changed the theme to the one uploaded earlier, and some other things. All were seamless. It was no different than it being two installs.

In summary, it worked just fine.
Now for some notes…

Plugins.

Some may or may not work. In theory, most should. Ones that would not, are ones that create tables in the DB, but don’t use the table prefix. I’ve seen a couple that have done this, at least they did at the point I used them.

wp-cache? Don’t know, don’t use it.

Themes should be ok. As long as it keeps in line with table prefixes, and the site url/file settings, all should be ok. Don’t take my word for it though, as I said, I haven’t tested any plugins.

There might be an issue with plugins that want to modify the htaccess file. Look at what it wants to do, and edit it manually to be safe.

There shouldn’t be a problem with multiple conditions for different domains, but you never know.

Themes:

Should be fine. Since they are activated in each DB, and follow the settings that are set in the options pages.

I should note, that any theme customization for a particular domain should be made into a theme identifiable for that domain. I wouldn’t recommend allowing the theme files to be writable, just in case.

Permalinks:

Since they are controlled by the database, all is well.

Final Note:

This was a test, simply to prove that it can be done. I’m not supporting my changes, only showing you how. This is by far not an option for a novice or noob, that can barely figure out where to edit the style sheet for Kubrick to change the color of the links or header image.

If you don’t know php, and that does not mean being able to cut and paste a tag it means KNOW php, then don’t try this at home folks.

If you have a test site, then feel free to experiment until your hearts content.

Just remeber, I’m not responsible for anyone messing something up, and all that jazz. ??

Have fun.

Yeah. I’m really bad about it too.

Wow, if that wasn’t a wide open door…

I think I will give it a go. Might take an evening or two, but I really don’t see why it couldn’t logically work.

Granted, anytime you would add a site you would need to edit the config file duplicate the tables. But, there wouldn’t need to be any hacking of actual core files. And since they tell you to never overwrite the config file, it isn’t too big of an issue.

Great. Now I’m curious, and it won’t go away until I know.

This is in theory, I haven’t tried it. I’ll try to explain.

The “table prefix” is hard coded into the config file.

Why couldn’t someone do the following?

1) Set up wordpress as usual. Tweak it, set permalinks, and all that jazz.
Let’s say the table prefix for this is “site1__”

2) Next, duplicate the entire tables for “site1__”, but change the table prefix to “site2__”

3) Edit the db, to change the links to the index and files. (WordPress address and Blog address)

No need to edit the site title yet, the links would be what matters.

4) Repeat for additional sites, changing the table prefix and editing accordingly.

5) Edit the config file.

Use a check of the url, probably a stristr(), in a sequence of if/elseif logic.

Something like if stristr(url, domain)) $MyTablePrefix = site_1

Then, where the table prefix is normally hard coded into the config file, just stick the table prefix variable in there.

Then anytime the config file is loaded, aka: every page load, it would use the table for the site that is related to the domain.

Couldn’t swap between domains in the admin, because the users would be different and so would the domain, etc.

That’s the basic idea, I suppose. Although, I haven’t tried it out and I’m sure it would need refined a tick.

Thinking about it, I just might have to give it a go. I’ve got a couple domains sitting around with nothing to do.

Why not just put a default index.php page in any directory you don’t want someone to be able to browse?

In that page, put a header redirect back to your main entrance page?

Then, when someone tries to browse a directory, they instead are directed to your main site? For a single site, all you have to do is make 1 page, then upload it wherever you want to use it.

Of course, don’t upload it where you don’t need it, and overwirte an existing index page. For example, uploading a redirect page like this by accident to say… your root publich html directory would be bad. But, when used in directories where an index page doesn’t exist by default, works out great.

Well, nothing says you couldn’t make a working replica of your current site, and then play around with it.

I mean, it is kind of silly to recommend an entire additional software combination to add onto your site just for one little thing.

However, knowing what else it can do in addition to just registration management, I know there will be something else that will make you go “Wow, I’m glad I tried this.”

Here’s an example. Built into the site are error logs, that record all errors within the setup. Easy to access, you can filter results, and certain ‘behavior issues’ happen to produce very distinct messages.

Got a problematic IP or user?

Ban ’em with the click of a mouse, and entry of a little information.

Ever wanted to add content to the WordPress sidebar, but don’t feel like modifying a file?

It’s possible through the block system.

I’m actually looking for some good feedback from a current WordPress user.

I made the offer to another user, and I’ll extend it to you as well.

If you would really like to try it out, I’d be happy to personally assist you with it. If you can make a working copy of your site (using duplicate tables), I’ll help you get it all installed, and get it themed to match your site.

In fact, if you would prefer, I can help you theme it to where it looks like your site does right now. With some new, cool stuff of course.

Only thing I’ll ask for in return is your feedback on it.
I get emails from our userbase, but feedback from a source that isn’t familiar with it, and a fresh perspective is a goldmine for us. Let’s us get a new angle on operation, use, etc.

I took a screenshot (as I mentioned in the thread here that I referenced above) of an installation that has WordPress as it’s focus. Grabbed a random wordpress theme (happened to be Senorita), and then added the setup I’ve referenced. I themed it to be a WordPress site, look like the WordPress theme, with some additional stuff.

Screenshots available in our gallery at

https://www.lunabyte.net/gallery

If you’d like to take me up on my offer, register with our site, and send me a personal message through the site.

No, there wouldn’t be.

Not that I mean I’m being mean or something.
But there isn’t a way to just pull out a piece of code from the system to use in another one, if that makes sense.

But hey, you’d get some pretty new toys to play with along with it. ??

Cool your working now.

Sorry about missing your last couple of posts.

Been fighting an infinite redirect loop issue with apache. ??

Ok. That at least is a positive note so far. That says your domain is ok at least.

For the record, you can remove the hosts default page in your htdocs directory.

Now, for the problem.

By that error, it says line 5 of wp-config.php is calling the function wp, and it doesn’t recognize that function. Funny thing, is that line 5 of wp-config justs defines the pw for your db connection.

Is this a fresh install? It sounds like it.
Could you try removing all the files, and completely starting over with fresh files, including creating a new config file. I say this, just so that you get everything cleaned up from your testing.

You could go back to using the htdocs directory (site root) as well. Just remember to take out the hosts default page (usually index.html, or similar).

Also, triple check you have the right username, pw, db name, and db host as well to be on the safe side.