Leaderboard

I use Sublime Text as my editor. I've tried others, but haven't found anything close to Sublime in terms of usability and performance. Most PW projects use the following modules: ProFields FormBuilder Wireframe ProcessCacheControl AdminTemplateColumns Any additional PHP dependencies are added via Composer. I use Laravel Mix to handle front-end compilation / bundling of SCSS and JS. It's a nice "wrapper" around Webpack that simplifies this process a lot. (View one of my webpack.mix.js files that runs PurgeCSS for production builds) All code in Git repositories hosted on GitHub, and use Sublime Merge as a Git GUI. Hosting-wise, most PW sites are on a Krystal reseller account or a client's hosting (if you use referral code 'CRAIG' we share £20 equally). For new sites, I do set up staging/development versions as a subdomain so it can be previewed. For deployment, I use DeployHQ (referral link / normal link) (also by Krystal) - which handles the transfer of changed files from Git over to the hosting via SSH - either manually or on Git push. It also does the front-end build step and Composer package installation as well so I don't have to do that myself. During development, I disable the template cache with this in a ready.php hook. // (I also set `$config->env = 'development';` elsewhere) if ($this->config->env === 'development') { $this->addHookBefore('Page::render', function($event) { $args = $event->arguments(1); $args['allowCache'] = false; $event->setArgument(1, $args); }); } I recently posted about how I do separate configs for different environments.

This week there have been various small core updates and fixes but the biggest change was to the installer in 3.0.191. Last week we removed all but the site-blank profile from the core, cutting in half the size of the core. And because of this, the installer now needed to provide more direction about downloading and installing other site profiles. So it now does that and it also links to a new page that describes all of the past and current site profiles, along with additional details on how to create and install site profiles. Speaking of creating site profiles, the Profile Exporter module was also updated this week. It is now PW 3.x exclusive and is updated to recognize and work with various aspects and $config properties that are specific to 3.x. ProcessWire 3.0.191+ and the Profile Exporter module now support a custom /site/install/finish.php file which is a template file that is called when installation of a new ProcessWire and site profile has finished, but before it has cleaned up the installer. It is a plain PHP file that has access to PW's API and the installer, so it can do pretty much anything you could do from a regular template file or module. I added this because I noticed a few issue reports for the Profile Exporter module were requesting support of one thing or another, and I found that nearly all of them could be added just by having a profile-specific finishing file, for those that want it. So if you want your site profile to perform any other types of customizations on top of what you can already do with a site profile, this is the place to do it. This is where things are at this week but perhaps we'll continue to go further with the installer in supporting more things too in the new year, as there have been several good ideas. Thanks for reading and I hope that you all have a Merry Christmas and/or Happy Holidays!

Hi Ryan, Big thanks for doing this, as it adds to beginners friendly and jump start with Processwire. Merry christmas to the Processwire Family

I can confirm this with a totally new and clean installation. No modules, hooks, whatever.

@ryan I am unable to create pages with 3.0.191 I wanted to use the quiet days to set up a small website for a friend. DEV 3.0.191, multilanguage German and English with German as the default, as I did countless times. The website was pretty basic with only AOS and Combo modules. When I wanted to setup a basic page structure I noticed that I cannot create pages, as PW redirected me to Admin - Access - Users, with the warnings that the page name is already in use, the page has been created, and has been renamend to xxxx-100, which wasn't the case. No page was created. A downgrade to 3.0.190 solved the problem and everything works as it should. Screenshot: Translations: The page /de/bio/test-100, using template Standardseite(basic-page) has been created.(not true) Warning! the page name test is already in use and has been changed to test-100(not true)

15 inch MacBook Pro, no external monitors. I'm used to pretty small print — cranking the resolution setting to max space and then decreasing the font size a few times works wonders ?

Merry Christmas and Happy Holidays, @ryan!

These seem very much related: there shouldn't be any need to skip over identical (consecutive) entries, since such entries shouldn't occur ? In the latest dev version of the module I have some issues with image fields, where a) adding an image via AJAX is registered as a change, and then b) on page save field content is updated, also registering as a change. This could be related, perhaps? You could check which fields are involved by querying version_control__data and version_control__revisions database tables: the data table is connected to the revisions table with "revisions_id" column, and each row in the data table refers to a single fields_id + property pair, so there may be multiple data rows for each revision row. I'm hoping to get the latest changes (currently in feature-data-objects branch at GitHub) polished and merged to dev, hopefully that will fix this issue as well. Fingers crossed that I'll get there soon. Any changes/updates to this module are pretty time consuming — part of why the feature-data-objects branch exists is to reorganise things, hopefully bringing sanity to the module's architecture ?

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

That is true, but they do require looking up the class name if you don't already know it. I noticed that InputfieldSubmit already has setSmall() (only 1 line of code) and setSecondary(). setDisabled() seemed like it would be consistent with these, just saying.

Hey guys, this upgrade now appears on PW 3.0 (devns) branch. If you are using the ~= operator in a search, like "title~=disability act" it now asks MySQL for the ft_min_word_len (per @LostKobrakai's suggestion above). If any word length falls under that threshold, it delegates that word to a separate REGEXP command in MySQL that matches whole words. This is actually an improvement over the code I mentioned earlier because the previous code that converts it to use a "%=" for short words could match things like "disability fact" or "react to this disability" etc. Whereas the new core addition will only match whole words in the same way that the MySQL index would, meaning the field would only match if it contained the exact words "disability" AND "act" somewhere in the field, and not some word that happens to contain the partial word "act". To take it further, it also now uses this technique to match stopwords that MySQL doesn't full-text index. Previously it would just exclude them from the search since the presence of a stop word would prevent a search from matching. Now you can perform searches that include those stop words and match them.