admintiger

I just noticed that TML did not create the five new pages Log Out, Register, Lost Password, Reset Password, Your Profile in WP when I re-installed 3.6.8 after cleaning the database.

I found and deleted six _tml_action meta items from the database and then reisntalled TML 3.6.8. That changed, but did not correct, the problem.

Now, when I try to logout, instead of going to:

https://www.domain.com/login/?loggedout=true

the system tries to load:

https://www.domain.com/wp-login.php?loggedout=true

and the WordPress “This is embarrassing …” message displays, because wp-login.php cannot be found. I had set the TML security option to disable wp-login.php back when using TML 3.6.6 and everything had worked correctly with that version set that way. Now, wp-login.php is always disabled whenever TML 3.6.8 is activated, regardless of the TML security option setting, and it is not possible to log out or in.

I just discovered that the “Admin Username Changer” plugin is not compatible with the current version of WordPress. Instead of using that plugin, the admin username can be changed easily with the following steps:

1) Create a new user account with admin access.

2) Logout and then back in using the new username.

3) Delete the original admin user account.

False alarm! The “Admin Username Changer” plugin is not compatible with the current version of WordPress and wasn’t changing everything correctly. Instead of using that plugin, the admin username can be changed easily with the following steps:

1) Create a new user account with admin access.

2) Logout and then back in using the new username.

3) Delete the original admin user account.

After doing that the red warning message on the “Stop Spammers Plugin Options” page disappears.

No. Copy the “admin-username-changer” folder and files it contains to the /wp-content/plugins/ folder in WordPress. Then login as admin, go to “Installed Plugins,” and activate “Admin Username Changer.”

Sorry, I can’t provide that right now, because both the production and test sites are running in a high-security environment.

However, I learned more about the problem after foolishly risking a trial on a production site. I had been able to successfully upgrade a test site from TML 3.6.6 to 3.6.8 using the “Fix 2” steps further above and thought I could do the same with a production site. However, that process not only didn’t work, it made it impossible to either log in or out. Logout attempts displayed an “Are you Sure” message. Login attempts displayed a “Lost Password” link that didn’t work.

Whether TML was activated or deactivated the WordPress admin “Pages” list had “Login,” “Log Out,” “Lost Password,” “Register,” “Reset Password,” and “Your Profile” pages that could not be displayed or deleted from within the WordPress admin system.

I checked wp_posts in the mysql database and found multple posts with each of those names that each had the post_type “page.” I deactivated TML, deleted all those pages directly from wp_posts, and also deleted TML from wp_options. I then installed TLM 3.6.8 in the hope that it would recreate whatever was needed for a fresh installation. That didn’t work. Login attempts resulted in 404 “Page not Found” errors.

Reinstalling TML did not re-create any pages in wp_posts (should it have?), so I created them manually with a post_type “Page” and content [theme-my-login]. That enabled login via TML. It also enabled display of the TML logout page when trying to logout. However, logout does not actually occur.

Do you have a script that will delete everything from the mysql database that any version of TML ever created to enable a virgin TML installation, because TML 3.6.8 works with a fresh WordPress installation?

The tests sites used for the experiments above did not use the TML widget. I just tried Fix 2 above at a third test site with the TML widget in a sidebar. After Step 2 where TML 3.6.7 was installed the logout HTML link was broken and I was not able to logout with TML activated. Re-saving permalinks did not correct the problem.

I have determined that the log out problem is due to something in the SQL database that was fixed in 3.6.7, but that is not fixed in 3.6.8. Either of the following corrects the log out problem for me:

Fix 1:

1. Do a fresh installation of WordPress 3.5.1 with a newly-created empty mysql database.
2. Install TML 3.6.8

Fix 2:

1. Deactivate and remove TML 3.6.8
2. Install TML 3.6.7
3. Deactivate and remove TML 3.6.7
4. Install TML 3.6.8

I should have mentioned in my comment above that when I try to log out “Are you sure?” displays. That is listed in the changelog as having been fixed in version 6.3.7 (which I skipped), but is not fixed in 6.3.8.

I have TML 6.3.6 installed and running correctly at several several production sites (I have been very pleased with it, by the way). I noticed today that 6.3.7 and 6.3.8 have been released since those installations. Before upgrading the production sites I upgraded a development/test site from 6.3.6 to 6.3.8, skipping 6.3.7. Since doing that I cannot logout of the test site with TML activated.

In an attempt to revert back I deactivated TML, deleted the TLM 6.3.8 plugin folder, replaced it with the previous 6.3.6 plugin, and reactivated. That did not correct the problem. Since upgrading to 6.3.8 I cannot logout using either TML version.

I agree! It is reckless to load JavaScript code located on a Facebook server in web browsers logged-in to the WP admin system. I stripped out all code related to that and to the creation of unwanted Twitter and Facebook links. I haven’t tested the modified version extensively, but it seems to be running normally at several websites.

I have posted the modified version here for others who want to use it instead of the official release.

Of course, the changes will be overwritten if a newer version from Photocrati Media is subsequently installed, so this is only a temporary solution. Now that Photocrati Media has violated user trust by doing this I have created a new branch that I will upgrade over time for my own use, but I probably won’t be making it available to others, because I don’t have time to provide technical support.

I don’t know anything about the SD Questions & Answers plugin, but the Q and A – FAQ Plugin works fine with WP Super Cache at my sites. Maybe it will meet your needs.

The keyword density tools you have tried must not be able to decompress files. I would leave compression enabled and look for a better tool.

I don’t have that problem here with any of multiple installations. It might be a Permalink issue. I use a “/%post_id%/%postname%/” custom Permalink structure that likely is different than what you are using. I suggest that you go to Settings/Permalinks and simply click the “Save Changes” button which can fix Permalinks under certain circumstances.

GRMetrix reports that browser caching is enabled at all my sites that use WP Super Cache. Your issue probably is due to web server configuration.

Web servers can be selectively configured to enable web browser caching for each type of file. So in your case, for example, browser caching might be enabled for some types of files, such as image files, but not for others such as stylesheet or JavaScript files. Furthermore, the files that do not have browser caching enabled may be related to advertising, such as Google AdSense. Web browser caching generally is not enabled for advertising files, so advertisements can be changed.

The first troubleshooting step is to check the GTmetrix report to see which types of files are not leveraging browser caching. If they are related to ads, that will be by design and the only fix will be to remove the advertising. If instead they are files being served by your web server, then provide your web hosting tech support staff with a list of the file types.