martonic

Edit. The shortcode produced only the title. In another page, where I use php I put in the following code:

<?php dynamic_sidebar( 'secondary-widget-area' ); ?>

This renders correctly.

The necessity was to have the files available in a new location. I kept the old ones “just in case”. As it turns out, IIRC the first time I could not get into the admin site at sitename/admin, I had to use sitename/wp/admin – so if I had deleted (“moved”) those files, I would have been SOL. However, the existence of files that are not referenced should mean nothing. WP had been told to look for them in a new location. Why should it matter if they are also present in an old location, or a dozen other locations that WP has been told NOT to use? It should not matter at all. If you are saying that was a mistake, and it led to the current behavior, for which there is still no explanation in sight, I would like to see some justification for that opinion. I still don’t see why WP should be attempting to update files in a location that is not referenced either in the database, or in any of the configuration files – or how it can know where the files are for the purpose of READING them, but not for the purpose of WRITING them. That makes no sense – so it must be incorrect, and a reference to that directory must still exist somewhere in the working image. However, the mere EXISTENCE of an old directory should have no effect whatsoever. If this is wrong, please explain how it can be wrong. Thanks for your help!

1) Administration > Settings > General panel.

2) Changed WordPress Address and Site Address from http://wp/sitename.com to http://sitename.com.

3) Clicked “Save Changes”.

4) Copied wp-admin, wp-content, wp-includes directories from public-html/wp to public-html.

5) Copied .htaccess, index.php, xmlrpc.php, and all of the wp-*.php files from public-html/wp to public-html.

6) Edited index.php (in the root directory). Changed “require(‘./wp/wp-blog-header.php’);” to “require(‘./wp-blog-header.php’);”.

7) Ran the “Search and Replace for WordPress Databases Script” from here:

http://interconnectit.com/products/search-and-replace-for-wordpress-databases/

Changed all matching references from “sitename/wp/” to “sitename/”.

8) Opened the admin site which was a bit tricky. I don’t recall how I finally got into the site at this point.

9) Administration > Settings > Permalinks

10) Clicked “Save Changes”. The contents of sitename/.htaccess did not need to be changed; it already matched what was shown. It has the permalink code and nothing else.

I think that’s it.

I ran the “search and replace php script” but I cannot be 100% sure that it worked correctly. However, the site does run at its new location and WP READS the plugins, themes and so on from the correct location, it just continues to WRITE them (including updates) to the wrong one.

Hence my original question in the first post above:

Can anyone tell me where, in the database, is the information that tells WordPress where to operate on the installed plugins? This seems to be different than the information that tells it from where to LOAD the installed plugins. I would call this a BUG – but meanwhile, would like to find a way to correct this problem.

Example 2. I install a plugin and it lands here:

$_SERVER[‘DOCUMENT_ROOT’] . ‘/wp/wp-content/plugins’

and I go to the plugins page and it is NOT THERE.

I manually MOVE the new directory into this location:

$_SERVER[‘DOCUMENT_ROOT’] . ‘/wp-content/plugins’

and THEN WordPress agrees that we have a new plugin installed.

Any ideas?

Thank you very much!

Thank you very much. We are now using another solution, but I appreciate the answer.

No – we switched to “Q&A” (now using the paid version, “Q&A Plus”) which is looking okay (with search and category links disabled, and styling added).

We also liked “Faq manager” except that re-ording the questions seems to be broken 🙁