Leaderboard

Greetings Everyone, Christophe: I would not worry about those "best of..." sites. Right now, the PHP community is nutty for Laravel. I like Laravel generally. However -- and I don't say this lightly -- most assessments I've seen are biased and a little rigged to help Laravel these days. For example, in that Sitepoint survey, versions 1 - 5 of Laravel are lumped into a single "popularity" number. But Yii framework (which is great, by the way), is split between version 1 and 2. We often have these discussions about increasing PW's popularity. But I wonder, maybe ProcessWire is doing well enough without pushing it? Thanks, Matthew

Since there are a lot of topics about the same theme, I decided to write a small module which overwrites the core function ___SetupPageName(). The module allows now to populate the page name using proprietary date() function. Works like PHP date() with follwing exceptions: Everything between the brackets is detected as format string, meaning no 2nd parameter possible. No need to use quotes around the format string. Spaces not allowed. from any page property, page field including subfields, parent property, parent field etc. Meaning everything what you get with $page->get(); including dot syntax. The function will give error and warnings in case of unproper settings, but creates the page with name 'untitled' anyway. Download here: http://modules.processwire.com/modules/process-setup-page-name/ Some Examples The following settings in parent template 'Name Format Children' will assign name immediately. date(Y) date('Y-m-d') parent.title parent.parent.title parent.id template.id assign name after page saving and/or population of depending field. Overwrites 'untitled' after all fields which are defined in parent template are populated. id (any other page property) pagefieldname, multiple pagefieldnames show a warning. pagefieldname (value not populated)show an error. date() // empty, no format assigned date(Y // missing closing bracket date(Y md) // unallowed space notexistingfieldname notexistingproperty existingfield.notexistingsubfield The function in the module ___SetupPageName() could be completely copied as is to the core class $pages. @Ryan Would be nice to see this in core. Related topics: https://processwire.com/talk/topic/8576-name-format-children/ https://processwire.com/talk/topic/8217-name-format-for-children-based-on-any-field-not-just-title/ https://processwire.com/talk/topic/11628-custom-page-name/ https://processwire.com/talk/topic/11349-page-add-step-not-being-skipped-when-name-format-for-children-is-set/ https://processwire.com/talk/topic/10701-automatic-page-name-using-processpageaddexecute-and-pagetable/ https://processwire.com/talk/topic/10208-pagetable-automatic-page-name-format-when-multiple-templates-allowed/ https://processwire.com/talk/topic/9979-name-format-for-children-for-multiple-allowed-templates-for-children/ https://processwire.com/api/modules/process-template/ Any recommandations after testing welcome. Download here: Download here: http://modules.processwire.com/modules/process-setup-page-name/ Edit: small enhancement to prevent display of warning twice. 23.12.15 multiple values possible now 24.12.15 made compatible with PW 3.x 27.12.15 Update Version 1.0.8 09.01.16 Update Version 1.1.0

Thanks, Martijn! I had a personal conversation with Adrian about this module. There are reasons that it is not in the module directory yet. They are discussed here: https://github.com/ryancramerdesign/ProcessWire/issues/302 and later in that thread https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/page-2#entry84916 I think core admin-view permission support on a page basic is something we can benefit from customizing admin interfaces for editors. That's why I was so interested to find out about the mechanism used for hiding 404 page revealed to me by LostKobrakai.

It's now on Github: https://github.com/horst-n/AdminLinksInFrontend After aproval in the modules directory, I will update the post here. Please, re-read the first post. It is updated with the release announcement and a more detailed explanation of all features.

I believe this as well and here's how I came to the same conclusion... I recently read this post by the original creator of Drupal and the fantastic comments there: http://buytaert.net/should-we-decouple-drupal-with-a-client-side-framework ... and that gets you thinking deeply about the evolution of content management systems and what their role is in the coming years. If you believe their role is ultimately some sort of structured content storage database that's decoupled from the frontend, or entirely headless, then platforms that like already exist. They are called Content as a Service systems, like Contentful: https://www.contentful.com/ More about CaaS: http://ecmarchitect.com/archives/2014/10/27/3944 Contentful is "an API-first CMS" and is entirely headless. It exposes the content as an API. You can then build your frontend separately in any way that you like. A very interesting approach is outlined here, using the Roots static site generator: http://carrot.is/coding/static_cms The thing about Contentful is that the concept and simplicity of fields, templates (known as "Content Types" in Contentful) and pages (known as "Entries" in Contentful) is almost exactly like ProcessWire. If you compare the two, you soon realize that ProcessWire is much more robust and feature rich... more field types, ability to nest pages, finer level of control, a User system, not forced into Markdown for rich text fields, ability to create modules, Hannacode/shortcodes and so on. Contentful is great too, but I feel it has a more precise use case. With that being said, the way I see ProcessWire is that it can be a CaaS-like/headless CMS much like Contentful, but also a "traditional" CMS like Drupal/WordPress but with way better architecture. Best of both worlds. I love my CMS too.

Try it out and let the error message tell you

I need to rewrite that post because there are many improvements and simplifications in that process. My ultimate goal is to create a site profile (maybe a multilanguage one) with Latte.

One thing I'm going to be working on soon is adapting Trellis to ProcessWire. If any of you saw my video on adapting Sage for ProcessWire, Trellis is a project by the same group of people (Roots) which allows for you to setup an excellent development + staging + production environment using Ansible (and Vagrant for the development environment). Because of the similarities between WordPress and ProcessWire (well, in terms of the server stack required and the fact that they are both CMSes), a lot can be borrowed from their setup in terms of approach and techniques. They use WP-CLI for some things, but Wireshell can be swapped out for that nicely from what I've researched. I'm really excited to see how it turns out because this has been a huge missing piece to my workflow. This approach would replace things like Capistrano and any other deployment methods, assuming you use a dedicated VM for a site. I highly recommend checking out Trellis to see how it's done. It's thought out very well.

When you call image and if image exist not trying to create it again just bringing existing image data.

ALIF - Admin Links In Frontend EDIT: latest version update with PHP 8 fixes on 05. Nov 2023 (!) The version now is 1.1.9 (!) This module combines some of the admin links that we want to use on the frontpages sometimes. It is a comfortable and easy way to do so. After you have installed and configured the module, you can inject the links into the frontpage with code like this in a template file: echo $modules->isInstalled('AdminLinksInFrontend') ? $modules->get('AdminLinksInFrontend')->render() : ''; . Credits: The comfortable Javascript Color Picker in the Configpage comes from Jan Odvarko (http://jscolor.com). Many thanks for this! * Toolbar The toolbar can be positioned by css values for top/bottom and left/right. It can expand in vertical or horizontal direction. The buttons are links to the PW admin, for logout, or for editing the page in admin, or informational ones. All settings, including the colors, can be defined in the modules config page. This is available for all PW versions from PW 2.3 up to now. Depending on how you configure this part, it can be used for authors and editors too, maybe. * Import / Export Settings It has the possibility to export and import its settings via two textarea fields. When importing settings, you get a second screen where you can select which settings you want to import. * One-click User Account Switcher For PW versions 2.6.8+, there is one really nice function available, that I use when developing / testing sites with different user / roles. A fast User-Account-Switcher that lets you view the same page from different user accounts with only one click. To enter this mode, you need to login as a superuser one time, and the feature needs to be enabled in the module of course. After that, you can log out, login with different user roles, etc. At least the toolbar buttons for the User-Account-Switcher will stay visible for you. This is session based. There is also an extra button with a trash can and the text "Session", that helps you to leave this mode once you are finished. As you can see in the screenshot, after clicking "guest", I was logged out, but a regular login button, a warning for debug mode and my three defined buttons for user accounts are available. When clicking another user button I login with this account. Very handy. ATTENTION! The use of the One-click User Account Switcher is mainly intended for dev sites, not for public sites! You should be aware that there is a huge security risc when using this feature on public reachable sites! We completly leave ProcessWires comfort zone in regard of security, - and the only thing between your site and potentially hackattacks is this module. (Oh mom, - what have I done?) PW 2.6.8+ has a comfortable function for admin tasks, that let us log into different user accounts via API without using passwords. This module uses this function! All data that is needed during a User Account Switcher session is stored in the session data on the server. So, if someone steel your session cookie, there is potentially risc that he can login as a superuser, depending of the user account buttons you have in your admin links collection! To prevent SessionHijacking, the module can be bound to a single IP address, it uses a fingerprint depending of IP(s) and UserAgent string. And you need to define a max time to live in minutes between 2 and 60, a User Account Switcher session may run. A User Account Switcher session only can be initialized by a Superuser who also explicitly has set a permission called 'alif-user-account-switcher', what is defined by the module, when installing it. So, the prefered way to use this module is, to enable and use the User Account Switcher while the site is unpublic, and before it goes public, remove the permission from the superuser role. This way, you can use its menu function, but not the UAS anymore. On a sidenote, for those rare cases where multiple superusers simultaneous developing on a site and want to use the ALIF, but the UAS should be used only by one, you can leave the 'alif-user-account-switcher' permission removed from the superuser role, but need to assign the role 'alif-superuser' to the single user account. This way, only that single superuser has the permission for UAS, whereas all other superusers doesn't have it. . . * The Configpage * Online demo I have pasted it into this old site and enabled it to be present every time (when the site is in demo mode only!). So, it is an earlier state, but the switcher is functional there: http://pwlaf.biriba.de/dbinfo/ * Download From our modules directory or from github repo

I love the new frontend page editor function in PW 3.0.2. and Star Wars. I'am making a simple site and want the user to login and only see the homepage. He can edit the homepage and that's it. I mean that the user does not see the back-end at all. The first solution is that a user directly get redirected to the home after login. Maybe somebody have a better solution?

i'm using the updated timepicker and it works fine so far - you would want to duplicate the inputfield (datetime) into your site directory and then tell PW to use that one; from there you can make your changes... (like to the CSS file) you may also need to add something like this to your admin custom files (ProcessPageEdit.js) if(typeof $.timepicker != 'undefined') { $(function(){ $.timepicker.custom = { stepMinute: 15, controlType: 'select', oneLine: true, }; $.timepicker.setDefaults($.timepicker.custom); }); } word is that the next version of PW will have the updated timepicker addon

thanks man!!! you save my day in office!!

I've always used a PHP file that resides outside of PW and included an include to the index.php page, but if you are working within PW, you probably don't need to include this at the top of your template: include("/home/path/to/public_html/index.php");

Surveys, polls, statistics... we know people can make them say what they want. Yes, there is no need to rush things. ProcessWire's growth is natural.

Thanks for the feedback Adrian. I've had some mixed results with the Migrator. It worked for some of our content but it didn't seem to work for Blog Articles i was trying to export. But I've realised the Blog are complex objects that have a lot of dependencies and I may have not specified them correctly. The Blog articles i'm using are part of the ProcessBlog module. All in all it's been positive overall and I think it's probably best for me to stick to simple pages or objects when it comes to the Migrator. I look forward to the bug fixes and I hope it gets the love and attention it deserves.

@kixe: Why did this module not make it to the module directory?

Go here: https://processwire.com/talk/topic/8576-name-format-children/?p=108748

@Ivan, Take a look at https://processwire.com/talk/topic/1176-hiding-uneditable-pages-from-users/?p=84916 to hide pages. (See settings Tab of the page)

I had the same issue when upgrading to current devns. Landed up doing a manual upgrade, which worked (as expected).

The 404 page is declared as system page in the constructor here https://github.com/ryancramerdesign/ProcessWire/blob/master/wire/modules/Process/ProcessPageList/ProcessPageListRenderJSON.php so there's probably no way currently to extend this exact behaviour besides editing the file itself. But you could hook Page::viewable and try to just disable the view access for that pages if the current process is ProcessPageList.

Labels are field-specific, i.e. generally they apply everywhere the field is used. Values on the other hand are always page-specific, i.e. each page has a separate value for each field. This is why you should be asking for the value of this field from a specific page. For current page you can use $page, and for other pages you can, for an example, do this: $pages->get('/page/url/'). <?php echo $page->caracteristicas_superficie; ?> <?php echo $pages->get('/page/url/')->caracteristicas_superficie; ?>Or: <?php echo $page->get('caracteristicas_superficie'); ?> <?php echo $pages->get('/page/url/')->get('caracteristicas_superficie'); ?>I would suggest taking a proper look at https://processwire.com/api/ before stumbling any further. The basic stuff is all explained there

How to name the adaptation? I guess "Trollish" is out of the question

I just attended one of the free A List Apart live-events and was quite amazed. The big topics that were discussed were how to chose a cms, evaluating not only the frontend, but also the author/backend user experience and workflow needs and finally the current interest in decoupled cm-systems. The great thing was, that on all of those topics I was constantly thinking how nice it is to handle these things in PW. Some may include more work than others, but in the end it's really avoiding lots of those mentioned difficulties / roadblocks with cmss. So my conclusion is really "I love my CMS" . For the curious I've included the link to the event page, where the hangout/transscript will be posted later and the hangout link, so you can watch it as long as the event page isn't updated. Maybe someone did even watch it live as well. http://alistapart.com/event/content-management https://plus.google.com/events/clcdcbjo5puojn47aprk5plkem0?authkey=CMP6kImisby_tgE

Jonathan: you should write an article about your observation.

Glad I helped. I meant the most common way of writing loops in PHP. Using this same example: <?php foreach($page->children as $child) { foreach($child->images as $image) { echo $image->url; } } The for you used is common for when you are mixing PHP and HTML. Like this: <?php foreach($page->children as $child): ?> <article> <h2>Images from page: <?=$child->title?></h2> <div class="images"> <?php foreach($child->images as $image): ?> <img src="<?=$image->url?>" /> <?php endforeach ?> </div> </article> <?php endforeach ?>

@FrancisChung - I am going to be offline for about a month, but please let me know how Migrator works out for you. I use it a lot in my development process for migrating new branches of content from dev to live, but I do know that there are still some issues that need to be sorted out. As I mentioned in the Migrator support thread, it's definitely not abandoned, I just need to find a good chunk of time to address some bugs. I would definitely recommend testing the migration from one dev site to another dev site first and if that goes as expected it should be safe to migrate to a live site. Also be sure to use the the inbuilt backup option just in case. Hopefully sometime in the new year this module will get some more love.

Try: <?php foreach($page->children as $child): foreach($child->images as $image): echo $image->url; endforeach; endforeach; ?> I kept the code similar to what you had so you understand the differences, but way of writing PHP is more suitable if you want to alternate PHP and direct HTML. For a simple echo it's better to just use brackets. I'm actually surprised that you don't get a PHP error with that code

Hey Ben, that's brilliant news! Finally, someone who knows about ProcessWire writing about ProcessWire . Could you please start a new thread about this? It is an important issue and should not 'be hidden' here amongst other stuff, thanks.

I´m currently translating to 2.7 https://github.com/NinjasCL/Processwire-Spanish based on this one https://github.com/LuisSantiago/Processwire-Spanish

I´m a happy customer of padloper thanks for all your work apeisa

Module updated Module and InterventionImage Library update

It's been more than 9 months since I wrote in this thread about our intranet. Well, things happened that had me away for a good while, and when I got back to it, the wishlist exploded. Finally, though, the migrated intranet is up and running, and based on the feedback I'm getting, I can already call it a success. Here's a short feature list: Running on Windows Server 2012R2 / IIS 8.5 A little over 8000 pages, two languages, 600+ frontend users in 15 countries, 45 editors About 20 templates 15 custom modules Reduced custom CRM module code to less than one-eighth (counted in bytes, not lines) Integrated web server authentication and detailed Group permissions using Apeisa's UserGroups module (big thanks there! Keeping our group-based permissions was one of the main requirements for the new CMS) Live user + groups synchronization from Active Directory Granular search via OpenSearchServer (including permissions handling and indexing linked PageFiles) Tag based in-text translation system through custom Textformatter module linked to our ERP database, with own CKEdtior plugin (think detailed technical data sheets where you don't want to edit every language version separately) About 400 dynamic pages that range from simple database-driven lists to rich single page apps Persistent page links using page IDs that get replaced on save + render Versioning for textareas Custom links in the style of "article:CUSTOM_UNIQUE_FIELD" used to fetch recurring content into pages in our in-house manuals Booking system for our inhouse training center using just pages, standard fields and a bit (well, a good bit) of frontend-editing glue, with graphical interactive calendar Pages can be published per language through a multilanguage checkbox, with corresponding indicator icons and actions in ProcessPageList Notice board system (title, short body, optional attachment, expiry date) for main and department pages, with frontend adding/editing and admin interface Detailed permissions reports in backend and through command line for compliance audits Not yet implemented, but a working prototype is already on the test system: a simple question/linear response forum system with rating, tagging, answer accepting and highlighting options, primarily targeted towards international knowledge exchange Big thanks to Ryan, PW is really an outstanding system in terms of flexibility, scaling and ease of integration, and also to everyone who contributed in any way to PW itself or its huge module repository. As a funny side node, I talked to a colleague from manufacturing when migration was still under way, and he was initially a bit miffed that I'd swap the system he already knows (hey, it's only been 7 1/2 years!) - but only until I told him I'd use PW. At the mention of the word "Process" he immediately determined that his workflow to add content would get a lot smoother, something I could confirm without thinking. (The old system had a separation between categories and articles, so you had to create both in different backend screens to get a navigation entry for a simple page that shows just some text - in PW he only needs to tick the "Show in Navigation" checkbox for his new page.) Shows that the right naming choice already gets you halfway to the goal Now that "The Big Project" is done, I'll only have to weather the usual end-of-year-craziness, then I'll get my custom modules into a shape where I can share them (meaning: polish documentation, add reasonable defaults and switch to module config fields instead of config files).

A vm workflow is really nice especially cross platform. If you take a look at vagrant I'd suggest trying out ansible as provisioner. It's a damn nice and modular system, which can be used on almost any system you've ssh or console access.

vagrant (+ virtualbox) + git is pretty encapsulated vagrant streamlines the process of generating virtual machines to develop on, by providing 'prepackaged' virtual images + options to include other provisioning software (like puppet, chef, etc.). Some use Vagrant VMs as 'apps', meaning that each project has its own virtual machine, some other people have one VM for multiple sites (a la *AMP software). In your case, you could have your site versioned in git, together with your mysql dump and Vagrantfile (vagrant 'recipe' for your vm), and when you come to new machine, you'd do something like 'git clone project && cd project && vagrant up', go have a coffee, come back and start working. (of course, it's never quite that simple IRL , but in gist vagrant is quite nice. I am in the process of setting up local vagrant from clean ubuntu + serverpilot.io over vpn. fun times)

processwire is love processwire is life

We're lightyears ahead.

I hadn't heard about the concept of "headless" CMS, though I believe it is kind of the way PW is built right? Like, everything modules around the core? Also the examples they give about distributed technologies as management systems reminded me of a topic around General Support of someone making an API for a mobile app. My favorite part of Processwire is this feeling that I know "a way" of accessing data and just present it however I want to. Not having to look into the documentation every time to see which specific function I need to call and the default admin that makes so easy to show just enough for the right user. I love this CMS too

I like fish... Can you cook Ryan?

Actually I was talking about the second and only due to the enforceable legal environment in the EU. I believe that there's never a need to be paranoid about anything, people just need to be aware of any technology and it's use or possible misuse. I find it amusing that many people think that intrusive behavior, like what you mentioned, comes from only over here. You mentioned one agency, yet It's a big world out there and there are many bad actors doing many bad things. We, as humans, tend to focus on where the spotlight is directed, failing to critically think about what the bad actors in our own neighborhood are actually doing. It would benefit everyone to realize that America is not the only place that has the talent, the resources, a desire and a will to get information they want at all costs. I only talked about European hosts as a better choice because its been proven that existing European laws and ethical behaviors are geared more towards privacy. The fact is that US based hosting can be cheaper, however you have to live with the legal rules that they operate under. That's an important and big difference. Whenever you're making a decision about something like hosting, you need to be aware of and be smart about many things. Having all of the details and not just a few facts, results in you making a better decision. I believe that whether you host with a US provider or someone under EU regulations is an important decision to make (if you live in Europe). Here in the US, we're stuck. I mentioned the subject mainly because you are somewhere where you actually have a choice to make regarding privacy. So, once again there's no reason to be hiding or fearing anything. Everything else about that agency and those discussions aren't even worth talking about, especially on this forum. Latency has always been an issue based on where you're at, the capabilities of your physical hardware and the communications/computer technology involved in getting the information from Point A to Point B.

Thanks for the explanation Martijn....then as suggested in the docs, this is the way to go, no? [to make it foolproof] $page->siblings($selector) //or $page->next($pageArray) Can limit to 1, etc....

Custom admin themes go in /site/templates-admin/. The /site/ structure is never touched during an upgrade, so it should be impossible to overwrite an admin theme during an upgrade. http://processwire.com/download/admin-themes/ I'm guessing you had your custom admin theme in /wire/templates-admin/ instead? Just remember that /site/ is all your stuff, and /wire/ is all ProcessWire's stuff. The reason upgrades are easy is because you can just replace your entire /wire/ directory with the new version and you are set. But that also means it's a bad idea to put any of your own stuff in /wire/. Btw, a good practice when upgrading is to bring in the new /wire/ directory under a name like /wire.new/. Then once it's there, rename your old /wire/ directory to /wire.old/, and then /wire.new/ to /wire/. Test that everything is working well. Once comfortable, delete /wire.old/. But if for some reason you noticed a problem after putting in the new /wire/ then, you can simply rename the /wire.old/ dir back to /wire/ so that you aren't suddenly in a bind and unable to revert.

Thanks for the instructions Ryan - I guess these could be appended to the http://processwire.com/about/requirements/ page? Plus, I just wonder about including a warning that you might want to edit .htaccess with any new settings for ProcessWire rather than overwrite with an updated htaccess.txt since it might include other settings required on the server?