i have multiple sites (30) on my VPS with the same template into the /wp-content/themes/ directory and when i have to update the theme i have to do the operation on thirty folders.
It's possible to link with a Symbolic Lynk to the folder of the theme into the /wp-content/themes/ directories?
I want to do something like this if it's possible:
/var/www/<theme_folder>/ -> /home/<user>/public_html/wp-content/themes/<link_theme_folder>
Can wordpress recognize the folder with a "special" Sym Link?
Thanks for your help and sorry for my bad English.
Have a nice day.
I tried locally and WordPress 4.x did not detect the symlinked folder, so I guess it's a no-go.
What you should consider is migrate your 30 WP installations into one multisite (or "network") configuration.
This will allow you to centralize plugins and themes for all your websites in one interface to rule them all.
You will need to organize the migration:
- setup a new WP, configure it as multisite.
- all plugins used by all of your 30 sites should be imported into this Wordpress, along with their configurations (I'd do that manually);
- Add your Theme to the themes folder;
- recreate the users;
- export the posts from each site as an xml file;
- import each xml file to its related new blog;
- You will need a Domain mapping plugin so that each blog has its own Domain name. (site1.com, site2.com instead of site.com/site1/ urls).
Tips:
Tell your customers that you need to "freeze" their websites for the necessary time (meaning: no more touching the CMS, adding posts, changing configurations).
Practice on a local copy first to play around first.
Work on another, separate, domain name during the setup. When the sites are all properly replicated, update the DNS registry of the 30 sites to point to the new multisite WP. This way, no downtime!
This can take some time but will make it much easier for management and for adding new sites in the future.
Related
I have big dilemma and I need help.
Basically we have sitecore web app this is our main web service. Currently my app is working with the main app via .html static pages(it works as SPA, JS calls backend with needed html content).
But database I work with grows bigger, and to access certain elements with URL I need to create ~70.000+ static files. As well this static files are needed for google indexing, so we can advertise our products. In case if there is new meta data needed or new item added, I need to run my other program that creates this static files to update everything out of txt file with all items. And we have 2 reserve servers where our sitecore web is. So it like 70k+ files for 9 languages and 3 web servers. It takes a day to recreate everything...
That why I decided to make clear MVC SPA application, and it works great. But...
I can't add my MVC application or anything except .html files to the current sitecore main app.
And the question is: how it could be done without losing google indexing and without changing main domain.
For example we have now:
www.ourdomain.com/foldername/mystaticfile.html
What I want:
www.ourdomain.com/mynewmvcapplication
Sitecore has a settings called IgnoreUrlPrefixes. You can add mynewmvcapplication to this setting, in that case Sitecore will ignore that path as well as anything under it. Here is a good article which shows you how to update this setting without making an update to Sitecore's config files.
Take a look at Sitecore Redirect Manager Sitecore market place. This it has the capabilities to create your custom url and keeps your search engine rating.
https://marketplace.sitecore.net/en/Modules/Sitecore_Redirect_Manager.aspx
Otherwise you can check Custom Link Provider and Custome Item Resolver. This will need more coding than the previous one. A google search with those keywords brings back many results.
Best wishes.
Much to my surprise, it is not a five minutes-task at all. Spent almost a day without achieving anything...
My existing website notgoodname.com is running well for months. And I want to change it to goodnewname.com (already bought it) . Ideally, I would like to do it the way that impact users least (least downtime, 0 data lost), SEO n others are second priority.
Initially, I was thinking about having goodnewname.com and notgoodname.com sharing same IP, same hosting ressource (php code, mysql db), then gradually retire notgoodname.com. However, Googling can't help, godaddy support neither, both gave me confusing guides.
Please lend me some guidance/good links.. (my background: ~10 year as software developer but just few months webmaster : cpanel/WHM/hosting/dns kinda stuff)
Firstly, I would like to congratulate you on goodnewname.com, what a find. :P
The easiest hassle free way to use the new domain is to add it as a parked domain under the cPanel account of the existing website, you would also need to change the nameserver to point at WHM's/YourHosts nameservers, or, and a root A record pointing the domain to your web server's IP.
If the website is quite straightforward (PHP, CSS, HTML, no databases etc..) you could instead of adding it as an addon, create another hosting account for the new name, copy all the files across from wwwroot (public_html) on the old account to wwwroot (public_html) on the new account and then delete the old account and add old bad name as an addon.
Update:
Since this question was asked Joomla StackExchange has been setup and the same questions exists there please add any answers or comments to that question
Original:
I am using Joomla 3.0.3 for a fairly big new client, security is a must. I therefore decided to try change the Administrator URL, normally
example.com/administrator
changed to
example.com/newadminurl
Reason being if the folders aren't where potential hackers expect that is the first hurdle before they can even try anything else.
However that has now meant whenever I go to the new URL it brings up a 403 error. I have tried searching if there is a global config setting I need to change but can't find anything on the web or Joomla site. Anyone know how to change this deep down in the source code?
Step 1. Create a new directory in your root directory (eg. "newadminurl")
Step 2. Create an index.php file in your "newadminurl " directory..
$admin_cookie_code="3429020892";
setcookie("JoomlaAdminSession",$admin_cookie_code,0,"/");
header("Location: /administrator/index.php");
?>
Step 3. Add this to .htaccess of your real Joomla administrator directory
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/administrator
RewriteCond %{HTTP_COOKIE} !JoomlaAdminSession=3429020892
RewriteRule .* - [L,F]
Explanation:
Now, you need to open "http://yoursite.com/newadminurl/" before you open your “administrator” path. Here we have created a cookie that expires at the end of the session and redirect to actual administration page. Your actual “administrator”path is inaccessible until you don’t open on your secret link .
I hope this is what you were looking for.
While there are hacks around that do this, they introduce new security issues as the Joomla! core isn't built to work this way.
In fact the it is common practice both in the core and in 3rd Party extensions and templates to load models, controllers and other assets from /administrator.
The best practise is to secure your site is:
Keep your Joomla! installation up-to-date (the most common cause is outdated installs)
Don't hack core files, if you need extra functionality duplicate the core component and extend that, not the core.
Add a realm password /administrator
A secret word on the /administrator url e.g. /administrator/?s3cr3tpa55w0rd
An ip whitelist that only allows on select IP addresses to access /administrator
Use unique and strong passwords
Don't share passwords even with your significant other...
Enact a password policy on your site.
Keep a tested and regular site backup in an off-server storage location.
Run a file scanner to help you detect a hack so that you're aware of where your last good back was taken.
You can find extensions that do one or several of these things for you in the Access & Security section of the Joomla! Extension Directory (JED), and for integrated backup to cloud or other storage you can't go past Akeeba Backup (and personally for the tiny fee compared to the cost of my time we always go with the Pro versions).
In fact Akeeba's Admin Tools Pro (included in any of their subscriptions) also provides most of the features on that list through it's WAF (web application firewall). The only area not covered is Password Management of which there are several solutions available.
There might be all sorts of dependencies in the core and in third party extension that will hard code the admin path, even though there are platform variables to assist this.
I would recommend that you instead configure your .htaccess to prevent public viewing of your administrator folder and restrict access only to approved IP addresses. This will prevent them from accessing the admin folders, but of course will not protect against attacks which do not require direct access (e.g., some third party app that calls code in an admin folder for the component from the front end).
Note: This goes in the .htaccess file in your administrator folder not the .htaccess in the site root, i.e. [siteroot]/administrator/.htaccess
Here is an example of the .htaccess you may configure:
ErrorDocument 403 http://www.your-ip-is-not-allowed-to-access-this-section.com
Order deny,allow
Deny from all
Allow from X.X.X.X
Where X.X.X.X. if the IP address you want to allow to the admin section. You can specify multiple addresses with multiple Allow from X.X.X.X lines.
I have yet another .htaccess question, simple for you, not so much for me.
Let's say my main site is found at http://domain.com. I do all of my pre-release testing at sandbox.domain.com and sandbox.domain.co. I just realized that Google has gone ahead and indexed my sandbox sites... Ugggh!
The document root folder on my Apache server with the live site is always called ALIVE, and in order to make my sandbox contents live I quickly rename the folders, ie ALIVE->OLDx, SANDBOX->ALIVE.
My goal is to prevent indexers and users from accessing my sandbox pages. I am trying to design a .htaccess file for document root that only allows my ip address when accessed from a sandbox subdomain (sandbox.domain.com), otherwise it allows everyone when accessed from the main domain (domain.com). This would eliminate the process of remembering to update the .htaccess file each time I release a new site.
This doesn't seem too difficult, but I haven't been able to find the right combination. Any pointers in the right direction will be much appreciated!
Create a .htaccess inside each folder (like sandbox):
order deny,allow
deny from all
allow from YOUR IP HERE
I'm creating a custom master page for my SharePoint 2010 publishing site. There are images, css files and js files associated with this custom master page. Where should they be stored?
I'm using the SiteAssets library for now - is this a good choice?
Thanks.
Yeah that is a good choice, also make sure you Provision all these files using Feature, this way upate of Files becomes easier.
In my opinion, you should store everything under the site collection libraries, this way you get:
Easy recovery in the cases you need to re-install the server[s]
Versioning and permissions on resources
Separation of resources between site collection
Simple deployment between environments, as you do not need to copy the files manually or design and deploy a feature to do it for you
The preferred place is of course Style Library, this is what it is intended for.
If you are creating and deploying your files through code, you can also use the _layouts directory to store your files. This makes it simpler to share files between site collections. Visual Studio 2010 makes it really simple to add a reference to the Images folder and any files will then be deployed to the _layouts/Images URL.
The only advantage of this is that a site collection administrator cannot make changes to these files, only someone with access to the physical server. (Although this can also be a disadvantage if your logos or images are changing regularly).
I usually store them in _catalogs/masterpage/ORGNAME/...
You can refer this blog for actual implementation
http://markviky.blogspot.com/2010/11/sharepoint-2010-web-content-management.html
-Vighnesh Bendre