Leaderboard

Yes, quite easy ? $wire->addHookAfter( 'ProcessPageEdit::buildForm', function (HookEvent $event) { $form = $event->return; $page = $event->process->getPage(); // if page is young enough don't lock the page name field $lockPagenameAfterSeconds = 60; if ($page->created > time() - $lockPagenameAfterSeconds) return; // get field and set status to collapsed + locked $field = $form->get('_pw_page_name'); $field->collapsed = Inputfield::collapsedLocked; $field->notes = 'Can not be changed any more'; } ); Alternatively you could use $page->meta() to set a flag at some point instead of waiting 60s.

You may want to use path hooks for this: https://processwire.com/blog/posts/pw-3.0.173/#introducing-url-path-hooks You can also hook into 404, but I don’t have a snippet handy right now. I’ll post one if no one beats me to it, but I think path hooks are probably the best way to do what you describe. Another option would be URL segments. You could define a regex to only allow a single integer URL segment.

Multiple sites per account (Cloud version) Hi, I have just launched the new version of PAGEGRID Cloud (SaaS). It's now possible to have more than one site. I also removed some of the old restrictions for the free version. Now you can have unlimited sites, pages and items and only the webspace and publishing options are limited by the tier. This makes it more flexible and easier to get started. Simultaneously publish a portfolio, client website, idea boards, a profile site — basically any kind of site you need — all with a single account. Create as many sites as you like for free. Choose a desired service option and make a site public when you are ready to launch. Start with a blank canvas or use one of the site templates. Optionally buy a self-hosting license and export a site at anytime. (Of cause you can still host ProcessWire yourself and just install the PAGEGRID module from the modules directory.) Start for free (More templates will be added soon)

I could have sworn there was a $config->advanced option in template settings to disable this, but apparently there is only one to prevent a page from being moved. Of course, you might want to do that, too, if you need stable urls. Also note Bernhard’s hook only hides the field from the edit form, but it could still be changed through code or even (I believe) with simple browser dev tools trickery on the part of an editor. To prevent it even through the API you could probably hook into Pages::savePageOrFieldReady: https://processwire.com/api/ref/pages/save-page-or-field-ready/

Fridays are always the days when I'm full-time on ProcessWire. Other days I may be doing client work, or ProcessWire, just depending on the week. This week it's been mostly client work. And I just learned that I'll have to be out of the office tomorrow (Friday) for a family commitment. So I'm writing this weekly update today instead, and just sent out Teppo's great ProcessWire Weekly newsletter with ProMailer today (usually it gets sent Friday). Because of this change in schedule, I don't have much new to report just yet. Instead, I wanted to start talking a little about future plans, so here's a few ideas. I think we should get another main/master version out, perhaps by September. Following that, I thought we should focus on ProcessWire 3.1, or maybe it's time for version 4. What would be in this next major version of PW? For starters, we'll finally drop support for older PHP versions and start taking advantage of all that's been added new newer PHP versions (8+). This will involve lots of updates to the ProcessWire core code base, while remaining 100% API compatible with PW 3.x. I thought that would be a good starting point into our next major version at least. In addition, we'll likely be trimming some things out of the core and into separate non-core modules, such as FileCompiler, CKEditor, the two legacy admin themes, and a few rarely used Textformatter modules. Most likely we'll also have an overhaul of this website and some nice improvements to our primary (Uikit) admin theme to accompany the next major version as well. There will be plenty more too, but this is what I've been thinking about so far. Your feedback is welcome. Thanks for reading and have a great weekend!

The path seems to be correct. I am using the same path in my font declarations: @font-face { font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ font-family: 'Barlow Regular'; font-style: normal; font-weight: 400; src: url('/site/templates/fonts/barlow-condensed-v12-latin-regular.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ } I would try out this advice from @da²

Really? ? Maybe check the root directory you set in Apache config. It looks like it's targeted on mysite/site/templates/ instead of mysite/. Personally I use relative paths in CSS (url('../font/NotoSansDisplay-Regular.ttf')), but that doesn't matter, if I enter url('/site/templates/font/NotoSansDisplay-Regular.ttf') it works fine too since Apache root directory is set on parent directory of /site/.

Awesome! As always.

I think existing pages always have precedence over path hooks, so if a page called “/folder/4545” actually exists, no path hooks will run for such a request. But in your example, the page is actually called “/folder/4545-foo-bar”, so a path hook like this would trigger: $this->wire()->addHook('(/.*)/([0-9]+)/?', function($event) { $page = $event->pages->findOne([ 'parent' => $event->arguments(1), 'my_id_field' => $event->arguments(2) ]); if($page->viewable()) $this->wire()->session->redirect($page->url); }); This should find any path whose last segment is an integer, try to find the page with that integer among the children of the preceding path, and redirect to it. Normally I would test this before posting, but I’m not on a suitable machine…

Hi @bernhard - the clone icon is visible for the user. This is what they see on the front end with Alfred: Regards, Ian.

I have updated all but one server to 2.4.61, but yes, I am still seeing the issue on 2.4.41 (including that UnsafeAllow error) so not sure what's up with that :) Figured this out - see my post below:

Weird that you saw it on the old version, because like you say it's probably related to the changes in Apache 2.4.60 https://httpd.apache.org/security/vulnerabilities_24.html https://www.cve.org/CVERecord?id=CVE-2024-38474

I haven't experienced the issue (I get normal 200 responses for User Activity requests) but it sounds like some sort of pre-emptive security blocking. If you're running WireRequestBlocker see my topic here because the default rules are quite broad. Or maybe your host has introduced some security software without notifying you? I had an irritating situation like this with Cloudways recently (thankfully resolved now).

Ok, I have got things working again by removing the encodeURIComponent() from '?activity=' + encodeURIComponent(activity) + from UserActivityAdmin.js and I've pinged @ryan about it in a DM but at this stage, I'm really not sure why this became a problem all of a sudden.

Oh, no... sorry. Don't have that. ?

@wbmnfktr - it's this one: https://processwire.com/store/pro-dev-tools/user-activity/

Isn't this the most modern way of doing it? html, body { height: 100%; } body { min-height: 100vh; // those who don't know min-height: 100svh; // those who know margin: 0; }

Hey @bernhard. Did you think about pushing the footer down to stick always to the bottom? That might fix issue maybe. Nowadays it is easy to accomplish. Take a look at https://developer.mozilla.org/en-US/docs/Web/CSS/Layout_cookbook/Sticky_footers for example. If you don't want to use a wrapper, you can also use the body and set it to 100vh.

Before I find time to add my very own wishlist let's not forget the PW requests repository

It doesn't come up all the time for me (depends on the site) but often enough that I agree with others that re-using images on other pages is important. I rarely insert them into the editor - that's my problem. How could we have an image from a different page's single/multi-image field be used in another page's single/multi image field because that's how I would need to use that feature? Maybe next to the upload button have another button to select existing from another page (or media manager - I like that idea) and it's inserted into that field as a reference and can have it's own description, tags etc. Likely others have already talked about this a lot over the years whereas I've just ignored it and duplicated my images quite a few times ? I think though that this is where storing images in folders by page ID would maybe need to be replaced with something else to uncouple them from page IDs on disk, like maybe files/field id/ instead though granted that would be complicated for an existing site with thousands of images already on it. They'd also need to be grouped under the field ID as on a travel website /files/photos (as an example) could have 10k files or a lot more with variations under it easily. Not sure that's actually a problem though - feels like it might have been 10 years ago but maybe it's not now. If you wanted though you could have a subfolder per image ID for that field to store it and all variations neatly which somewhat alleviates the issue.

I think the most talked about feature is an asset manager. The drilling down of file and imagefields so that you can choose assets from a global library that have already been uploaded somewhere, instead of having to upload assets multiple times. Actually, the approach using references is the best I've come across so far. The data remains where it was originally uploaded, but is only referenced in a file/image field on another page.

With all due respect, disparaging PW over this is entirely uncalled for. It’s not a ProcessWire concern. Whether it’s links or redirects, your issue lies in interfacing with the browser. ProcessWire’s session()->redirect() is just a thin abstraction over HTTP/1.1 301 moved permanently Location: http://example.com If a browser doesn’t want your site to open a new tab, it’s not going to open a new tab. I’m sure you’ve seen sites of questionable repute apply some trick or other to open pop-ups, pop-unders and whatever else, and you can use ProcessWire just fine to deliver those same tricks, but ProcessWire’s role in that ends at helping you manage and assemble the data for your response. Admittedly I’m still not certain what your clients’ goal is. You have a clickable link in a sidebar and want it to open in a new tab, but somehow it also involves a redirect? Sorry I can’t be of more help, but I’m sure we can get it figured out if it’s at all possible.

UPDATE 2022 Simple and powerful - put this at the end of your config.php file: $localConfig = __DIR__ . "/config-local.php"; if (is_file($localConfig)) include $localConfig; Then put all local settings into config-local.php (same concept for DEV/STAGING/PRODUCTION): <?php namespace ProcessWire; /** @var Config $config */ $config->debug = true; $config->advanced = true; $config->dbName = 'db'; $config->dbUser = 'db'; $config->dbPass = 'db'; $config->dbHost = 'db'; $config->userAuthSalt = '1234'; $config->tableSalt = '1234'; $config->httpHosts = ['xyz.ddev.site']; // this prevents logout when switching between // desktop and mobile in chrome devtools $config->sessionFingerprint = false; // RockFrontend $config->livereload = 1; // RockMigrations // $config->filesOnDemand = 'https://your-live.site/'; $config->rockmigrations = [ 'syncSnippets' => true, ]; // tracy config for ddev development $config->tracy = [ 'outputMode' => 'development', 'guestForceDevelopmentLocal' => true, 'forceIsLocal' => true, 'localRootPath' => '/Users/xyz/code/yourproject/', 'numLogEntries' => 100, // for RockMigrations ]; $config->rockpagebuilder = [ "createView" => "latte", ]; -------------------- OLD POST from 2018: Have you ever come across the situation where you needed to change your config.php file for local development? Have you ever come across this warning? Say goodbye to this little annoying tasks Some of you might know that you can have a separate config-dev.php file for local development. This is nice, but also needs some setup (for example excluding this file for git upload) and there is still some danger of uploading this file to a place where it should not be... The other option was to keep the database settings for your live and dev server in sync - also not easy and maybe not the best... My solution is as simple, fast and I think it should be even safer than the other options. Just put these lines at the end of your config.php file: if(strpos($config->paths->root, 'C:/www/') === 0) { $config->dbUser = 'root'; $config->dbPass = ''; $config->httpHosts = [$_SERVER[HTTP_HOST]]; $config->debug = true; } elseif(strpos($config->paths->root, '/var/www/vhosts/') === 0) { $config->httpHosts = []; $config->dbUser = 'XXX'; $config->dbPass = 'XXX'; $config->debug = false; /** * Redirect to HTTPS * ATTENTION: This will NOT work with ProCache enabled! Use .htaccess instead */ if(empty($_SERVER['HTTPS']) || $_SERVER['HTTPS'] == "off"){ $redirect = 'https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']; header('HTTP/1.1 301 Moved Permanently'); header('Location: ' . $redirect); exit(); } } else die('wrong config.php'); Having a separate config-dev.php file also makes it necessary to keep both files in sync. That was my first idea: To include the original config and then overwrite settings. But it's just simpler the other way round: Using the default config.php file and overwriting settings there.

Have reworked all my projects with Latte and CustomPage classes and the code is more clean, way easier to read and maintain and more structured now. Definitely recommend diving into Latte and CustomPage classes for new projects to anyone. Both techniques were easy to learn and paid off quite soon in my projects.

Hi @Autofahrn, thx for that suggestion. I did not try that. But I'm not sure how I should/could do that to get a helpful output? I've found the issue, but would still be interested in a way to show a backtrace of all executed hooks ? I've added a file_put_contents(... FILE_APPEND) to WireHooks::runHooks() to dump all executed hooks to a file called hooks.txt. That could be a first step in the direction that I wish would exist already. The issue in my case was that my CRM module was loaded twice, so all methods added via hooks actually ran twice. I found that by inspecting the debug mode tools, where my cloneInvoice() method showed up twice (and so did all other CRM hook methods). The solution was to make the module "singular" (and do a module refresh). But still I think it would be great to have a chronological list of all executed hooks so that one can instantly see which hook fired when (and after/before what other hooks).