ProcessWire Site Header and Footer Used in WordPress Blog

[quickjeff]

Hi Guys, 

We are working on a project which includes a new ProcessWire site and a WordPress blog.  The site is built in ProcessWire and the blog will reside in a directory labeled blog on WordPress (Same Server, Same Root, 2 databases).

Since the Blog should mirror the website, we need to find a way to pass the header and footer to the blog.  This way the user visiting the website will see they have not left the site but is now viewing a blog.  (hope I didn't confuse anyone)  

My question is, has anyone done this?  If so, how?

I have seen others cache the header and footer files from custom CMS's but not on a ProcessWire site. 

Any direction on this would be greatly appreciated. 

Thanks guys!

[Pete]

I'm going to skip the question "why" and leave that for someone else as I'm guessing there's a good reason for using Wordpress for the blog portion or you wouldn't be doing it this way

The way you could do this, without having to try and bootstrap ProcessWire with every Wordpress page load, is to use a caching method as you said. MarkupCache should be able to handle this I think: https://processwire.com/talk/topic/7-new-markupcache-module/

You would have to store all the header data in a varialble and save it to the cache (as per the examples in that topic), but it would have been parsed correctly by ProcessWire and would be standard HTML in the cache and therefore ready to use elsewhere. Same again for the footer. Then you should (theoretically) be able to just include those cache files into your Wordpress template files and hey presto!

It would be worth testing with a small bit of text in a MarkupCache cache file and seeing if that works.

[Martijn Geerts]

Pete has a nice option, here's an other: You could make a dedicated template for the header and the footer and include those. 

You could template cache or pro cache it!

include('http://www.processwire-install.com/header/');

include('http://www.processwire-install.com/footer/');

[Macrura]

I'm going to skip the question "why" and leave that for someone else as I'm guessing there's a good reason for using Wordpress for the blog portion or you wouldn't be doing it this way

guess i'm the someone else.. after just having built several blogs with PW, i do wonder why anyone would willingly use that awful WP interface, and the annoying media manager, not to mention things like featured image etc..  i guess for power bloggers, WP probably has some advantages, but most of my clients just need a simple blog that they can edit quickly and easily..

[rick]

As Pete and Martijn have suggested, you can automate including the PW-app header and footer in your WP theme file.

What I take from your statement, "...the user visiting the website will see they have not left the site but is now viewing a blog..." tells me that the blog is a secondary application to the PW-app. In other words, the WP-blog is not the primary attraction or interaction, but more of an add-on feature to your site.
 
If that is the case, have you considered using http://modules.processwire.com/modules/process-blog/ rather than two applications?

On a related note, I have no idea if WP has changed it's user login since I last worked with it, but you also have to consider that the admin-user login in PW is not the same as in WP. This will require the administrative user(s) to log in twice, once if working in PW and once in WP, or, you will probably need to write a bridge to log into both apps with one interaction if you want them to have access at the same time.

[quickjeff]

Hi Guys, thanks for all the feedback.  I will give these solutions a try. 

In regards to the arising questions for using WordPress, yes, I agree. Its NOT my CMS by choice. I actually have steered many away from it. 

The only reason we are still using it is for blogging. The client has multiple posts already and it would be too much of a pain to move away and meet our deadline. Therefore the blog is secondary not the primary application. Trust me, I would love to keep it all under one application.  

Unless someone has a solution for extracting all the posts and links? :-/

[adrian]

Unless someone has a solution for extracting all the posts and links? :-/

https://github.com/NicoKnoll/MigratorWordpress

I have used it successfully on two new sites and I know Septhiroth has also used it!

[quickjeff]

https://github.com/NicoKnoll/MigratorWordpress

I have used it successfully on two new sites and I know Septhiroth has also used it!

So let me ask you this, since the main site is on process wire, how would I import the posts without causing issues with URLs, and the existing page tree?

[adrian]

So let me ask you this, since the main site is on process wire, how would I import the posts without causing issues with URLs, and the existing page tree?

That's exactly what it is designed to do - if you import into a dedicated "blog" child page, all posts will be added to this tree without affecting anything else. I would caution you to do the import on a test PW installation first to make sure you understand all the import options and make sure there are no issues before doing on your actual dev site.

[quickjeff]

@adrian, wow this is pretty amazing! I am happy to hear that this may just work better than I thought. With the blog setup and a full site running as well, has anyone done this? If so, how well is it running? The site we are working with is running hundreds of pages in the site and soon ramping to thousands. The blog runs hundreds as well and continuously growing.

Thanks again for everyones great responses and big help! This truly is a bright bunch of developers!

[adrian]

Once the blog posts are imported, they will run just like other PW pages. The import itself is the only potentially tricky part. MigratorWordpress is configurable to match the names of the pages/templates/fields of kogondo's blog module, but if that isn't installed, then it will create all those pages/templates/fields itself. It will even import and create the users from the WP blog and assign the posts to the appropriate user. 

Once again, just test on a test PW site first so you learn all the options and make sure they are no conflicts / issues. 

[quickjeff]

@Adrian, great advice and thank you. I am definitely going to move everything to processwire versus having two systems for one company. I rather have them login once, and control what they need to control. Thanks again!!!!

[adrian]

One more piece of advise - if the blog you are importing contains a lot of images, the import can take 10's of minutes, so be patient. I have also had some reports that in some cases the dev had to run the import twice to get everything to work - I haven't experienced this myself, but this is one of the reasons the module is not officially listed in the modules directory yet. As I get bug reports I am working to improve things, so please let me know your experience and any problems you have.

[quickjeff]

@adrian - I tested the solution you recommended and we are almost 100% there. Its very fascinating how the module works. 

After setting up the blog, setting up the migrator and installing the sub module to migrate the posts from WordPress, we have encountered one issue. 

Sure we get all the posts and images and authors etc.  but we get duplicate Templates and not sure why.

Here is what I mean:

We setup style 1 of the blog manager/profile. 

So the tree is like this:

blog/posts/actual-url-to-post

But after the migration, we end up with:

/blog/posts/posts/actual-url-to-post

And none of the posts are in the blog dashboard.

We then can see duplicate templates were created. Posts and Blog Posts but they are different. Once I try to view a post that was imported, it doesn't have view as an option.  So technically, I was thinking of just changing the template to Blog Post(The correct template version, not the duplicate it created)and sure it makes it viewable but it erases all the content. :-(

On import we have tried all the settings, append, overwrite, replace and still no luck. 

Not sure what we are doing wrong. 

Any help would be awesome!

[adrian]

Because you are using the blog module you need to configure the MigratorWordpress plugin (Modules > MigratorWordpress) to use the field/templates/pages that module uses. The defaults for the module don't match, which is why it has created new ones.

If you take a look at what was created by the blog module, and replicate those - eg "blog-post", instead of the default "post" then everything should work as expected.

Remember this is designed to work without the blog module being installed - perhaps the defaults should match those used by the blog module.

Let me know how it goes after tweaking those settings.

You may want to set up another clean site so you have a fresh starting point until you get those config settings correct.

[quickjeff]

@adrian I am almost there. Grrrr! I am still messing with the settings of the Wordpress migrator. Although I now have Blog Posts under Posts. :-( hopefully I can figure this out shortly.

[quickjeff]

@adrian almost there! Had to change the template migrator settings now changing the field settings. Should have it figured out soon.

[adrian]

@adrian almost there! Had to change the template migrator settings now changing the field settings. Should have it figured out soon. 

Good to here - yeah, the migrator template and field name defaults are not matched up for blog module. I don't personally use the blog module (Kongondo has done an awesome job with it, but I don't need the dashboard and I prefer to set up manually to configure exactly to my needs). Also when migrating a WP blog, migrator by default, uses the template and field names that I prefer.

When you get a minute, it would be great if you could put together some tips for other users based on your experience. I think it's a pretty powerful took for getting more people using PW, but I don't think it's getting that much use at the moment.

I'd also love to here any suggestions that you might have for improvements.

[quickjeff]

@adrian Success!!! I have completely migrated a wordpress blog into a ProcessWire site running the Blog module! I will be writing a quick summary and explainer on how to successfully do this. I am sure there are others who are going to encounter this at one point. It will be nice to save a headache and get it done quickly.

[quickjeff]

So this is where we are with this setup now. 

In the Blog Module by Kongondo

The Blog Dashboard times out, could it be that I imported too many posts? Could it be I installed locally?

Everything else functions like a champ but this part is quite frustrating.

It's actually a fairly odd bug, I can go to /admin/blog/posts and categories, tags, authors, settings, cleanup but the dashboard times out. It will load forever and then fail. :-(

[adrian]

Sorry you are having issues with the blog dashboard. As I mentioned, I don't use it, so I am not sure how it works or what might be causing this issue. I saw your posts in the blog thread - hopefully you will get some help over there. 

Do you have debug mode on? Any errors there or in your php error log?

It might be useful to start inserting some log statements in this method:

https://github.com/kongondo/Blog/blob/master/ProcessBlog.module#L798

to see where things are getting to. There is a loop that iterates through all posts. I would also maybe start commenting out sections in this method to see if a certain chunk of code is to blame for the timeout.

There is also some code in that loop that checks for comment stuff. Did all your post comments import OK?

[quickjeff]

Here is the error I am getting now, after I enabled debug:

Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 32 bytes) in /Applications/MAMP/htdocs/website/wire/core/WireDatabasePDO.php on line 223

I am running Mamp and I just increased the memory_limit and the maximum_execution time. I had to crank it to 500M in order for it to work and 60 seconds. 

Is that normal? 

It works now, but takes a little while to load with the new settings on the php.ini file. 

[adrian]

What happens if you add a limit to the selector on this line:

https://github.com/kongondo/Blog/blob/master/ProcessBlog.module#L825

Make it like this:

$posts = wire('pages')->find('template=blog-post, include=all, sort=-blog_date, parent!=7, limit=10');

[quickjeff]

@adrian even with the limit, the load time is the same.  Almost makes me wonder if I should just hide the view for the dashboard, It doesnt really do much besides give you an overview. I think its more important to show posts. 

[adrian]

Ok, good to know - I am not sure what the problem with the dashboard is. If you don't want the dashboard, I would consider doing the migration again without the blog module installed at all - I think its main benefits are setting up everything for you and also providing the example front-end markup code - great for PW newbies, but I don't think you need either of those things. This way you can start with a clean setup (no existing blog related fields or templates) and the migrator will take care of adding everything as needed. Then just write the template code to output the posts and you are good to go. You can even steal some bits from the markup code from the blog module if it helps.