Leaderboard

I am new to ProcessWire. I am not new, however, to programming (started with assembly back in the '70s). I'm not writing a marketing speel here -- I simply want you (the developers and community) to know how I arrived at ProcessWire as my solution. I have specific requirements for a numer of projects that I will be starting (hopefully) in the next few days, and had been researching various CMSs and frameworks the past few weeks to find a 'one-size-fits-all' toolbox. I have currently forty-four cms installs (from academic to zikula) and thirteen different frameworks ( from akelos to zoop). They all have their merits, and are fine solutions for many users and developers. ProcessWire is one of the original 44 installs, but at first 'glance' didn't seem to fit what I was looking for. Later, after searching the web for a solution to one particular issue, a link back to a PW solution emerged. I clicked the link, and low and behold, ProcessWire *was* what I had been searching for all this time. On a related note, google has sent me a nasty-gram about the reactor they had to fire up because of my queries. The primary strength of ProcessWire that I have discovered so far, is that I (as a developer) am not limited in the tools I can use, or the tools I can create. ProcessWire is sleek and efficient. It is a toolbox full of tools that allow me to build a fine watch, a multi-story office complex, or a fishing pole. The other applications suffer from either bloatware or limited tool availability, or worse, both. I could very well accomplish my project goals using any of these other applications but with much head-banging, hair-pulling, and cosumption of scotch. The biggest 'selling' factor to me for ProcessWire, however, was it's efficient engieering in the construction of built-in tools I will require now, and the ability to create my own tools for use in the future.

Hello all! I'm not sure if this is the correct forum to post an introduction, but I didn't want to clutter a specific topic elsewhere. I've been reading various forum topics, wiki, and docs, for the past twenty or so hours and decided to sign up last night. I just want to say that I am impressed with Processwire itself, as well as the community's eagerness to assist us newbies. I'll most likely have a number of questions later. As of now, I suffer from information overload due to the amount of reasearch over the past few weeks. I'm sure some of you old-timers, like myself, are familiar with *Tilt*, which is currently emblazoned on the back of my eyeballs. I look forward to learning and working with PW on a number of up-coming projects, and eventually become a contributing member of this community. Thanks for having me. Best regards, Rick

I highly recommend reading the second post, too before implementing anything, as it might simplify a lot, depending on your setup.. Because I just updated all MarkupCaches with newer WireCache, couple of weeks ago, and really like it, I thought why not share it. So I got _init.php as prependTemplateFile, and _out.php as appendTemplateFile. But let's check out the interesting part, for example an article.php template. but for some pages, for example blog, it makes sense to include all children ;-) You can include any page you like, or define a time or a template as expiration rule. Here my defaults from the _init.php $cacheNamespace = "hg"; $cacheTitle = "$page->template-" . $sanitizer->pageName($page->getLanguageValue($en, "title")) . "-$page->id-{$user->language->name}"; $cacheTitle .= $pageNum ? "-$pageNum": ''; $cacheExpire = $page; I'm not exactly sure if there is any benefit in using a namespace, you can omit the namespace part and if needed just prefix the cache title. Works both. You'll see why I added the namespace/prefix a little later ;-) For the title I'm getting, the template, english page title (you can of course use the language title and omit the language name part, but I liked it better to have the caches grouped.. After language name I'm adding the page number if present. If you need you can of course create a different, more or less specific cache title. Add get parameters or url segments for example. Then I have $cacheExpire already set to $page as default value, so I don't need to set it in every template So my markup (only the important parts) looks like this: //You can have anything you like or need uncached above this $cacheExpire = $page->chilren(); $cacheExpire->add($page); $cache->getFor($cacheNamespace, $cacheTitle, "id=$cacheExpire", function($pages, $page, $users, $user) use($headline) { // as you can see, within the function() brackets we can pass any Processwire variable we need within our cached output. // If you don't need any you can of course leave the brackets empty // and if you need any other variable wich you had to define outside this function you can pass them via use() // so here goes all your markup you want to have cached // for example huge lists, or whatever }); // Then I have some more uncached parts, a subscription form for example. // After this comes another cached part, which gets -pagination appended to the title. Otherwise it would override the previous one. // It's not only caching the pagination, I just needed a name for differentiation. $cache->getFor($cacheNamespace, $cacheTitle.'-pagination', "id=$cacheExpire", function($pages, $page, $users, $user) use($headline) { // so here comes more cached stuff }); After this your template could end or you can have more uncached and cached parts, just remember to append something to the cache title ;-) Now comes, at least for me, the fun part haha In my prepended _init.php template file I have the following code under the cache vars: if($user->isSuperuser() && $input->get->cache == 'del') { if($input->get->clearAllCaches == "true") { $allCaches = $cache->get("hg__*"); foreach($allCaches as $k => $v) $cache->delete($k); $session->alert .= "<div class='alert alert-success closable expire'>All (".count($allCaches).") caches have been deleted. <i class='fa fa-close'></i></div>"; } else { $currentPageCaches = $cache->get("hg__$page->template-" . $sanitizer->pageName($page->getLanguageValue($en, "title")) . "-$page->id*"); foreach($currentPageCaches as $k => $v) { $cache->delete($k); $session->alert .= "<div class='alert alert-success closable expire'>Cache: $k has been deleted. <i class='fa fa-close'></i></div>"; } } $session->redirect($page->url); } So when I append the parameter "?cache=del" to any URL all cache files within my namespace and beginning with the predefined $cacheTitle will be removed. Means all language variations and the "-pagination & -comments" caches will be deleted, too. This is the else part. But if I append "&clearAllCaches=true", to the first parameter, it will get all caches within my namespace and clear them. Without the namespace it would clear Processwires caches (like the module cache), too. I'm storing a little success message in a session called "alert" which is closable by the FontAwesome icon via jQuery and expires after some seconds, means it will remove itself, so I don't have to click ;-) Maybe it makes more sense to change the cache title and have the page->id first, so you could select all related caches with $cache->get("hg__{$page->id}*"); I liked them grouped by template in the database, but maybe I change my mind soon because of this For not having to type those params manually I have two buttons in my _out.php template file. I have a little, fixed to the left bottom corner admin menu with buttons for backend, edit (current page), and now clear cache button which unveils the clear all caches button on hover, so it's harder to click it by mistake. When someone writes a comment, I added similar lines as above, after saving the comment, to clear comment caches. Ah, the comment caches look like "-pagination" just with "-comments" appended instead. I don't know if there is an easy way to expire a cache when a new children (especially backend created) is created, other than building a little hook module. With MarkupCache it could be a pain to delete all those folders and files in /assets/ folder, especially with slow connection. The database driven WireCache makes it much faster, and easier when set up those few lines of code to make it for you. more about WireCache http://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/core/WireCache.php Hope it helps someone and is okay for Tutorial section, if you have any questions, suggestions or ideas feel free to share. Hasta luego Can

wire()->addHookAfter('InputfieldURL::render', function($event) { $field = $event->object; if($field->name != "yourField") return; $url = $field->value; if($url) return $event->return = "<img src='$url' width='100' alt='' />" . $event->return; }); This should do the job pasted at the beginning of site/templates/admin.php.

Just a few quick notes: The sites directory, or the developers directory, are our best bet at identifying sites, companies, and developers using ProessWire. On the other hand, these are a subset of the real figures – for an example, none of the sites our company has built using ProcessWire are listed there (that's a longer topic, not going there right now).The truth is that we can't tell for sure just how widely ProcessWire is used, partly because it's built in a way that makes it possible to completely hide the fact that a given site is powered by ProcessWire. Which is a good thing, really. We do know that it's gaining momentum, and it's also quite safe to say that it's usage is nowhere near that of WordPress If, for any given reason, the lead developer had to step down, development would no doubt continue.We've got plenty of capable folks around here. It's pointless to speculate whether that would lead to one or more forks and what else might or might not happen, but I'm confident that ProcessWire wouldn't go away that easily. Personally I've always found the question of "how do we find another developer for a project built with platform X" somewhat off.First of all, this question completely ignores the fact that each system is different. ProcessWire is particularly easy to learn and understand, and unlike (apparently) with certain other platforms, there's no year-long learning period involved. A developer with basic knowledge of PHP and web development in general should be able to just step in without any major delays. To be fair, this also applies to WordPress, and other even remotely sensible platforms. Building sites with a CMS/CMF is not rocket surgery, and while years of experience with given platform will give you an edge over someone less experienced with said platform (you already know some of the possible pitfalls and shortcuts), that's all there is to it. What's much more important is how a particular project has been developed so far. Just like with any other platform out there, it's possible to build broken and overcomplicated crap with ProcessWire, while (and this is at least partly opinion-based) it's not as easy as with certain other platforms. The flexibility of ProcessWire means that even if the previous developer made some pretty horrible choices along the way, it should still be possible to salvage some parts and rewrite others. In the end it's always better to just brace yourself and tell the client that the whole thing needs to be blown into pieces than attempt to forcefully breathe life into a project that's already rotten to it's core, regardless of which system it was built with.

A conversation from the GITHUB issues which I thought to be useful to have in this Forum's knowledge base. Ryan Cramer put some valuable information there, which should be searchable in this forum, i.m.h.o. My Summary: Use the "autojoin" option on pagefield (when allowing multiple pages) with care. There could be unwanted side effects especially if you use more than one of these fields with that setup on a single template. Original conversation: tbba asked: I have 2 page fields (one is the clone of the other - so they are unique apart from the name). Both are used on a template. The first field DOES remember the (dragged) sort order of the pages, the second does NOT. Has anyone else have the problem too? Is this a cache problem, or corrupt indexes? PW latest dev / php 5.6 fastcgi / Safari+Firefox Update: If I change the display order of those 2 fields in the template, both fields behave the opposite: So the first (whatever the first field is in the template when editing the page) always WORKS the second NOT. (The 2nd field lets me still adding or deleting a page - just the order is corrupt there.) Update: On localhost everything works (same php version but has opcache off in MAMP - maybe this info is important) Update: If I switch "autojoin" off for those page fields, everything works everywhere. This is my workaround for now. (I remember that "autojoin" has been a problem for me with page fields already in much earlier versions of PW on many sites so it is not a temporary phenomena.) ryancramerdesign commented If you need to retain a sort order, you'd only want to autojoin one of the page fields. Autojoin causes everything to be loaded in one query, and there can't be two different sorted result sets included in that query as far as I know. Though it's interesting it works on your localhost and not on the other server. There are some MySQL versions known to have issues with sorting and certain queries, and you may be hitting up against that on one server and not the other. Though I can definitely see how auto joining two Page fields in one query would pose challenges to retaining the sort order. So in either case, I would limit your autojoin to just one Page field, or simply not use Autojoin for page fields at all. There's not a major benefit in doing so. tbba commented MYSQL on the live server is 5.6 and on localhost/MAMP it is still 5.5. I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? (I must say this "mystery bug" - which sometimes happens and sometimes not - was quite a debugging nightmare and other users should be warned/hindered to set-up such a combination, i.m.h.o.) ryancramerdesign commented I am very glad you can confirm that this issue is not a phantom of a defect system and can be 100% nailed down to "Autojoin". Actually I can't nail it down to autojoin, but outside of using it with a simple text or number field, autojoin is an advanced option that can be affected by a lot of different factors. It's one of those things we suggest using when you find it helps, and don't use when you find it interferes. When you autojoin a multi-value field, MySQL is performing what's called a group_concat, and is at the mercy of certain MySQL memory buffers and configuration settings. It's very possible you are hitting up against that too, which is made all the more likely by auto joining two multi-value fields. That would explain why you see it on one server and not another. I used Autojoin under the assumption that it indexes a field and makes certain searches (menu building) quicker. (Since the new cache options, I am not worried with speed on certain searches any more.) It can make things quicker but it can also slow them down. It really depends on the case. The only way to tell for certain in a given instance is by testing and timing it. I do know for certain that auto-joining one or two text fields (like title and summary, for example) does provide a performance benefit to large navigation lists that use the autojoined fields, though not likely one that you would feel unless loading hundreds of thousands of pages. If Autojoin has, in the best case, no "major" effect with page fields and in the worst case totally confuses the system, why is the option nor switched off and deactivated for this field type? Because it is an advanced option that may be beneficial. If auto joining one multi-value field, like a small list of category page references, you may find it beneficial when outputting a 100 item navigation list. Or you may not. It really does come down to installation specific configuration, so it's one of those things you want to test when you use it to make sure it's working and worthwhile for your case. I wouldn't want to disable the option for this Fieldtype, because I think it can be worthwhile. But it's on the advanced tab for a reason. Is Autojoin only bad for page arrays or even if the page field is set to accept only one page? Are there other fields that also have a problem with "Autojoin"? Autojoin should be fine for Page fields, especially single page fields. What I would avoid is giving several multi-value Page fields autojoin on the same template. You are more likely to run into issues there, but again, the only way to know for certain if it's going to be an issue on your installation is to test it. If you need something guaranteed to be portable across systems, then limit autojoin use to single-value text fields and such. Any multi-value Fieldtype has potential to run into installation-specific limits that could cause issues, so always treat it as an advanced option and test.

Nice reading Rick, welcome to PW!

Thanks for sharing this Rick, I recognize so much of it. Welcome.

@rick: If any question should appear while you're (hopefully) do your projects in the next days just come back to the forum and ask - we're happy to help you here (And welcome to the ProcessWire family of course )

Ryan already has the module to edit config in backend since 2.5 in his repository. I'm working on a new multisite version but doubt it will be ready anytime soon.

You could limit the removal of get parameters to just the frontend by disabling the rule for everything in the admin-backend "folder". Disabling them in the backend is a very bad idea as lots of core and 3rd party modules use them.

I mentioned in the initial post I am working on a multi site install where I already have to create the url list in the module manually. That means every time I add a users website to my multisite, I have to manually add it 2 places. One using the cms and one hand editing the config file. It would be nice if I could add it manually only one time and make one read the other. Anytime you have 2 manual lists, it creates an opportunity for something to become out of sync. If I am going to update one time, I would prefer it to be via cms/database instead of file to edit as well.

You can change it, but wherever you do so it's most likely to late to be picked up by the internal check, that compares the actual httpHost to the whitelisted ones. The changes would only be available to everything running later. The only way to have it pick up for the internal check, too, is by editing the config file itself, which could be made automatically. Another option would be supplying no httpHosts all together and call the check manually after adding all the needed domains. But it's a question for Ryan to answer if this would actually be of use for the security. @Soma I can understand that need. If you'd build some kind of SaaS software, where the user should be able to add their domains, you wouldn't want to edit those manually.

Keep in mind that the maintenance mode and protected mode modules only limit access to the front-end of the site, not the admin panel, so won't work for your needs anyway.

Thank you, I didn't knew about this module. I just tried it out and it seems to work fine with my rendered output from the PageTable-Field.

i think you could make your config file get the content of the multisite hosts field

Bah! I mixed this with the other EMO module! This is what I've been using all the time, without any problems with render: https://github.com/BlowbackDesign/emo https://processwire.com/talk/topic/2916-email-obfuscation-emo/ Andreas: did you try it?

If you are happy with a quick hack, try this in your templates/admin.php file. if($user->isLoggedIn() && !$user->isSuperuser()) { echo 'Sorry, login is temporarily disabled'; return; }

the only one that also works on historical data and my recommendation: https://processwire.com/talk/topic/9739-google-analytics-referral-spam/?p=94480

I have brought this up with Ryan already, so hopefully it is on his radar. Perhaps an issue on Github would be a good reminder for him though. This was my message to him:

This hasn't been asked, but wanted to cover how the permissions and publish workflow work on the site. It has a very simple, though nice setup, where authors can submit new posts but can't edit already published posts, nor can they edit unpublished posts by other authors. It enables Mike to have full control over any content that gets published on the site, while still allowing easy submission and edits for the authors. Post workflow All of the authors have a role called "author" with page-edit permission. On the "post" template, the boxes for "edit" and "create" are checked for this "author" role. This site also makes use of the page-publish permission, which is an optional one in ProcessWire that you can add just by creating a new permission and naming it "page-publish". Once present, it modifies the behavior of the usual page-edit permission, so that one must also have page-publish in order to publish pages or edit already published pages. The "author" role does not have page-publish permission. As a result, authors on the site can submit posts but can't publish them. Nor can they edit already published posts. In this manner, Mike has final say on anything that gets posted to the site. Post ownership The default behavior in ProcessWire is that the Role settings control all access... meaning all users with role "author" would be able to do the same things, on the same pages. In this case, we don't want one author to be able to edit an unpublished/pending post created by another author. This was easily accomplished by adding a hook to /site/templates/admin.php: /** * Prevent users from being able to edit pages created by other users of the same role * * This basically enforces an 'owner' for pages * */ wire()->addHookAfter('Page::editable', function($event) { if(!$event->return) return; // already determined user has no access if(wire('user')->isSuperuser()) return; // superuser always allowed $page = $event->object; // if user that created the page is not the current user, don't give them access if($page->createdUser->id != wire('user')->id) $event->return = false; }); Planned workflow improvements Currently an author has to let Mike know "hey my article is ready to be published, can you take a look?". This is done by email, I'm assuming. An addition I'd like to make is to add a Page reference field called "publish_status" where the author can select from: DRAFT: This is a work in progress (default) PUBLISH: Ready for review and publishing CHANGE: Changes requested - see editor notes DELETE: Request deletion Beyond that, there is also an "editor_notes" text field that only appears in the admin. It's a place where Mike and the author can communicate, if necessary, about the publish status. This editor_notes field doesn't appear on the front-end of the site. All this can be done in ProcessWire just by creating a new field and adding these as selectable page references. That's easy enough, but I want to make it so that it notifies both Mike (the reviewer) and the author by email, every time there is a change in publish status or to the editor_notes. This will be done via another hook in the /site/templates/admin.php: wire()->addHookAfter('Page::saveReady', function($event) { // get the page about to be saved $page = $event->arguments(0); // if this isn't a post, don't continue if($page->template != 'post' || !$page->id) return; // if this post wasn't made by an "author" don't continue if(!$page->createdUser->hasRole('author')) return; $subject = ''; $message = ''; if($page->isChanged('publish_status') || $page->isChanged('editor_notes')) { // the publish status or editor notes have changed $subject = "CMSCritic post publish status"; $notes = $page->isChanged('editor_notes') ? "Notes: $page->editor_notes" : ""; $message = " Title: $page->title\n URL: $page->httpUrl\n Status: {$page->publish_status->title}\n $notes "; } else if($page->isChanged('status') && !$page->is(Page::statusUnpublished)) { // page was just published $subject = "CMSCritic post published"; $message = "The post $page->httpUrl has been published!"; } if($message) { $reviewer = wire('users')->get('mike'); $author = $page->createdUser; mail("$reviewer->email, $author->email", $subject, $message); $this->message("Email sent: $subject"); } }); Mike, if you are reading this, does this sound useful to you?

Greetings Everyone, Sorry I missed this discussion until now. Yes, I am working on a ProcessWire book and companion Web site. As a technical writer/developer/designer, ProcessWire has been an inspiration on multiple fronts: creating Web sites, going deeper with design/development, and writing/documenting the system. I've been working regularly on the book project, and I have about 175 pages completed already. I'll have much more to share in the coming weeks. Stay tuned, Matthew