bernhard

The PW backend is extremely customisable all over both from the design and from functionality. For the design you can simply modify /site/templates/admin.less (https://processwire.com/blog/posts/pw-3.0.179/) or use AdminStyleRock (https://processwire.com/talk/topic/25668-adminstylerock-easily-style-your-processwire-backend-with-two-simple-settings/). So you can very easily adopt spacings, fonts, font-sizes etc. For functionality you can use hooks or custom admin pages aka process modules (https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/).

Hey @zoeck I've updated an older site to the latest version of RockFrontend (+116 commits ? ) and got this error, which is caused by the LattePanel: The API docs say that ::initialize is deprecated: https://api.nette.org/latte/master/Latte/Bridges/Tracy/LattePanel.html But no idea why this is a problem on this installation since all other projects are also running on php8.1 and don't complain? Any ideas?

One possible solution: $wire->addHookBefore("Inputfield(name=title)::render", function ($event) { $f = $event->object; $id = $this->wire->input->get('id', 'int'); $f->appendMarkup = "<script>alert('You are editing page #$id')</script>"; });

RockFinder is just for pulling data from the database. We actually now have $pages->findRaw() which makes RockFinder obsolete in many cases. The ->dump() method is just for debugging, but if you look into the code you can see how it's done. It uses tabulator.info to display the data that RockFinder pulls from the DB. So you can quite easily build a Lister / ListerPro alternative with findRaw/RockFinder and tabulator. If you don't want to build it on your own you can write me a PM and buy a license of RockGrid, which was built exactly for that purpose, namely taking a RockFinder/findRaw result and turning it into a tabular grid with sorting and filtering capabilities: But even when using my module you need to code your grid via JavaScript, so it's not a click-click solution. But it helps you to get setup quickly and to make the foundation well structured and future proof (maintainable) and it even creates the necessary boilerplate files for you (basically a PHP file for grabbing data via RockFinder and a JS file for setting grid options like sorting, column labels, column widths etc). So you just need to click on "create new grid" and then edit these two files: JS $(document).on('RockGrid2', function() { let rg2 = RockGrid2; // this will add the grid using the default base setup // if you want to use another base setup set it as 3rd argument // see RockGrid2.js for more details rg2.add('Demo', { // here you can set any properties of your grid paginationSize: 15, // column definitions autoColumnsDefinitions:function(definitions) { // loop all definitions and set column settings definitions.forEach((col) => { let name = col.field; // example how to use the link() helper if(name == 'id') { col.width = 50; col.hozAlign = 'center'; col.formatter = function(cell) { let id = cell.getValue(); return rg2.link({ icon: 'edit', href: rg2.editUrl(id), tooltip: 'Edit this page', panel: true, }); } } // example how to use a predefined coldef // you can use this technique with your own coldefs as well if(name == 'title') { rg2.setColDef(col, 'edit'); } }); return definitions; }, }); }); PHP <?php namespace RockGrid2; class Demo extends Grid { public function info() { return parent::info()->setArray([ 'title' => 'Demo Grid', 'icon' => 'check', ]); } public function getData() { // we use findRaw in this example because it is shipped with the core // my recommendation is to use RockFinder3 as it provides a lot more // and customized options for working with PW page data in grids $data = $this->findRaw("id>0, limit=50, sort=-id", [ 'id', 'title', ]); bd($data); return $data; } public function isViewable() { // who has access to this grid? return true; } }

It depends a lot on the project and on your skills. If the PW backend fits your needs, then you'll have a lot less work and headache if you build on top of that. If you have very custom requirements in terms of UI/UX then it might be easier to build a custom backend from scratch. But as you have already mentioned you then also have to take care of everything that PW already does (security, interactivity, permissions etc...) The forum is not built with PW, it just uses the same editor as PW did until recent updates. The link to the forum software is in the footer.

Isn't it just $this->wire->config->js('mySettings', ...) ?

Is anybody experiencing assets loaded multiple times with the new version? If so please let me know (and even better try to find the issue if you can) ? I've had the issue for a short time during development but then it disappeared so I thought it's fixed, but @snck reported the same problem with the latest release. I can't replicate it on my end so it's a little hard to fix ? Edit: We found the issue and I'm working on it ?

Why and where do you want to dump your data? Just for debugging?

@adrian do you have any reproducible example?

Sure. Tabulator can display any data you feed it.

Hi @eydun you don't need RockFinder for that, you can just use the core: $database = $wire->database; $query = $database->prepare("SELECT id, class, created FROM modules"); $query->execute(); while($row = $query->fetch(\PDO::FETCH_ASSOC)) { db($row); } $query->closeCursor(); You could also use the DatabaseQuerySelect abstraction: $q = new DatabaseQuerySelect(); $result = $q->select('id, class, created') ->from('modules') ->execute(); while($row = $result->fetch(\PDO::FETCH_ASSOC)) { db($row); }

Ok learning from the last 2 days: The action that I'm using uses the "angular" preset which has a slightly different syntax than what is listed on https://www.conventionalcommits.org/en/v1.0.0/ Using the conventionalcommits would be possible (https://github.com/TriPSs/conventional-changelog-action/issues/217), but that would mean we had to "npm install" some dependencies, which is not what I want, as the nice thing with this setup is that everything works out of the box with just adding one file to your repo. Memo: Breaking changes need to be written with a "BREAKING CHANGE: ..." footer to trigger a major version bump. The exclamation mark syntax like "feat!: ..." does not work. Thx @dotnetic for your help!

Be sure to check out the new version which has a "security" update:

New month, new version: https://github.com/baumrock/RockMigrations/releases/tag/v3.26.0 Bug Fixes double linebreaks (bf07c6b) magicpages comparing classnames without namespaces (28b5657) prevent migrating pageclasses twice (b3c9add) remove double slash when using $this->path (aa9502c) wirerandom issue on deployment (29bd145) Features add placeBefore to wrapFields() (906753c) add random salts to config-local suggestion (1e7401c) add rm-hints to field and template gui (27b5b25) add support for parent_id as page path (e45e430) imporve createPage for array syntax (74bd338) improve getTemplate (use ::tpl fallback) (b6f6d14) improve isDDEV() (e4df541) improve setFieldData() method (2830eed) use $this->path instead of DIR #22 (f134e1b) One very nice feature is that RockMigrations now adds uikit tooltips to the field and template editor where you can directly inspect the name of the property to use and also the value of one setting, which is very handy if you need a setting that you don't know by heart. With this update you don't need to find the setting by inspecting the html markup any more and you can instantly see it by hovering over the setting:

I've just released RockFrontend 3.0 https://github.com/baumrock/RockFrontend/releases/tag/v3.0.0 @netcarver found that .less and .latte files were publicly accessible if you knew the file path (eg example.com/site/templates/sections/footer.latte) which is for sure something that you don't want even though it should not really be a security concern. Sorry for that and thx for spotting @netcarver ! The latest release updates /site/templates/.htaccess to block access to .latte/.twig/.blade/.less files so be sure to upgrade RockFrontend in all your installations! Other than that I've also changed the way how RockFrontend loads assets and I'm not 100% sure if that might introduce issues in existing sites, so be sure to check if everything works as expected. New features: RockFrontend now ships with https://github.com/wasinger/htmlpagedom wich let's you parse and manipulate html markup which can be super handy in several situations. I'm using it on my new website where I'll show docs for all my modules that are rendered from markdown files and add some magic here and there via manipulating the resulting html that comes from the markdown parser. Improvements for the Topbar: There is now a toggle that makes it possible to hide/unhide the bar instantly (and persistantly). Also you can add your own custom markup to the topbar by adding custom markup to $rockfrontend->topbarPrependMarkup or topbarAppendMarkup.

I'm using DDEV, so every project has it's own URL like myproject.ddev.site https://processwire.com/talk/topic/27433-using-ddev-for-local-processwire-development-tips-tricks/ That works great for PW but not sure if that also works for WordPress as I heard it does weird things with hardcoded hosts all over?!

There's this: https://processwire.com/talk/topic/18719-maintain-separate-configs-for-livedev-like-a-boss/ And this: https://github.com/processwire/processwire/pull/267

I don't think it's a good idea to shut down the database completely. ProCache will cache pages for a given amount of time and then try to recreate the cache. I don't think that it will be happy about a dead db connection... Do you want to tell us WHY you want to do that? There's also https://processwire.com/modules/static-wire/ but I've never used it and I don't know if it still works...

I think you are right for the ->title, but not for the ->url. The url is a property of the page object, not a regular field. So there is no textformatter applied and therefore it should just work like shown in the example. If you have a textformatter applied on the title field, then you'd need a |noescape filter in latte, yes.

Sure, there are always many ways ? If I understand correctly you could also do this: <li n:foreach="$downloads as $downloadPage"> {do $downloadPage->of(true)} {include 'download-list--teaser.latte', page: $downloadPage} </li> What about adding a {do $page->of(true)} at the top of this file?

I'd go with option 4 and use $page->getFormatted('your_image_field') ? That ensures you get the formatted value no matter which state the global OF is in. And you can use the new syntax like $page->getFormatted('your_image_field.first') if you want to ensure that you get a single page image object no matter what the field settings say about the formatted value. That means even if your field settings are changed some time by some person your script will still work.

First of all there is $page->of(false) and $pages->of(false). First is singular and sets OF for the single page object, second is plural and sets it globally. Second, even if you have OF=false on a page and you echo a field's content, then you request the string value, which will automatically request the formatted value of your field: Also if you are on the frontend and not in module development there should be OF=true by default.

Hey @zx80 welcome to the forum! Glad to hear that! Would be interested in how you found my video (which one btw)? I'm not sure if I understand, but it sounds like you have already found a better approach? When being new to PW there are often situations where you think far too complicated, because you have learned that things work like that or have been done like that. And in PW there is often a much easier and quicker way. Not always of course ? As I didn't really understand what exactly you are trying to do I'm also not sure why you need a console script here? Great! If you still need help or have questions it might help to give more detailed examples. If you are already happy with what you have congrats for your first steps in PW ?

It should work just like any other PW api... Does it render empty divs? Does it throw an exception? I'm never using {include ...}, I'm always using {$rockfrontend->render(...)}, but both should work.

Define "low cost" ?