Leaderboard

Apologies communication hasn't been ideal. No one who signed up will be left out. You will get an email shortly before or after the release with further information. I am working flat out for Padloper 2 to make Santa's list ? ?.

Hi I created new module for adding links to quickly edit a field directly from page edit. https://processwire.com/modules/admin-helper-links/ You probably already know existing module HelperFieldLinks created by @Soma which was my inspiration. I was using that module for a long time so thank you @Soma! The reasons for this new module are that HelperFieldLinks seems inactive and contains few bugs. I decided to try to fix them, but after a short time I realized a better (i think) and simpler solution and also got some new ideas how to improve. I used javascript instead of PHP and modified a code which is already in PW source code to show field names when you hover the inputfield's expand arrow (in debug mode). I also moved the cog icon next to the expand icons which doen't break the layout so much. What is missing is the field info panel with it's props, never used it, but it can be done too. The template edit links needs to be added too. If you got some ideas how to improve, tell me.

Over the years, I've experimented with using RepeaterMatrix as the basis of a rich page builder. I've gone through at least a dozen concepts, most of which hit the chopping block due to either being too complex, not well thought out, too clever or too limiting. To my knowledge, the only other CMS that takes the "Builder" approach that I've demonstrated is DjangoCMS (meaning, it has a matrix-like field with depth support). While the "Builder" approach works well, it could be too advanced for some people. Therefore the other approach is the "Classic" approach where you don't deal with containers/rows/columns (which instead is handled by template code), and simply enter the content in the respective field. This is easy to understand, but has drawbacks in terms of flexibility. If it were made to be too flexible, it would become a "God" block which is bad. Then I finally thought of a third approach which is a mix between the Builder and Classic approach. It uses the basic builder blocks, combined with the layout from the matrix item template file. By using the basic builder blocks, you get the plethora of options. It requires an extra page to be created behind the scenes however, but live preview still works. I made a video comparing all the above (10m duration). I want to hear your feedback on this as I am ~75% done with my super module (doing a lot of code and concept cleaning at this point) and want to finish off this portion of it. (note: I'm posting this in the Dev Talk forum since this is a discussion / not support request)

This week ProcessWire has gone on a diet. I've been working on reducing the size of the core by moving all (except site-blank) installation profiles out of the core and into their own repositories. This cuts the size of the core in half, going from 15.5 MB down to 7.5 MB, which is quite a slim down! This means the site-regular, site-default, site-beginner, site-languages, and site-classic now live in their own dedicated repos on ProcessWire’s GitHub. The site-blank one remains, but I've updated it a bit to make the template files more useful for beginners while still keeping it a blank profile. I may do a little more with it and rename it to be site-basic or something, and then have an even more trimmed down site-blank in its own repo as well. I'm not yet sure about that, so will do a little more with it next week also. I also went through each of these site profiles and cleaned up a few things, corrected old and outdated links, and updated a lot of text in readme files and such. I think a lot of the more experienced users would also prefer not having extra profiles included in the core as well. This update came at the request of the community a few months back (I think it was Robin S. that requested it, but not positive). It's not like any of the current site profiles have a lot of bling or marketing value, as they really are more just technical examples and starting points. So I think it's kind of a win/win to trim down the core in this way. Though maybe one day we'll have a site profile that looks good and has good marketing value. But until then I think we gain more by keeping the core size nice and trim. The downside is that there's a little more for new users to figure out (downloading a profile), so in the next week or so I'm planning to update the installer to hopefully lessen that issue and maybe even build in the ability for the installer to download and install site profiles from the modules directory. That comes with its own security considerations, so I'm not yet sure we'll go that far just yet, but it's one of a few options I'm looking at. Thanks for reading and have a great weekend!

v0.0.75 adds a new method addLanguage() that makes it super easy to add a new language to your pw site: // get german translations for default language $rm->setTranslationsToLanguage("https://github.com/jmartsch/pw-lang-de/archive/refs/heads/main.zip"); // add english as second language (including language field tabs and page names support) $rm->addLanguage("en", "Englisch"); https://github.com/BernhardBaumrock/RockMigrations/commit/3e52805b9f6f3582f63826d179c753f1ad6c0750 I had a quite hard time to get this working because setting the "name" of the root page was not as easy as expected. I had to hack it via custom sql: https://github.com/BernhardBaumrock/RockMigrations/blob/3e52805b9f6f3582f63826d179c753f1ad6c0750/RockMigrations.module.php#L2235-L2242 If anybody finds a better way of doing this please let me know ?

Select Once Per Table Adds a setting to "Select", "Page (Select)" and "Page (Autocomplete Single)" columns in a ProFields Table field so that each option can only be selected once per table. Requires the ProFields Table module. There could be a number of situations where this module might be useful, but perhaps the primary situation is when you want to store extra information for pages that are selected in a Page Reference field. So instead of using a Page Reference field like this... ...you could use a ProFields Table field together with Select Once Per Table to store extra information for each selected page like this... The module ensures that pages/options that are already selected in the Table field are disabled as you add new rows or edit existing rows. Configuration To enable the module for any "Select", "Page (Select)" or "Page (Autocomplete Single)" column in your Table field, edit the column settings and add selectOnce=1. https://github.com/Toutouwai/SelectOncePerTable https://processwire.com/modules/select-once-per-table/

Same here ? So thx for you module! @szabesz you know that tracy shows the template in the panel (and it's a link) @Richard Jedlička you can add uk-tooltip attribute then AdminThemeUikit will show the title="foo" as nice tooltip on hover ?

This is what I'm doing with RockMatrix: I guess that's option 3 ? Not perfect, but the best option I have so far... While I see the benefits of option 1 I can't see any client in the world be able to use it. And even if you where a developer it would need very good understanding of the setup or css framework that you use to understand exactly what you need to do, where you need to click, which block you need to indent and where etc...

Hello, Thank you for sharing your module. I used to install AdminOnSteriods on all of the sites I work on, which module (among lots of other features) can do the same. However, since AdminOnSteroids might not be maintained in the future, I started not to use it. What I am really missing without AdminOnSteroids is this feature you implemented, and a similar one, which is a link to the edit template page. So my first idea to improve the module would be to add an "Edit template: templatename" link next to the title of the page (H1 id="pw-content-title" in the html source of the page). BTW, I installed it and the cog icon does not show up, because you hardcoded the admin url into the module. Could you please us $pages->get($config->adminRootPageID)->url instead? Yeah, it involves PHP, but: https://processwire.com/talk/topic/8343-access-page-and-pages-variables-from-inside-a-javascript-file/ Or maybe some knows that the admin URL is already provided by the PW admin on the JavaScript side as well?

Version 1.1.0 is here. - added template edit link - added link for editing field in template context - using modals - style update: changed link icons, field name, tooltips, ...

This is sooo cool. Thanks Bernhard

Hi @szabesz, thanks for your reply. I will, hope, add the template edit link soon. Yeah I hardcode the url, I didn't realized it can be changed, will fix it.

The trailing slash setting is something that applies to URLs rather than paths, i.e. $page->url rather than $page->path. Related GitHub issue with response from Ryan: https://github.com/processwire/processwire-issues/issues/273

That's a Cloudflare CDN message. As far as I know it's some kind of Firewall rule to block unwanted traffic.

I've added support for "Page (Autocomplete Single)" columns in v0.2.0.

Turn on debug mode in config.php. When you are able to log into the admin, go to the debug accordion at the bottom. Under 'Pages Loaded', how many pages does it say it loaded?

Thanks for the link, I had this link buried somewhere in my bookmarks. Sadly most of the nav examples are equal to the UIkit accordion, where a parent page is only a trigger. The big screen navigation has the usual dropdown (ul.level_2) You mean adding a redirection link to the parent page, based on a template that can be hidden via: 'selector' => 'template!=basic-page-hidden', home parent-page 01 parent-page 01 (redirect) child-page child-page child-page parent-page 02 parent-page 02 (redirect) child-page child-page child-page about contact

I really like the idea behind the third approach where every block has its sets of options to work with. I don't really like the way to access them, via a modal interface, even tought I think you've used it since it's the current best way pw gives us to stay in the state of the page edit. One better approach would be to have somewhere a tab (or tabs) for each and every component inside the block (in this case image and text, as for your example) where the options might have their place to live, something similar to what we already have for the rest of the pages. Or maybe, and even better, use the pw native sliding panels to edit the content of each block. Great job by the way!

There's a new $pages->new() API method on the core dev branch this week. This method is similar to the $pages->add() method, in that it is used to add new pages to the DB, but is a lot better in my opinion. The $pages->add() method has arguments that you have to remember, whereas $pages->new() accepts a single-argument selector string, like many of the other $pages API methods. This new method can also auto-detect some properties that the add() method cannot (like parent or template). Let's take a look at how to use it. Here we create a new page from a selector string, and it returns the new page (saved in the database): $p = $pages->new("template=category, parent=/categories/, title=New Category"); If you prefer, you can also use an array: $p = $pages->new([ 'template' => 'category', 'parent' => '/categories/', 'title' => 'New Category' ]); The page name and parent can be auto detected if you specify a path: $p = $pages->new('path=/blog/posts/foo-bar-baz'); But if you start the selector string with "/" then it is assumed to be the path, so this is is exactly the same thing as above: $p = $pages->new('/blog/posts/foo-bar-baz'); In your selector string or array, you can specify any page property or field name that you want to set with the new page. It's basically just a quicker way to do something that's already pretty easy to do, but I thought people might find this new option even more handy in many instances. To create a new page, it needs to know the template and the parent. If your template family settings are configured in a manner where it can auto-detect, then it will do so, at which point parent or template becomes optional. In the last example above, it detected that the template was "blog-post" and the parent was "/blog/posts/". A few things to note (pulled from the method documentation): If a `path` is specified but not a `name` or `parent` then both will be derived from the `path`. If a `title` is specified but not a `name` or `path` then the `name` will be derived from the `title`. If given `parent` or `path` only allows one template (via family settings) then `template` becomes optional. If given `template` only allows one parent (via family settings) then `parent` becomes optional. If given selector string starts with a `/` it is assumed to be the `path` property. If new page has a name that collides with an existing page (i.e. “foo”), new page name will increment (i.e. “foo-1”). If no `name`, `path` or `title` is given (that name can be derived from) then an “untitled-page” name will be used. The `class` of the Page will be auto-detected when applicable (and something different than `Page`). An exception will be thrown if it doesn’t have enough information to create a new page in the database. I've also updated the existing $pages->newPage() method to accept the same selector string (or array). You might already be familiar with this method, but if not, it creates a new page in memory, but not the database. So you might use it to create a new page that you will call save() upon later. $p = $pages->newPage('template=blog-post, name=hello-world'); This week the core also has a few issue fixes. I'll wait another week before bumping the dev branch version though, as there's more to add first. Though the next few weeks might be little slower on core updates as the end-of-the-year seems to always be the busiest time when it comes to client work... everyone wants to wrap things up before the new year, and I do my best to accommodate that, while also keeping PW updates in progress. Thanks for reading and have a great weekend!

Thank you so much for this post. This should be considered for the official documentation. It would have saved me a lot of time and headache when developing my first custom fieldtype

In other news: Color-coding content blocks is such a great addition. Even those who don't use the backend that often find the right spot way easier now. Thanks @Ivan Gretsky for the idea and @ryan for adding this to the latest dev branch.

Hey @Zeka To be honest what you're currently doing sounds like a reasonable solution, and also goes beyond what I've personally ever done/needed. In most projects I've got a handful of components — I think around ten or so at most — so splitting them into directories hasn't really been worth it. Boils down to preference, really; I tend to use partials for most things, and components only when I really need the power (and complexity) they add ? So, long story short: there's no built-in way to split components into directories, but that's not a bad idea (after all that's always been there for partials), so I've added it to my list for now.

Just return json directly like so: http://stackoverflow.com/questions/4064444/returning-json-from-a-php-script

$pageArray->has($page); http://processwire.c...er=has Also it doesn't matter if you add duplicates as PW will remove them anyway.