summitlake

FIVE STARS: UPDATE: I split 3 queries into three different PHP Code widgets with tweaked code. They then worked at the bottom of the sidebar. I moved them to the top where they belong. They still worked, but they broke the stock CATEGORIES and ARCHIVES popups, and most sidebar content below that.

BUT IT GETS BETTER. I rewrote all 3 to use mysqli connects and queries, rather than the older mysql.

All works fine now. I don’t know what API the author uses, but I found that my older mysql PHP calls are deprecated. People are now using the preferred APO and mysqli protocols.

I’m upgrading my rating to 5 stars if I can find the right way to do it.

I gather the main idea is to stop someone wanting to hack into your blog, since the first username they’ll try is “admin”.

OK, what’s to prevent them from simply going to any page and seeing who’s posting? (Assuming admin posts under that name).

Seems to me, to make this work, sole users like me would have to post under one name, and log in under a secret name.

There were several different “how-to’s” posted of varying clarity. Perhaps some of us picked one using the different table naming scheme we discussed. Not knowing if the recommended naming scheme also had to match hard-coded 3.0 multisite requirements, we would have just used what our particular “how to” recommended.

As to your question about error messages, I never saw any browser errors. I don’t remember if I checked the server error log, but I’m pretty sure I would have.

You asked about table names earlier. Apologies for the post length, but my database and table names wp_ through wp_10_ are listed below (wp_4 thru wp_9 omitted for brevity):

wp_1 (108)

wp_2_commentmeta
wp_2_comments
wp_2_links
wp_2_options
wp_2_postmeta
wp_2_posts
wp_2_terms
wp_2_term_relationships
wp_2_term_taxonomy
wp_2_weatherxml
wp_3_commentmeta
wp_3_comments
wp_3_links
wp_3_options
wp_3_postmeta
wp_3_posts
wp_3_terms
wp_3_term_relationships
wp_3_term_taxonomy
wp_3_weatherxml
….
wp_10_commentmeta
wp_10_comments
wp_10_links
wp_10_options
wp_10_postmeta
wp_10_posts
wp_10_terms
wp_10_term_relationships
wp_10_term_taxonomy
wp_10_weatherxml
wp_blogs
wp_blog_versions
wp_commentmeta
wp_comments
wp_links
wp_options
wp_postmeta
wp_posts
wp_registration_log
wp_signups
wp_site
wp_sitemeta
wp_terms
wp_term_relationships
wp_term_taxonomy
wp_usermeta
wp_users
wp_weatherxml

200 downloads and no feedback is discouraging. Whether or not a plugin meets all expectations, users should certainly take a minute to share feedback with open source authors.

I did research this before I found and tried your plugin. I was not expecting it could be done with a plain 3.0 installation (no buddypress, no related parallel installations). But I knew I could be wrong.

I would have to set up a test blog and then deactivate _that_, but to be honest, I currently still just copy and paste excerpts by hand, so I uninstalled the plugin.

Instead, please, let me ask you this: is your plugin designed to work under a brand-new 3.0 installation configured for multisite, 2+ blogs on a single database, and NO other plugins or support apps?

All I did for 3.0 MS is follow the how-to’s which resulted in the table naming we already discussed. I’m not delighted with it (strange permalinks) but it works flawlessly. And, Google and my readers are using published permalinks.

It could take a lot of work to reconfigure a 10-blog site for a new table name (table prefix + ms_posts). This would probably change all the permalinks. As a “drop table” situation with a powerful text editor, this brings a lot of high-risk change with possible downtime.

So, it would be better if the plugin can work with the standard table names we have now.

Can you tell us why there would be two different naming conventions and where the _ms_ naming scheme originally came from?

Thanks — Alex

My posts tables are wp_posts, wp_2_posts, wp_3_posts thru wp_10_posts. No table at all has an _ms_ in the string.

I see you are hard coding your mySQL query for [base_prefix.”ms_posts.*]. So this would not work for me.

I’m not having any other issues operating my single 3.0 multisite installation (replacing 10 separate older 2.9 installations), so it appears my installation isn’t compatible with the configuration you are developing with.

I’ve been posting my multiple-site WP post excerpts manually on the “home” page for years now, and it’s not really that inconvenient. It just seemed that it would be neat if an aggregator could take over the chore.

Thanks.

Using WP 3.01 multisite … if there is supposed to be a table with the string ‘view’ in the name, there is no such table in my mysql installation.

Thanks, but still not resolved for me: no change from my post on 1.0. I found the screenshots but cannot tell when one would expect to see them. Does 1.0-1.2 capture the most recent 5 or more existing multisite posts going back to before installation/update, or should the user expect to see results only on new posts after installation/update?

ISSUES RESOLVED (for me): after watching my JS error console, I did the 2 steps below on my remaining 5 “problems” installations. This fixed all my remaining problems, including (a) our Edit Post sidebar issues, and (b) an Appearance/Widget frozen/inop widget icon issue I didn’t know I had.

These steps are only what worked for me. I have no obvious explanation why all my installations weren’t affected or whether they’ll work for everyone, but:

1) in my affected wp-admin folders I re-uploaded these 3 files: load-scripts.php, load-styles.php, widgets.php

2) testing the affected control pages, I found I had to refresh the page in Firefox to see the fixes take effect, but work they did.

To re-test, I logged off all installations, closed Firefox, and started it again. Logging in, the fixed functionality remained “fixed” – without refreshes or other gimmickry.

Alex

Partial fix. This is good news: I downloaded and installed the Firefox upgrade from 3.5.5 to 3.5.6. This cleared up all problems previously noted in my last post (in the clean TEST installation).

The Sun java test page reports that my Java Platform 6.0.170.4 runtime library is working correctly.

Unfortunately I still have these Edit Post issues with my regular WP 2.8.6 installations. This should point me to a “multiple causes” scenario with the files or plugins in those installations. More troubleshooting!

I did a new post under WP 2.8.6, clean install from the 2.8.6 download package, no extras or customization, under Win7 Mozilla. The Post Tag ‘Add new tag’ and ‘Choose from the most used tags in Post Tags’ do not work. Neither does Add New Category. This is consistent with other sidebar function reports.

Mozilla 3.5.5 reports dozens of errors like the below in Tools/Error Console:

Warning: Unknown property ‘border-bottom-left-radius’. Declaration dropped.
Source File: https://www.summitlake.com/TEST/WP-TEST2/wp-admin/load-styles.php?c=1&dir=ltr&load=global,wp-admin&ver=ba4d987ec2b562bd22e5da70fe38318d
Line: 748

The link from “Choose from most used tags’ is:
https://www.summitlake.com/TEST/WP-TEST2/wp-admin/post.php?action=edit&post=448#titlediv — which is the page URL rather than the intended URL.

I’m using Firefox under Win 7-64. I’m getting a similar issue only with the Add Tags popup in Post Edit. Clicking the link to add tags does not usually produce the popdown inventory of currently used tags. Instead, it pops the whole browser page to the top, and in this case I can’t either add new tags or select from old ones.

I have multiple WP 2.8.6 installations and the odd thing is that this feature works in some of them. The obvious approach here would be to try to find some slight difference in the installation files, and I will try to track down the problem this way. But these same 2.8.6 installations work perfectly under XP and Snow Leopard 10.6.2 Mozilla (Firefox), and the problem can’t be recreated.

So for me at least, this issue does seem to be connected to W7 or 64-bit. My workaround for the time being is to load or edit posts on the Mac.