How do you make a Wordpress Theme part of the auto update check. I know you can plug in to the plugin auto updater, to add/remove plugins from the auto updater, but how do you do this with themes?
I tried digging through the Twenty Ten theme, but there is no code anywhere which defines how it auto updates, or registers it for auto update. Yet, it auto updates with Wordpress.
Any help would be greatly appreciated.
EDIT: Should have specified, my theme is not in the Wordpress repository. It will be distributed separately.
Hook into pre_set_site_transient_update_themes
Because your theme does not reside on the Wordpress repository, an easy methodology is to incorporate file access in your theme. A quick way to do this:
Incorporate version control within a master file in your theme. Create a "version.php" file that has a PHP variable like version = 1.1
Create a directory where your theme files will be hosted on your own site. Create a "version.txt" file in that directory that only contains the latest version number (i.e.: 1.2) and no other text or numbers. The URL might look like domain.com/repository/version.txt.
Design your theme to open the contents of domain.com/repository/version.txt and use PHP to compare the numbers of each. If there is a newer version, then download the latest version of the theme as a ZIP.
$version = floatval(file_get_contents('domain.com/repository/version.txt'));
// note use only 1 decimal to keep it simple and prevent floatval() from failing
if($version > $localversion) {
copy("domain.com/repository/version".$version.".zip","theme/tmp/version_temp.zip");
$zip = new ZipArchive;
$res = $zip->open("theme/tmp/version_temp.zip");
if ($res === TRUE) {
$zip->extractTo("theme");
$zip->close();
echo 'ok';
} else {
echo 'failed';
}
}
You'll need to take that code, refine it, and account for file permissions and what works best for performance.
The update API is split in three: core, plugins and themes. All are hosted on wp.org, and the mere existence of your plugin/theme in the WP repository makes it auto-updated without a line of code beyond the standard plugin/theme headers and readme.txt files.
wordpress.org has an API listening for plugin/theme update requests. The client is the local WordPress installation that sends those requests to WordPress.org, and waits for a reply. The local WordPress installation uses wordpress.org as a default, but the remote API can be any custom URL, such as example.com.
If your local WordPress installation is on example.com it will need a custom plugin that is built to act as an API that listens for update requests using HTTP(s) from your plugin/theme installed elsewhere, or even on the same server.
For a plugin/theme to send the API request to a server, such as example.com, rather than wordpress.org, you would need to build client software, such as a client class, to send the API request to example.com, and when the client receives the HTTP(s) response it would hook into one of two filters:
pre_set_site_transient_update_plugins
pre_set_site_transient_update_themes
One filter hook is for plugins and one filter hook is for themes. Those are not the only hooks available in WordPress.
To summarize, a client library needs to be built for the plugin for theme to send HTTP(s) requests to an API located on a server, such as at example.com. A plugin must also be built and installed on the server, such as on example.com, for an API to listen for client HTTP(s) requests.
What is done with those HTTP(s) requests on the client and server can be customized however you'd like, but it takes time to develop a solution. There are free and commercial solutions available that may meet your immediate needs, or you can use one of those solutions as a start to create your own custom solution.
Here is the request and response flow:
client ->(HTTP(s)) request)-> server(API)
server(API) ->(HTTP(s)) response)-> client
Here are two solutions as an example:
(Free) wp-update-server from YahnisElsts
(Commercial) WooCommerce API Manager
There are other solutions and tutorials out there currently that a Google search can help locate.
Keep in mind, any solution you develop should have security at the forefront, so as not to expose your server to a hack, especially since you are exposing an API on your server. This is one reason I included a commercial solution as one of many solutions available.
Related
I have a security question. I gave the WordPress admin access to someone for a series of changes. Could he use the shell or any other way to infiltrate the server and access other hosts on server?
By default, any user that logs in with administrative permissions can access the WordPress plugin and theme editors, and change any theme or plugin file on your site in real-time.
– From https://wordpress.org/support/article/editing-files/
That, in theory, leaves your server open to arbitrary code execution. You might consider mitigating this default vulnerability by reviewing trellis's approach of locking down the root user, and bedrock's must-use-plugin-autoloader.
(It's very cool, you define your plugins in a composer.json file. Here's the magic sauce of that.)
"installer-paths": {
"web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin", "roots/wp-stage-switcher"],
"web/app/plugins/{$name}/": ["type:wordpress-plugin"],
"web/app/themes/{$name}/": ["type:wordpress-theme"]
},
That prevents "writing" new code to the theme/plugin folders outside the context of a theme deploy, and so elides the concern of WP admins writing whatever code they like.
(However, if you're assuming a malicious admin, you might be in need of social as much as technologica approaches.)
Short Answer:
No
Long Answer:
This kind of credentials can be used only from wordpress instance.
He can modify some lines of code by using a custom plugin but he cant go outside the theme folder.
Some plugin can modify the wp-config.php but no more.
By settings you can negate the GUI Plugin installation, so only the server administrator via FTP can install them.
In general, this credentials can modify only file of that wordpress installation because there are present on that Wordpress-DB
None can access via ftp/ssh because he needs user/password and IP of that server.
I have a WordPress website hosted on Amazon Ubuntu.
Amazon reported that my server is sending a WordPress login attempt requests to other servers on Amazon.
My website is just a landing page with a contact form. How do I prevent such incidents?
You can block external http requests check adding
define( 'WP_HTTP_BLOCK_EXTERNAL', true );
in wp-config.php
Since you have already found a bad curl call in your source, I strongly suggest you check the integrity of your Wordpress installation.
If you have WP CLI available you can do this with the command wp core verify-checksums.
If you don't have WP CLI available you can use this excellent solution by Jan Reilink (either directly or as a starting point for your own code).
Either way you'll get output that tells you whether or not additional files have been modified (you could then restore them from the same WP version source). This will not be a catch-all-method in regards to malware, but I think it can be helpful in your specific situation.
Given that the code that's causing these requests is not part of the Wordpress core the answer to your question is some of the general best security practices for Wordpress:
Keep Wordpress and plugins updated
Use strong passwords for users
Add a captcha and brute force protection to your login page if possible
I have this:
A rails app on Heroku that servers mydomain.com
A WP site on another hosting (that I can move to AWS .. or even heroku)
I need that mydomain.com/blog serves the WP installation, I DONT want it to be a subdomain for SEO.
My first idea was setup apache / nginx as reverse proxy on a instance on AWS. However I worried that this setup is not optimal as backends are in different services.
It's possible to setup heroku dyno as a proxy? I understand there is no way to modify the system files on heroku, like create a custom nginx setup to do the proxy. I was wondering if there is some application that works as a proxy and can be installed in heroku, next setup the blog in heroku also.
Or it's a good idea to setup an AWS instance as proxy in the same region that the heroku is (us-west1), and setup the blog also there.
I'm interested in the pros and cons of each solution and what would be the best way to go.
I had tackled the same exact problem with Rails and WP for quite some time.
My configuration and result:
Rails app is hosted on heroku (www.sexycrets.com)
WP Blog is hosted on another server (blog.sexycrets.com)
When the browser requests www.sexycrets.com/blog he receives the same html page that he would have received if browsing blog.sexycrets.com and the url on the browser remains the same
How I achieved it
One solution that does works well for SEO is to use a gem as reverse proxy (I use drewwed/rack-reverse-proxy from Github). You can configure it to intercept the route "/blog" (and "/blog/") so that every time Rails is asked for /blog it loads your WP site with a backend call and returns it to the user. This is a completely transparent operation from the user browser perspective, aside from the delay introduced. The user browser has no way to know that the blog page returned in the response was loaded from another server, the url on the browser remains "www.sexycrets.com/blog".
Pros: SEO requirements are satisfied
Cons: Performance since the reverse proxy is not very performant in terms of delay introduced
Alternative
For sake of completeness the other option I tried was to use an iFrame in a static page hosted on heroku that loads the WP. The problem is that in order for it to work avoiding a circular reference all the links in the WP blog have to point to blog.sexycret.com (not www.sexycrets.com/blog) which partly defeats the SEO purpose.
Pros: Performance is very good since it is not even using Rails: the user browser loads the static /public/blog/index.html page that contains just the iFrame that points to the WP blog
Cons: the links in the blog are not pointing to the main domain but to the 3rd level domain defeating
Hope this helps!
I am trying to optimize a Wordpress at his best.
What I have done up to now :
WP-Cron disabled, called through a cron-tab query (every 10 min)
Disabled all plugins that aren't needed
Installed / configured WP Super Cache together with WP Minify
Disabled Revisions (but then re-enabled it because I was getting empty posts (strange)
Put a subdomain as a CDN for images and scripts
here is a classic report of Resource Usage on my control panel :
57.0% .../index.php ()
7.0% php -q ../wp-cron.php ()
5.0% httpd (...)
Specs :
Around 5000 unique visitors / day
I would like to avoid moving to a dedicated server (this a shared hosting) or at least try everything I can before having to move.... any idea?
I use the Total Cache plugin, the free version and it works very fine. I don't have problems with new posts.
http://wordpress.org/extend/plugins/w3-total-cache/
This plugin does everything also minify html,javascript and css
As pointed out by Ahmad Suhendri, dedicated server was a good idea. I moved to a dedicated server and now the website is very fast.
I've created a web application based on this free Wordpress Theme:
http://vandelaydesign.com/blog/wp-themes/simple-non-profit/
All ok in localhost environment, but when I uploaded the site on remote (PHP + MySQL + Email active), the admin panel changes, and shows me only a part of whole admin menu.
e.g., admin panel doesn't show me the theme customization page and the slideshow customization page, that instead, in local environment, I have it.
Can you help me??? Thanks!
It might be that the live server is running a different version of PHP, or has config settings that make it different from your local environment.
However, my guess is that you haven't modified the database properly when you transferred it and that is the cause of your problem (I would suggest that it's nothing to do with the theme).
Moving Wordpress databases from your local development environment to live can be a massive pain because Wordpress (and lots of plugin/theme developers) use serialized arrays to store data. So if you do a find-and-replace on the database to replace your old url with the new one, you will disable lots of things like config settings and widgets (text widgets specifically, but there's loads of stuff you end up having to recreate).
Download this file;
http://interconnectit.com/124/search-and-replace-for-wordpress-databases/
and upload it to the server and access it directly in your browser. Run through the quick form and perform a serialized array-friendly find and replace on your database urls. Job done.
Delete the database on the live server and copy the local version of the database again, but this time use the instructions in the thread above to change all the instances of your local url path to the live domain url.