Leaderboard

@benbyf - you might prefer Tracy's API Explorer for getting the docs:

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!

There are a few things I want to solve, atleast for me, with Symprowire. - poluted global state - dependency injection - clean separation of concerns - Raw PHP in Template Files - no standards in templating - testable code Due to the way ProcessWire handles his templating the global state could get pretty poluted with vars floating around and on top you will most likely add business logic to your template. I prefer a more concise and separated aproach. As a developer I do want to use libraries from the Userland with composer to manage my dependencies and not have to wrap them into a module with the added overhead. I need a Dependency Injection Container to have a nice and manageable way to use my Objects. I want to use twig as template language to benefit from template inheritance, autoescaping and all the other goodies it ships. I need proper Event Dispatching and Handling driven by Types as Subscribers. I want to be able to test my codebase. Symprowire will be niche and way too much for a light, few pages webpage, but it will give you a well structured way for accessing and rendering your data outside of the admin. Symprowire is more like an application framework but could replace the ProcessWire renderer easily and is flexible enough to just serve your templates. In fact, I pushed the new concept to the repo so you may have a look at the codebase. As of now, Symprowire will add ~ 7-12ms to your Request after resolving to a Controller action and gives you a proper Controller Resolver, Event Handling, Twig, Dependency Injection. Im looking forward to release 1.0 ?

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.

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 ?

This is what I do, which is almost like (2). site/config.php: <?php namespace ProcessWire; if(!defined("PROCESSWIRE")) die(); // Other PW default config values... // ... $config->dbHost = 'localhost'; $config->dbName = 'example_site'; $config->dbUser = ''; $config->dbPass = ''; $config->dbPort = '3306'; $config->dbCharset = 'utf8mb4'; $config->dbEngine = 'InnoDB'; // Environment overwrite if (file_exists(__DIR__ . '/config.local.php')) { require_once(__DIR__ . '/config.local.php'); } config.local.php: <?php namespace ProcessWire; $config->dbUser = 'example_site_user'; $config->dbPass = 'example_user_pass_123456'; config.local.php is in .gitignore, so never committed, and separate config.local.php files exist on testing / live environments. (I use DeployHQ and this is added as a config file that gets deployed with the rest of the code). To me, the benefits of this approach means that the entire config can be changed depending on the environment, and used to turn things on or off, like debug or advanced mode.

@netcarver That's perfect, thanks. Getting the full URL using API methods only is surprisingly long-winded. This is the best I could manage: $full_url = $page->url; if($input->urlSegmentsStr) { $full_url .= $input->urlSegmentsStr . "/"; } if($input->pageNum > 1) { $full_url .= $config->pageNumUrlPrefix . $input->pageNum; }

It turns out that there is no need for special setup except for setting the right header type. My execute function looks like this and returns pure JSON: public function ___executeAjaxControl() { // handle banword saving if($this->input->get->banword) { $banword = wire('sanitizer')->text($this->input->get->banword); if(wire('pages')->get("template=banword,title={$banword}")->id) { $out = "Stoppwort existiert schon"; } else { $b = new Page(); $b->template = 'banword'; $b->parent = wire('pages')->get('template=banwords'); $b->title = $banword; $b->name = wire('sanitizer')->pageName($banword); try { $b->save(); } catch (Exception $e) { $out = "Es trat ein Fehler auf:{$e->getMessage()}.Bitte erneut speichern."; } if($b->id) $out = "Stoppwort {$b->title} wurde gespeichert"; } } header('Content-Type: application/json'); return json_encode($out); } @admin: I can't mark this as solved