Leaderboard

Good question. I'm not sure there's a simple answer though. What you mentioned about migrating changes directly from the database of WordPress doesn't sound like a safe thing to do with any database-driven CMS. The nature of a relational database is that there will be records in different tables referencing each other, so when you've got two versions of the same database, they would be challenging to merge. As a result, it's a problem if you have two databases going off on different paths of changes if they need to come back together at some point. I use my staging servers for staging things like new template files, modules, new PW versions, etc. I don't usually stage actual content from one server to another. Or if I do, I'm copying and pasting it (in PW admin) from one to the other. But the way I usually stage major content changes is to make them on the live server, but in a staging part of the site (unpublished, hidden or otherwise inaccessible pages). When ready to migrate, I publish or drag the relevant pages to their live home. Note that this is for content, and not for anything that could interfere with the operation of the live site. Anything that could interfere with the live site (templates already in use, modules, versions, etc.) ideally should be staged on a different server. I don't know of a better way than that. It's not perfect, but it's always worked well for me. Longer term, I want ProcessWire to support a workflow that lets a staging server talk to a live server and publish from one to the other (using web services). I already use this workflow on a lot of sites with custom modules, but they are specific enough to the individual sites that they aren't suitable as a broader solution. However, I do think we'll have a broader solution like this in the next 6 months to a year.

Hi there, welcome to the forum! This is easily achievable in ProcessWire. In PW, what are called pages, are not really pages. They are, more or less, what are called nodes in other CMSs. You can organize your content on the tree the way you want. In your website, would make sense to organize it just like in any regular website (about, why, gallery, menu, etc...). Then you call all the information from the homepage template. For this, you call the fields of individual pages like this: $pages->get("name=about")->body. So do, for instance: $about = $pages->get("name=about"); $gallery = $pages->get("name=gallery"); $name = $pages->get("name=menu"); $why = $pages->get("name=why"); and then use $about->body, instead of $page->body <div id="about"><?php echo $about->body; ?></div>

Hi all, My team has built a few ProcessWire sites, and we LOVE it - it is now our go to CMS. However, we have come up against the same issue on each site and wonder if/how any of you are managing it. I don't think the issue is entirely specific to ProcessWire, but due to the structure of the way PW stores data it may require an answer that only applies to PW. It's the issue of keeping a staging site database in synch with a live site. To illustrate: we start developing a new section, or modifying the functionality of a current section. All the while the client is making content changes on the current site, and in so doing changing the data in many different tables. Is there an approach, other than manually noting which tables have changed during our update, that people are using to manage this situation? With WordPress, for example, all of the content ends up in one big table, the structure of which doesn't change, so updates aren't that tricky. With PW data and structure being intermingled, it makes it a bit more tricky to manage. I'd really appreciate knowing more about how people manage this, even if it's just confirming that there isn't a better way than doing it manually. Thanks.

I've made a github repo, link added to first post, feel free to fork and improve

I built a single page site on ProcessWire and found it very well suited. I used the method of creating pages, then include()ing each in the index file. The important step for me in this was caching - without it the site would have performed too poorly. I set each template to cache for 24 hours and set the expiration setting to "Clear cache for the saved page and parents (including homepage)". With that the site loads quite quickly. As with any single page site there were other things to consider - SEO, deep linking - but those aren't specific to ProcessWire. Shoot me a private message if you would like some more info about how I ended up addressing those issues. Good luck! (Oh, if you want to check out the site I built, it's at http://agencypja.com)

You could also create various templates for the sections, and create them as pages underneath your parent/home. The php template would be just the section html markup with some content from the page. <section> <h2><?php echo $page->title; ?></h2> <?php echo $page->body ?> <img src="<?php echo $page->image->size(100,100)->url; ?>"/>; </section> Then in your top page (home) php template you'll be able to render them out simply with something like: foreach($page->children() as $p){ echo $p->render(); // will render the above }

I think it makes sense, and have recently had the same wish. Adam brought this up a long time ago, and I've been meaning to add it, but just haven't gotten around to it yet. Now that there's been another request for it, I'll push this forward sooner rather than later. Actually now that my mind is on it, I think I'm going to work on it over lunch break. The plan is that when you select a default sort at the template level, the option no longer appears with the page (i.e. template setting, if used, overrides page). If you select 'none' (the default), then it can still be set at the page level. When no sortfield is set, pages sort ascending by the database field 'pages.sort'. When you create pages in the admin, they should get added in the order you create them, as ProcessPageAdd manually sets this. That would look like 'created' order. But when you create pages in the API (or any kind of import process), and don't set the 'sort' field of a page, then they are all going to have the same sort value (0), which makes order unpredictable. I actually modified that yesterday when I was fixing the drag-sort issue that smd found, and committed it this morning. Now $pages->save() takes care of setting a $page->sort value if you don't, so it should be more API friendly. The reason we don't want to default sort by something like 'created' is for the reason Antti mentioned (no ability to manually sort).

Hi guys, I've made a big update to original Futura admin theme, this one is based on Futura Remixed code (completly rewrote the code with that one). I've included some tweaks based on posts by netcarver, alan & Adamkiss. Back to top button is located in the sidebar, sidebar moves quicker then before up & down and I've fixed the main menu. Screens: Download: https://github.com/nvidoni/futura futura-admin-theme-v1.1.zip

Couldn't find another topic on this, so I'm creating a new one. My idea (wish, if you wish.. no pun intended) is actually quite simple: wouldn't it make sense to enable sort order setting for templates in addition to individual pages? That way I wouldn't have to re-set sort order every time I create, for an example, a news page (which can only contain news items and thus has pretty much only one usable sort order throughout the site.) Also: current default sort value for new pages is "none", which can produce quite peculiar effects - apparently because DB itself uses some very obscure magic for deciding sort order - and I'm having hard time figuring out why anyone would wish it to act like this. As a second idea, wouldn't it be nice if default sort order was "created" instead of "none"? So - what do other folks think about these? Oh, and by the way, if there already IS a way to achieve one (or both) or ideas above, that'd be great (and in that case, sorry for the confusion!)

Hi, I am a newbie to programming and I am developing this site for a client of mine(WIP) : http://greenpantry.in/test820fcec/ It is a single page site, where the content is divided into sections. I want to know if it would be feasible to use Processwire to manage the content of the site. From what I have read, processwire's templating system is based on pages. I want to know if the client will be able to edit each section individually from the admin panel, as I feel creating a single long template for the page will be kind of messy. 'our platters' and 'gallery' are the two sections they want to be able to update. Btw PW looks so fresh and this is probably a trivial thing to execute. I just wanted to be sure it was possible before i dive in. If this is possible, any pointers as to where I can start will also be very helpful as I am just now beginning to go through the docs/videos. Thank you!

Add this to the top of your getModuleConfigInputfields() function. This should also solve the undefined variable notices: $data = array_merge(self::$defaults, $data);

I think the problem might be that $session already keeps it's own 'error' function and variable, which is an array. So it might just be a matter of naming and using something like 'login_error' rather than 'error'. Your current solution works because it's likely resolving to a session variable named blank or "0". But if you tried to do something similar anywhere else, then you'd have unpredictable behavior. As a result, I think it's best to give $session an actual variable name that you want to use, like this: $session->login_error = 'your message here'; and retrieve it like this: echo '<p>' . $session->login_error . '</p>'; using set() and get() is also fine, but not necessary.

Hello there, and welcome to the forum! What you're describing there sounds like something PW handles very well. You could, for an example, create all those sections as pages in PW and have one template file render content for all the others. Here's a post about somewhat similar concept: http://processwire.com/talk/topic/821-question-understanding-templates%E2%80%93advanced-templating/#entry6999. This way you'd create a template file for all individual sections (assuming that they actually have different markup & fields each) and then at some point, index / home page probably, render them all. Please note that I haven't done anything like this myself, but the concept doesn't seem too difficult - I'm sure others will be able to provide more helpful examples and educate us both about more sophisticated ways for achieving this result. ... actually, this sounds like a good idea for a nice little tutorial if anyone has some extra time ...

Here it is a first test version. Got it working with regular image fields, or thumbnail cropimages fields. You can specify any image field using the image field name in the advanced template setting for page label. To output an thumbnail (from the Thumbnail module) just use the dot notation. fieldname.thumbnailname (as specified in the thumbnail field settings) There's some option on this module for controlling the size of image and the container size, padding, colors. https://github.com/s...eListImageLabel Edit: Added support for multiple image fields. It will always take the first image.