WordPress admin redirecting on Nginx

Leave a comment
nginx-logo-square

I had an odd problem this morning.  I moved my blog over to a new VPS last week, switching from Apache to Nginx w/ PHP-FPM 7.  But when I tried to log in this morning to do a quick blog post on starting Solr on CentOS 7 (which I eventually did not do) but I found that I was getting infinite redirects on my login page.  Turns out that my Nginx configuration was wrong.  Following is the Nginx configuration I had

server {
 listen 80;
 server_name eschrade.com www.eschrade.com;
 root <root>;
 index index.php;
location / {
try_files $uri $uri/ /index.php;
 if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
 }
 location ~* \.(gif|jpg|png)$ {
    expires 30d;
  }
  location ~* \.php$ {
   fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   include fastcgi_params; ## See /etc/nginx/fastcgi_params
  }
}

Following is the configuration that works.  It is a very slight change (try_files) but it apparently makes a world of difference.

server {
 listen 80;
 server_name eschrade.com www.eschrade.com;
 root <root>;
 index index.php;
location / {
try_files $uri $uri/ /index.php?$args;
 if (!-e $request_filename) { rewrite / /index.php last; } ## Catch 404s that try_files miss
 }
 location ~* \.(gif|jpg|png)$ {
    expires 30d;
  }
  location ~* \.php$ {
   fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
   fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
   include fastcgi_params; ## See /etc/nginx/fastcgi_params
  }
}

Integrating Zend_View with WordPress

5 Comments

I just read a blog post about integrating Zend Framework and WordPress and figured I’d add some commentary of my own, since I’ve done something similar.  In my ESchrade plugin I use Zend_View to render some of my admin pages, though there is no reason why you couldn’t use it elsewhere, as long as the plugin has already been loaded.

Getting Zend Framework set up with WordPress is super simple.  Assuming you have Zend Framework already in your include path all you need to do is put the autoloader in your plugin file.

Here is a very slimmed down version of my plugin class that integrates with WordPress.  From the Zend_View perspective, all it really does create a new view object and set it up.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
namespace com\eschrade;
 
class Application
{
/**
*
* @var \Zend_View
*/
private $view;
public function __construct()
{
$this->view = new \Zend_View();
$this->view->setScriptPath(
realpath(__DIR__ . '/../../../templates')
);
$widget = new Popular($this->view);
wp_register_sidebar_widget('popular-posts', 'Popular Posts', array($widget, 'handle'));       
}
 
public function setView(\Zend_View_Interface $view)
{
$this->view = $view;
}
 
public function getView()
{
return $this->view;
}
 
public function handleJobs()
{
$this->view->jobs = new Jobs();
$this->view->jobs->setAction('/wp-admin/plugins.php?page=eschrade-config&action=Run Job');
$this->view->jobs->setMethod('POST');           
$this->view->jobs->setView($this->view);
// cut
echo $this->view->render('admin/runjobs.phtml');
}
}

Obviously you don’t have the view renderer set up, or some of the controller helpers that are so useful, but if you want access to anything that Zend_View has to offer it is thuper eathy to do.


Added (PHP 5.3) job queuing to my WordPress instance

4 Comments

One of the things I liked on my old blog was the ability to have a Popular Posts section that was based off of Google Analytics. I had also like that I was using pre-caching, i.e., a cache that does not expire but is, rather, overwritten.  There are two benefits to this.  1) There is no lag time when the cache expires and I need to contact Google to get new data. 2) If my connection goes down for whatever reason (bad data, time expired, modified password), the data stays in the cache until you can get the problem fixed.

So I had missed that, but it was not overly important so I left it.  But yesterday was a day where I needed something that was both engaging and brainless to do.  So I decided to implement my Job Queue API code for WordPress so that I could write a WordPress widget that would put the popular posts in the sidebar.

It was actually relatively easy to do.  But the cool part was that I was able to extend WordPress, which still contains code that was written around when the Martini was invented, and PHP 5.3 code, which is what my Job Queue code was based off of.  This is part of some “ESchrade enablement” which I am building as a WordPress plugin and so it contains some other stuff than just the JQ part of the plugin.  You can download it from here and put it in your wp-content/plugins directory.  There are some things that aren’t working quite right yet, and probably won’t.  I don’t really have the desire to become a WordPress developer.

What have I learned or re-enforced from this?

  1. PHP backwards compatibility is pretty darn good
  2. If you build a software application, make building plugins easy, even if it’s your own app.  (WordPress is kind of win/lose on this)  I may end up looking at Event_Dispatcher.

Migrated the blog… to WordPress

5 Comments

to WordPress?

Yep.  I had written my blog from scratch, partially because I wanted to use it as a testing ground for various ideas and such.  However, part of the problem of maintaining your own blog software is maintaining your own blog software.  I think that I’ve pretty much milked the code for all it’s worth.  So now I’ll stop maintaining my own code and start using someone else’s.

But… WordPress?

Yep.  Let’s face it; the code base is a horrible stinking mess.  The API is not intuitive in any way, shape or form.  WordPress pretty much gets everything wrong…

… except that it gets the job done.  Way too many programmers are way too proud of their code.  Well, not really.  They’re proud of their ability and they like any opportunity to talk about how great their abilities are.  PHP was never about that (though we have our share of egotists).  PHP was about getting the job done.  Do I wish that the WordPress engine had a better architecture?   Absolutely.  Do I wish that the API was remotely intuitive?  Yep.  But the long and the short of it is that I don’t have the time to maintain the code base for a blogging application.  So I use one that already exists, has plenty of templates available (I’m the world’s second worst designer) and has a large community around it.

So, yes, WordPress.