*B.V.RammannaRaau*
Forum Replies Created
-
@suraj jadhav
one of the last communication from your end saysI don’t have WordPress backend knowledge
That’s why i didn’t recommended phpMyAdmin option.
Also you gave some information about site asI was able to use that images (uploads in new directory) before itheme security new update. as of now I can’t use any of image from directory
It means you have an existing site. iThemes Security feature for changing wp-content directory name is not recommended for existing site, but for new site installation only.
In your last communication you mentioned that changing upload_path though phpMyAdmin resolves your issue. But actually it is a partially solution for your issue. By changing upload_path though phpMyAdmin, you can upload and link any attachment for the posts you are going to publish in future. But existing attachments still contains default wp-content instead of newly changed app-data (your custom directory name) in database.
Since you can access with phpMyAdmin, follow the following instructions:
- Goto wp-posts table
- sort table by clicking post_type
- verify all that says attachment
- look at urls under guid, all they have still point to old or default directory wp-content
If you have more attachments in the existing site, then you need to change all wp-content occurrences, but just changing upload_path is not sufficient enough.
Best solutions is one of the following:
- First option: in phpMyAdmin, you need to change all occurrences of wp-content in all possible tables using SQL queries or manually change just like you did for upload_path
- Second option:
- backup database.
- drop all tables but not database.
- open backup database with notepad.
- replace all occurrences of wp-content with newly changed directory name, and save it with new name
- then upload newly saved data to the existing database name
- Third Option: you can use plugins like velvet-blues-update-urls
Note: if your issue is resolved, close this thread
After changing wp-content directory, you need to logout and login again. If issue is still present, then check the following
- Under iThemes security > settings > Global Settings > Path to Log Files
- Under iThemes security > settings > Database Backups > Backup
Location
If you find wp-content directory instead of app-data directory in those two paths, just click on restore default location button. Logout and login again, then see if you are able to access media library.
We have been using this feature on several websites without any issues except those mentioned above.
No need to change those lines. Do not write your cPanel id in public forums. If possible replace cpanel id with random name before logout from wp.org
Let met check what’s wrong with your setup at my end
If,for any reason, the following lines not written by iThemes Security, then wordpress unable to find exact location of media library. Make sure the following present in wp-config.php file.
//Do not delete these. Doing so WILL break your site.
define( ‘WP_CONTENT_URL’, ‘http://youtdomain.com/app-data’ );
define( ‘WP_CONTENT_DIR’, ‘/home/your-cpanel-username/public_html/wordpress-directory-name/app-data’ );/home/your-cpanel-username/public_html/ is document root, change this path if your server having a different path.
Seems to be issue resolved after the latest version v5.2.1
Seems to be issue resolved after the latest version v5.2.1
@ramzii
suitable solution provided at https://wordpress.org/support/topic/ithemes-security-and-php-7?replies=4#post-7774485 to avoid multiple instancesMethod I:
Contact hosting service provider where MySQL version is higher than 5.5.40. Ask them to load atleast MySQL v5.5.40.(or)
Method II: Temporary solution
Edit line no.70 in system.php file at
wp-content>>plugins>>better-wp-security>>core>>content>>system.phpAfter finding the above system.php file edit line no.70 like this:
mysql_get_client_info() to mysqli_get_client_info()
Note for method II:
Whenever a plugin updated, the above process need to be repeated againHai Yorman!
Tests conducted on various possibilities with development version. Every thing seems to be working fine except one thing. Previously failed login times was working fine, but with the latest development version its showing UTC+0 instead user defined time zone.
Reproduce the same issue as follows:
1). Set time zone other than UTC+0, like UTC+5.30 or something like that.
2). Then try to login with with wrong credentials to get failed login details.
Hope this helps.Forum: Themes and Templates
In reply to: [Pinboard] How to have sidebars?Pinboard comes with 18 templates. All these templates fall into four categories: Blog, Static Pages (content), Portfolio, others. You are selecting blog templates for static pages.
I’d like to have a left sidebar on a few of my pages (not all though)
- You have to select one of the templates having their name content. Here for your requirement, you need to select template either sidebar/content or sidebar/content half for required pages.
- Theme Options>>Layout>>Content Columns>> Select 3 or 4 from dropdown
- Add atleast one widget in one of the sidebar widget sections: Sidebar Top, Sidebar Left, Sidebar Right, Sidebar Bottom
Now your required page layout appear on the front end.
Seems to be there is a plugin conflict.
Deactivate login with ajax plugin, as it only works with default login url.
Or
Disable the Hide Back End in iThemes Security settings.
Hope that helps.
If don’t get through, deactivate other plugins one at a time and test login url. Culprit will be revealed.Is it possible that htaccess from root folder have some conflict with this new installation
It’s not a conflict, it’s working fine as expected. It happens with multi-domain hosting plans, where all Addon-Domains and sub-domains folders have their place within the root dorectory/folder.
Ok, so that confirms there is some problem with the content of the .htaccess file in the root.
I don’t think there is a problem with above set of rules on htaccess.
Let us assume, we have a multidomain hosting (shared or similar) with root domain PrimaryDomain.TLD. Now the default directory for this primary domain is root where index.php reside. So, htaccess file will be generated in root. Since htaccess file in root directory which contains rules that restrict install.php (wherever it exist, since htaccess is in root), it will not allow new installations for either Addon or sub-domain.
We have three best possible ways to avoid this.
- Install PrimaryDomain.TLD in a sub directory like blog, eng, index, home etc. So that all files including index.php and htaccess file will be in that sub-directory. Then primary domain url will be PrimaryDomain.TLD/blog or other. Now no rules from root will restrict addons and sub-domains installations.
- Install PrimaryDomain.tld as usual, but remove the rules that restricting new installations.
Or disable the Protect System Files setting in the System Tweaks section on the iTSec plugin Settings which write similar rules on .htaccess in the root directory. After new installations complete, enable the previous option in primary domain. - Never try to rename .htaccess file in the primary domain if it has significant traffic. Instead put your site in maintenance mode and change whatever you like in .htaccess. After successful new installations for addon or sub domains, revert whatever changes made in .htaccess file. Next disable maintenanace mode for primary domain
Important Note:
If the first method is implemented, then manually add .htaccess file in root directory. And add essential security rules on htaccess like the following one.# Rules to disable directory browsing
Options -IndexesSo that directory browsing will be restricted.
Once new installations for either Addon or Sub-domains are over, everything work as normal.
.htaccess file protect the directory in which it resides, and all sub-directories within that directory.
@ivansliskovic
Change the status of this thread to resolved, if your issue is over.I was sure that it was not an issue with iThemes Security, but something wrong with .htaccess.
Since default wp rewrite rules and error documents redirections are correct, I thought it was related to only https.
hidden character at the beginning of the line:
ErrorDocument 404 /404.phpI have never experienced such an invisible character related server error. Yes, I can reproduce both on live and home servers, @dwinden is correct. I was surprised, the character invisible even on text editor.
Tons of thanks to @dwinden for new lesson. Keep rocking brother.
May I know in which application it can be visible?
I think you are dealing a site which is not enabled by SSL certificate.
#Error Documents
ErrorDocument 404 /404.php
ErrorDocument 403 https://www.mydomain.com/access-denied/
ErrorDocument 500 https://www.mydomain.com/server-error/
ErrorDocument 400 https://www.mydomain.com/bad-request/The above lines are written by yourself or other user having root access, but not by ithemes security plugin.
If your site is not having any SSL certificate, then change https to http for all instances. Since you uninstalled or deleted ithemes security, and getting 500 – internal server error, there is a greater possibility of misconfiguration in server side script, here it is .htaccess.
- Always use secured connection (SSL URL) to your cPanel.
- Always check last login in cPanel
- Some plugins (like Sucuri scanner) offering last login feature for wp sites. If you wish, u can install such plugins along with iThemes Security, and do verify last logins. These two plugins don’t have any conflicts in my experience. And one is not substitute for other.
- If possible use http authentication to your login url, if site is not having any subscribers.
- Last but not least, do spend some time on this forum. So that, u can excel in word press.
Have a great day.
With Regards,
B.V.RammannaRaau