Forum Replies Created

Viewing 15 replies - 61 through 75 (of 202 total)
  • Thread Starter rsgrone

    (@rsgrone)

    I never relaized that the “Enable Multi-site” made changes to the database…. I thought it had something to do with the upgrade from MU (which was extremely painful) that caused the bulk of my problems…

    Firefox try…. [CTRL]+[SHIFT]+[R] to load a fresh page… I personally don’t see what’s so great about FireFox… Chrome seems to load the fastest out of the “big three” however, Chrome has a rather persistent caching problem as well…

    If you are running WP-SuperCache for example, I would try clearly that cache as well… I login to my remote desktop, go right into the folder/directory and delete the contents…

    The only way you can get all the information you want (in bulk form as all have stated) is login to your “Control Panel”, “Remote Desktop”, or whichever, and execute a backup of the database. Zip the file as it will be large (backup.sql) ftp to the site, and download both the zip file along with, the wp-contents/uploads, wp-content/plugins folders…

    Once you obtain the base files, utilizing a tool such as “Filezilla” you may periodically backup the above folders while, “Filezilla” (for example) will save you time by not overwriting previously downloaded materials (photos, etc)…

    Next, you will need to do a rather scheduled backup of the database albeit, via MyPhpAdmin, MySQL tools to maintain the “knowledge” by your site (lack of better words) as to which plugins are active as well as, which users are still active relative to their posts.

    BEWARE… you will need to make adjustments to php.ini file to allow for MyPhpAdmin to “Restore” a large backup in case of disaster.

    But to answer your question as Andrea has already, no there is not a plugin…

    You may want to go out to the net and see if you could hire some php/mysql guru, that could create a script that would allow you to execute a database backup of each individual “blog” of your site via (wp_1, wp_2, wp_3, etc. tables) of course, the usermeta is crammed into one large file however….

    If you are allowing each of your users to create use their own domains, I would suggest strongly simply creating individual installs of WP 3.13 for each user… this of course will create several different databases within your MySQL server, an equal amount of wp-content/upload and /plugin folders but, it is the only way at this time to achieve what you are looking for…

    Good Luck!!!

    P.S. You know on second thought, via MyPhpAdmin you could actually make one large back-up of the entire site, and then do individual table backups of the corresponding blogs… e.g. backup tables, wp_1 (all), wp_2 (All), etc.. separately and in need only have to restore a minimal number of files… see if there is a MyPhpAdmin guru out there that can give you a hand with a script…

    @zeek — honestly so have I however, you may want to check out this article…

    http://jasonirwin.ca/2011/05/28/wordpress-multi-site-with-multi-domains/

    It appears he has a handle on the situation… I had left a comment regarding the load on the db (cache config., etc) if his site(s) become busy and begin spawing hundreds of cgi_processes….

    Have fun…

    Thread Starter rsgrone

    (@rsgrone)

    As I replied to your repeated comment in the other thread…

    In the wp-usermeta table there is the following entry
    19, 1, ‘primary_blog’, ‘0’

    Now, when mine failed after the rollback, I had to change

    19, 1, ‘primary_blog’, ‘1’

    to the above hence, the reference to “blog 0” whereas, my lack of technical expertise would lead me to restate that, “primay_blog” maybe set to “something other than 0 (zero)

    If you would like, I will post the entire entries for a single given user within the wp_usermeta table….

    Maybe I could get an explanation as to how, when I created the multi-site using some plugin my “primary-blog” (excuse the blog “0” reference as it is referenced that way in the table) was set to something other than “0” like all the other registered users…

    Complicating matters, my user level within the same table for admin, was set for “subscriber”

    Now, I know I did not intentionally go into my DB and make those changes to make my life difficult….

    In the wp-usermeta table their is the following entry
    19, 1, ‘primary_blog’, ‘0’

    Now, when mine failed after the rollback, I had to change

    19, 1, ‘primary_blog’, ‘1’

    to the above hence, the reference to “blog 0” whereas, my lack of technical expertise would lead me to restate that, “primay_blog” maybe set to “something other than 0 (zero)

    If you would like, I will post the entire entries for a single given user within the wp_usermeta table….

    @andrea… maybe they are having the same issue as I was… that is “admin” was assigned to blog “1” instead of “0” in the usermeta table…. just a thought…

    Thread Starter rsgrone

    (@rsgrone)

    I just checked using the archives widget…. it appears everything is there since opening in 10/09…

    Maybe that is why the “admin” was assigned to blog “1” instead of “0” like everyone else… [dramatic pause] and maybe, that is what caused my site to begin loading slowly… I have no idea… you?

    Thread Starter rsgrone

    (@rsgrone)

    Andrea,

    That is correct, I had the identical tables wp_ and just posted two new articles… all seems well…

    I think the transition from MU to 3.o wasn’t as seemless for me as I had thought… I guess I will really know with the exception of looking at the original database I kept but, it appeared the posts were duplicated as, the posts in wp_1_tables stopped updating back in I think, 2010…

    Thread Starter rsgrone

    (@rsgrone)

    Finally, I simply reverted back to the single site installs… Honestly, “Single Site” appears to be loading much faster than the multisite flavor (in IE anyway)

    Thread Starter rsgrone

    (@rsgrone)

    WEll I backed up the database and dropped the wp_1_ stuff and the numer of posts/coments did not change although, I honestly forgot to check how many there were prior to reverting back as your instructions indicated…. so, the bottom line here is, I think the only major issue I had was having to go into MySQL Query Browser and and execute two changes:

    admin had to be assigned to blog “0” in usermeta
    admin privileges had to be changed to “admin” from subscriber however, with multisite running I never had a problem with “admin” being a “subsriber”

    If you feel I may have caused damage, please let me know…

    Thanks Andrea

    Thread Starter rsgrone

    (@rsgrone)

    Thanks I had one issue though…

    User admin had privilieges set to: ‘wp_capabilities’, ‘a:1:a:1:{s:10:”subscriber”;s:1:”1″;}’ which I needed to change to: ‘a:1:{s:13:”administrator”;s:1:”1″;}’ less I obviously had only subsriber privileges…

    Next, although I never created any additional “blogs” (which is one reason I wanted to revert back) I still have a plethora of tables marked as: wp_1_

    Can I delete these as well?

    All seems okay so far however, I will need to change my Google Sitemap plugin I think since I was using the multisite flavor…

    Any ideas on what I can do with the additional wp_1_ tables? I believe they are carry overs from the MU days…

    wp_1_commentmeta
    wp_1_comments
    wp_1_comments_moderation
    wp_1_postmeta
    wp_1_posts
    wp_1_term (group of 3) to save time tax, relation, terms

    Thread Starter rsgrone

    (@rsgrone)

    P.S. (regarding the last paragraph “admin password lockout”)

    I first panicked Sunday morning because I thought I was hacked and someone changed the admin password…. However, it was coincidental that a returning blogger had used the recovery tool/page that caused the problem and of course made me aware of the problem… I was not hacked thankfully…

    Thread Starter rsgrone

    (@rsgrone)

    Got it with the wordpress@ email address….

    Anyway, it appears to be a combination of Premium Plugins, and a database issue following the upgrade to 3.13

    Once I removed the multisite premium plugins, I needed to restart mysql server running on port 3306… the server on port 3307 was not effected however, that install was upgraded to 3.13 but, it is not a multisite installation….

    Really strange as, with the multi-site, during registration you are redirected to wp-sign.php whereas, the single install uses the wp-login.php?action=register without the redirect…

    There in lies my issue… it is when the page redirs to the wp-signup.php is when ALL issues were being seen… I made some tweaks with my cache(s), as well as removal of plugins (premium) that would allow either the user creating password, or skipping the email confirmation and supply the password upon completion of registration

    The latter was a hassle as, I have a plethora of writers of examiner.com plagiarizing the crap out of my articles and had to install the digiproof plugin to disable the right-click issue… of course that made it rough on the new registrations as, the password could not simply be copied and pasted and the confirmation email was not sent…

    I played around with a combination of generating the password and sending the email confirmation however, it was really playing havoc on the “lost password” recovery… With the cookies and cache running, if I requested a password for a pseudo account, or had someone external from my location request a new password, it would at least lock out the administrator login…

    This explains the plethora of emails I was receiving regarding returning bloggers that could not get logged in… eventually it drove many away…

    Oh well, at least it works now, and I really can’t attribute everything to 3.13 as, I was receiving emails regarding login problems prior to the update however, after 3.13 is when I began experiencing the admin password being reset (could not login) and would have to go the server and reset my own password… (I hope that makes sense, it is late)

    Thread Starter rsgrone

    (@rsgrone)

    Already did the theme thing… I blocked out the “request lost password” form and replaced it with a message to email the administrator… I will give the other plugin a try… what has me faked is when it does fail on the SMTP plugin test, it generates an email address “wordpress@mydomainname.com” there is no such email address in the users database

Viewing 15 replies - 61 through 75 (of 202 total)