Leaderboard

I had been looking for CMS alternatives for a few months, I had been doing work primarily on Wordpress but only with already made templates, later, for custom design needs, I discovered Perch which I was quite excited to see how well it worked and how easy it was to set up a site with it, but the license fee made it less attractive as it did impact my costs of production (I normally do small websites). But I did love this thing, simple websites, simple admin, just the right amount of things to edit, everything managed through Pages (though not in tree form). Though, I did had a hard time getting used to their weird way of configuring field types (which looked like you were making a template, so I got confused between templating and configuration now an then) I then went to Kirby, flat-file CMS, also a very neat CMS, though I didn't like much the admin panel, I did like that it was pure files, so my local version of sites were pushed really easily, galleries options weren't as neat as in Perch and had no comments system for blogs. Then again, the license fee kicked in. Start looking again... This is when I came up with Bolt, Pico, Grav CouchCMS, etc. But nope, nothing at least comparable to Perch in simplicity, (or some don't have admin panel) If I remember I think Bolt did call to my attention but when I tried it it had this "bloggy" feel to it, similar to Wordpress, that ended up not convincing me. Then I was making a website for a friend's to be released comic book and I wanted to mimic what is done on manga sites, volume, chapter and page navigation dropdowns and stuff, then again same old story, look for a Wordpress plugin, found out that the best option wasn't exactly what I had expected and then again, doing Wordpress themes always looked like such a pain, so I that didn't even bother. Started looking again...even found a dedicated CMS for comics, that didn't really fit my needs. In this now long search for a perfect CMS, I stumbled upon CMS Critic while looking for reviews website, and saw they had an award thing going on, so I decided to check top places. "Well well, who do we have here Mr.Processwho-No-1-OpenSource-CMS?". Started reading the docs, saw the examples, looked awesome, so I decided to put it inside a website. Clean urls, everything custom fields, repeaters, multilanguage out of the box, extendable, a kick ass API....YOU HAVE TO BE KIDDING ME! The rest is history my friends, Processwire has brought the happiness to my web development career as nothing had ever done. I believe in this project and it's community, it's gonna be awesome, nuff said!

FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/ GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup As of 11 May 2019 ProcessWire versions earlier than 3.x are not supported This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin). The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen. The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages. The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan! Warning/Consideration Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API Backend Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer. FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. A very simple example. return 'Hello'; Simple example. return $page->title; Simple example with markup. return '<h2>' . $page->title . '</h2>'; Another simple example with markup. $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example. $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example. $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do: return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows: return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup') Access the field on the current page (just like any other field) echo $page->runtime_markup; Access the field on another page echo $pages->get('/about-us/')->runtime_markup; Screenshots Backend Frontend

Zero setup page rendering with caching, with simple replacements. Useful if you have complicated templates (or a large number of less complicated ones), where you often need to do a small number of adjustments. In this case, caching on the template level doesn't completely make sense — because it either uses cache, or doesn't. This module solves this problem by using markup cache all the time, but allowing us to modify the output by replacement of simple strings. - On GitHub - On modules.processwire.com Edit: Also, small thanks to Tom Reno for testing what single language install return for $user->language

Hi everybody, the fist time I heard about PW, it was by following a simple link on a blog, and it could probably change quite many things with my next client projects. As I started doing web design and dev' somewhere around 1994, I walked through some CMS's and PHP frameworks along the way. My last CMS of choice is (and almost was) ExpressionEngine but since the first versions of EE2 there's noting new or better, just more expensive 3rd party modules adding up to the license and more. Actually, i'm considering migrating two EE websites to PW, and starting a fresh install for a client project I'm actually working on. For later, on, once I'll dig more into the source, I'll test some UX ideas locally for the Admin part to see. Oh, yep, indeed I'm Andrei, web dev/design/market'er based in southern France, and glad to be here

Servus mr-fan, thanks for the hints. I now built the inputfield pretty much like described above. I duplicated PageListSelectMultiple for site A and changed the code so it loads JSONP data from site B. On site B I have a simple API that returns data suitable for ProcessPageList. Needs more testing but seems to work so far. Thanks, thomas

Yes, this specifically what I'm talking about and it depends on use-case. If you're developing, say, a site that allows users to list items for sale, it seems to me that it makes the most sense to create a custom admin section for the user as part of the frontend. That way it's easier to mimic styling and it's a lot easier, it seems, to use the api to create all that's necessary for that type of user to edit and maintain individual settings without dropping them into the PW backend. I wasn't clear with my Wordpress remarks so I'll go at it from another angle: the development of the WP REST API has excited developers for many reasons, among them being the ability to code custom backends for users that don't require interaction with the standard WP dashboard especially for reasons of styling consistency and unecessary complexity. Much easier to do a custom admin using the new api. Of course PW already has a great api and I'd suggest that any site that is allowing users to create accounts and user-specific content (such as ads, personals, subscriptions, products, forum posts, etc.) a custom backend with identical styling to the frontend is the way to go. The admins and developers can use the PW backend for site management.

I heard first time from Mar also as MadeMyDay here in the Forum. He was some kind of mentor for me for MODx. Even though I was sometimes annoying, he always had an answer via Twitter or Forum So i worked one or two years with MODx. After I noticed that he is on a new CMS called processwire i had start to read about it. It took some time to understand this. But now Im in love with PW

I suspect there are two types of backend development perspectives: modifying the appearance and functionality of the PW interface itself (aka admin themes), or creating highly-customised listing/editing/configuration pages. I've always regarded the existing PW backend as the place for superusers/developers only. A separate backend should be developed for users/editors/authors who wish to edit their own content and adjust basic settings related to how they interact with the frontend. This as opposed to something like Wordpress where the backend is usually quite suitable for all types of users from mere subscribers all the way up to admins. I mean, let's say you use PW to build a site where users can edit their own content. It seems much cleaner to provide a custom edit area, themed identically to the frontend, than to drop users into the PW backend even though you've hidden all the stuff the user doesn't have permissions for. That being the case, backend devlopment is nothing more than an extension of frontend development with robust auth/permission checks. I'd like to see tutorials on the pitfalls and best practices of that type of narrow, highly-customised admin area. Further, I concede there's a crossover between user-centric admin areas and a fully-exposed backend. I may be at cross purposes with the OP.

In PhpStorm you can get autocompletion and typehinting for wire function calls if you add a file with the following content somewhere to your project. Jetbrains suggests naming this file '.phpstorm.meta.php' and adding it to the root of your project, but it should work anywhere else too. I had to re-open the project after adding the file. <?php /** * ProcessWire PhpStorm Meta * * This file is not a CODE, it makes no sense and won't run or validate * Its AST serves PhpStorm IDE as DATA source to make advanced type inference decisions. * * @see https://confluence.jetbrains.com/display/PhpStorm/PhpStorm+Advanced+Metadata */ namespace PHPSTORM_META { $STATIC_METHOD_TYPES = [ \wire('') => [ '' == '@', 'config' instanceof Config, 'wire' instanceof ProcessWire, 'log' instanceof WireLog, 'notices' instanceof Notices, 'sanitizer' instanceof \Sanitizer, 'database' instanceof \WireDatabasePDO, 'db' instanceof \DatabaseMysqli, 'cache' instanceof \MarkupCache, 'modules' instanceof \Modules, 'procache' instanceof \ProCache, 'fieldtypes' instanceof \Fieldtypes, 'fields' instanceof \Fields, 'fieldgroups' instanceof \Fieldgroups, 'templates' instanceof \Templates, 'pages' instanceof \Pages, 'permissions' instanceof \ Permissions, 'roles' instanceof \Roles, 'users' instanceof \Users, 'user' instanceof \User, 'session' instanceof \Session, 'input' instanceof \WireInput, 'languages' instanceof \Languages, 'page' instanceof \Page, ] ]; }

Not sure if I would. Depending on how the site would be built I would probably use your solution and create the views for those. Probably with a listing of all the interests and a sublist of all the places in each interest, but then, maybe it makes more sense interests inside places and not the opposite. It really depends on the content.

I think it can be much simpler: Turn on url segments for interests, and link to /interests/interest1/PLACE/, where PLACE is the first url segment. //poi.php $url = "/interests/interest/{$page->parent->parent->id}/"; //interest.php if ($input->urlSegment1){ //validate that the url segment isn't bullshit $place = $pages->get((int)$input->urlSegment1); if (!$place->id || $place->template != 'place') { $session->redirect( … ); } $pois = $place->find('template=poi, interest={$page->id}'); // here you go. // alternatively, if you want to fiter out the 'sender', // add it as second url segment (and after check&validation), use: $pois = $place->find("template=poi, interest={$page->id}, id!={$poi_from_segment_id}"); }

@elabx, not possible. We are in one of the interests pages at this point. -- You have only two ways of passing info to the future page when pressing a url: the url itself or session. With session there is no way to create a permanent shareable page, so i would go for the url. you can do this with url segments or using a get in the url referring to the place. -- I would simulate with url segments that interests is at the same level of the tree as (do, see, etc) and link to there instead, leaving the interests pages without a template file. You could do it like this: <?php foreach ($page->interests as $i) { $place = $page->closest("template=place"); //or whatever works $url = $place->url . "/interest_" . $i->name echo "<li><a href='{$url}'>{$i->title}</a></li>"; } ?> On the template from the places pages you would have something like (rough draft): if ($input->urlSegment1) { if (!substr($input->urlSegment1,0,9) == "interest_" ) throw new Wire404Exception(); $reduced = str_replace("interest_", "", $input->urlSegment); $sanitized = $sanitizer->name($reduced); $int = $pages->get("name=$sanitized"); $pois = $pages->find("template=poi, interests=$int"); $content .= renderNav($pois); } Edit: And welcome to PW! Edit2: corrected typo

See here: https://processwire.com/talk/topic/648-storing-module-config-using-api/?p=5241

this new module could maybe do the job in most cases: https://processwire.com/talk/topic/10804-module-runtimemarkup-fieldtype-inputfield/

The answer is actually in the error message. Your assets directory seems to be locked down for writing. Does that happen only with Modules Manager or throughout your site? If the former, you might want to ask your question in Modules Manager support forum. There was a similar issue a while back. If the latter, have a read at this as well: https://processwire.com/docs/security/file-permissions/

I'm not sure where you see that WP is so much different than PW from the user perspective, except maybe the initial Dashboard. It's neither themed like the frontend nor can it provide more or less than what's possible in pw and people seem to love it. The posts / site listings can be mimiced by listers, the plugin and settings area shouldn't be visible to less-permissioned users anyway (our fields/templates). The Design area is simply a page somewhere in the pagetree (there are various ways to get this special page in the navigation). I'm not sure about comments, as I don't use them, but I doubt them being handled overly different. Users are already shown in a lister. There's a page to edit the own profile. Additionally you can really limit your users down to the bare minimum they need to see. Hide pages, they don't need to edit, or even hide the whole pagetree and let them only use listers. There's a lot you can do there. And if some feature is really not present (dashboard) you can still look in the modules directory or code an own process module to resemble your needs. By now I did lot's those custom process modules and it's really not that hard to integrate own layouts / views into the backend with the cohesive styling it's providing. If you find that users cannot grasp what their changes in the backend do in the frontend there are various examples where people integrated the fredi module or links to the backend. So people can decide in the frontend what they want to edit and from there go directly to edit it in the backend interface. When talking about "casual" users, who can edit their own content, but shouldn't know about a backend – that's 100% frontend – at least in my opinion. It's part of the service you offer the user. This can look like a "backend" but you're really better of not trying to integrate that in any way with the real pw backend. Just code it like any other frontend-part and use the api. Think about when the code of the backend would change a bit. Suddenly your users cannot edit their content anymore. That's not what you want.

Now that I know what this is about, I'd like to mention use this: https://imageoptim.com/ And googling for what SuperPNG does, I found this which seems to be from the same author as ImageOptim, though I don't really know if it does the same: http://pngmini.com/

@pwired. You can find out about these things, when looking into the wire/core (and wire/modules/) folders. These classes are just things the core itself uses and are not providing an "api" like $page or $pages. About the length of the snippet: Even raw php wouldn't need that much more lines to read from an mysql table.

Update: For the curious minds, the site is published at: http://www.ecocarb.com.br/ ( but only pt-br version for now) --- I'm creating a small project for a company owned by a cousin of mine and I'm using it to try new things, most on the front-end side but I decided to try jade with php. What I'm using: gulp to run all tasks – compile all sass and jade files and copy processwire files to the public folder bourbon + neat – nice mixins and grid system with a small footprint (project total css if less than 8kb - gzipped) jade + jade-php – I'm loving jade and with the jade-php npm package I can run ProcessWire code just fine. It's not the perfect world, sometimes I have to mix <?php ?> tags but I'm fine with it for such small project. Here's my basic-page.jade file: The rendered html: And here's the homepage so far (please ignore the translation, it is not done yet): And homepage's code: extends _main block header link(rel='stylesheet', href!='<?php echo $config->urls->templates?>css/home.css') block main-content include partials/_hero.jade .cta section h6 - echo __('O que dizem nossos clientes') include partials/_comments.jade a.button(href!="<?php echo $pages->get('/contact/')->url ?>") - echo __('Teste grátis por 30 dias') br small - echo __('Agende uma apresentação') section.desc h2 - echo $page->summary .services .line-behind-text h6.section-title - $services = $pages->get('/services/')->get("headline|title") - echo $services include partials/_cards.jade

$myDB = new Database('localhost', 'username', 'password', 'db_name', 3306); $result = $myDB->query("SELECT * FROM my_table"); while($row = $result->fetch_assoc()) { $p = new Page(); $p->template = "dam"; $p->parent = "something"; $p->title = $row['title']; $p->save(); }

Best information is given from the author himself in his blogpost

You can use GET vars to do so: <?php // URL: www.domain.com/tags/?tags=events,films,outdoor // // Alt. URL with different template than tags overview: // www.domain.com/tags/multiple/?tags=events,films,outdoor $tags = $sanitizer->selectorValue($input->get->tags); $taggedPages = $pages->find("…, tags=$tags");

Just an idea...but maybe you can adapt this module to your needs and grad the select data from a different db: https://processwire.com/talk/topic/9320-fieldtype-select-external-option/ or you use on site B a kind of webservice page that output json with id|title|url and use this in site A? http://modules.processwire.com/modules/service-pages/ just some notes on this issue... regard mr-fan

It's funny to see you quote my request for such an tutorial and now I'm very much feeling able to answer your questions here. Currently the best resource for handling all those mentioned things is really ProcessWire itself. If you want to know how to handle a custom CI Design in the backend - take a look at AdminThemeReno - it was born out of a custom backend interface and then ported over to pw. Maybe the new custom colorschema feature of Reno does fit your needs, but otherwise just clone one of those admin themes to site/modules/ and tinker away. About custom interfaces: All the Process* modules represent (full) interface-pages in the backend, and lot of the 3rd party modules are injecting things into those pages. Just take a look at those an see how they handle things. Maybe the most interesting Process module is ProcessPageEdit, as it is maybe the most used one. For module that inject things I'd say BatchChildEditor is a quite sophisticated one. After a little playing around with those files and creating own ones, you'll see that even the backend consists of only a few concepts: the Process/Module Interfaces, the Form api, the Inputfield / Fieldtype interfaces and Wire / WireArray classes. The other core classes should only be from interest if you really need them.

Also keep in mind, that even the page-editing page in the backend isn't "$page->template == 'pricelist'". It's a hidden page of the admin template with the process PageEdit and it just shows the specific page values / edit form. Not all of them. Users for example aren't, but you can only access the process pages.

I think all pages in admin have template=admin.

I was actually thinking of converting all feature request/enhancement issues to something in the PW website (powered by PW pages). Something like the sites directory, with the ability to "like" requests, so that the most requested ones could rise to the top and get more focus. This would also get them out of GitHub, so the focus there can be on issue reports. Though I think it's good to still submit feature requests at GitHub, but I would just move them to the more dedicated system and close them out there once that's done.

I'm having the same issue. This is my function (which is sit on another php file )to print archive post, similar as the wordpress archive widget <?php function archive () { $out = " <h3>Archive</h3> "; $start = new DateTime('2010-01-01'); //$start->modify('first day of this month'); $end = new DateTime('2015-02-01'); //$end->modify('first day of next month'); $interval = DateInterval::createFromDateString('1 month'); $period = new DatePeriod($start, $interval, $end); $a = array(); foreach ($period as $dt) { array_push($a, $dt); } $a = array_reverse($a); foreach ($a as $dt) { $d = $dt->format("Y-m-d"); $nextmonth = date('Y-m-d', strtotime('+1 month', strtotime($d))); $count = count($pages->find("template=post, post_date>=$d, post_date<$nextmonth")); if ($count > 0) { $out .= "<a href='{$pages->get('template=home')->url}" . date('Y', strtotime($d)) . "/" . date('m', strtotime($d)) . "'>" . date('M Y', strtotime($d)) . " (" . $count . ")" . "</a><br/>"; } } return $out; } In a template file, the code will looks <? include('./archive.php'); $out = "This is content."; $sidebar = archive(); $page->body .= $out; include('./main.php'); // the master output file I will get this error in the log Error: Call to a member function find() on a non-object (line 26 of /var/www/html/pw1/site/templates/archive.php)

In a nutshell, I moved away from other systems and started using Bolt, due to its custom content-type-driven system. There are some features that Bolt lacks, some of which are not planned to be implemented as yet. Specifically I was interested in a hierarchy set-up, with content-types. That's when I stumbled into ProcessWire (not for the first time, I might add - I had seen it before, but the styling turned me off for some reason). When I did, I saw a new website, and an amazing admin-theme, which won me over pretty darn quickly. My first site in PW is for a Cameroon-based company, called AEG & Partners. For my first attempt, I'm quite proud. It was really easy to put together, and very straight-forward when it come to building custom modules. Glad to say that, at this point, I won't be looking back. Edit: Oh, and Ryan, I did pop an email through with regards to the showcase link - it doesn't have a thumbnail... Was my image incorrectly sized?

Bumping this thread since there are many new people since the last post.

Sorry couldn't resist ;D