dotnetic

Wow. This looks so cool. The creation of fields and templates via the admin might not be for everyone, but I think you can generate the migration file also by hand, right? A feature that has been requested multiple time, is that all changes that you do in the admin should be tracked and added to a migration. I like the basic idea behind it, and think of a hook, that gets triggered after creating a field/template, or making modifications to a field, which automatically or after confirmation modifies or adds a migration file. As you are also running a diff, you might create a migration automatically, to see what changes have been made to templates/fields/contents since the last migration. Then you would just choose which templates/fields/contents should be included in the migration. For example you added a new field, added it to two templates and created a new page with one of the templates. Now your module could run a "Get changes" command, that fetches all differences since the migration and asks which of them you want to integrate. With this behaviour you would not have to remember and "define the affected elements" as in your video. What you think about this approach? I am also happy to have a look at your code and try it out, because I think migrations is a major issue with ProcessWire right now. I am using @bernhards RockMigration atm, but also like your approach. Migrations should be an important part of the core IMHO.

Thanks @bernhard. Problem solved

I added this example code taken from ProcessWire 3.0.173 core updates: New URL hooks to my site/_init.php // _init.php wire()->addHook('/hello/world', function($event) { return 'Hello World'; }); and get the following error: So what is wrong? As I am in the _init.php the hook should be attached during init, right?

@dlen I forgot, that the name of the default language is always default and can not be changed. Please try this updated code. BTW: where did you took that code example from? <?php $alternate_languages = ''; foreach ($languages as $language) { // if this page is not viewable in the language, skip it if (!$page->viewable($language)) { continue; } // get the http URL for this page in the given language $url = $page->localHttpUrl($language); // output the <link> tag: note that this assumes your language names are the same as required by hreflang. if ($language->name === 'default') { $alternate_languages .= "\n\t<link rel='alternate' hreflang='x-default' href='$url' />"; } else{ $alternate_languages .= "\n\t<link rel='alternate' hreflang='{$language->name}' href='$url' />"; } } echo $alternate_languages; ?>

Please check if the name of your german language is really "de", if not, please add it. I am not talking about the de name of the homepage, but the name of the language

Please show us the code that you use to generate the hreflang output.

Hey, sure, as I find the time. But could you please create an issue on github, so it is easier for me to track. PR's are also always welcome.

I am looking for an output strategy for repater fields or Repater Matrix fields (Pro fields) in my case. I would like to replicate the approach Ryan described in the blog post https://processwire.com/blog/posts/more-repeaters-repeater-matrix-and-new-field-rendering/ , but using Template Engine Factory (because I want to use Smarty or another template language). In short: Instead of a foreach loop that then uses many if clauses to distinguish the type, I would like to have a separate controller and template for each repeater matrix item. The controller should be used to modify the output before. Here is my working code, but I wonder if it might be better to use hooks like Template Engine Factory's hookBeforePageRender, or something else? //_init.php $factory = $this->modules->get('TemplateEngineFactory'); // check if the actual page has a modules_repeater (Repeater Matrix field) // and provide the output of the different modules as a variable if ($this->page->hasField('modules_repeater')) { // now get the output based on the type foreach ($this->page->modules_repeater as $module) { // Get the controller, to render a repeater item. $controller = $factory->controller("modules_controllers/{$module->type}.php", "modules/{$module->type}.tpl"); // You might pass some data via to the controller file, which you find at site/templates/modules_controller/nameOfTheRepeaterMatrixItem. // We assign the module repeater item to the $page variable so we can use it in our template and controller like this // $page->hero_headline $controller->page = $module; $controller->execute(); $output = $factory->render("modules/{$module->type}", ['page' => $module]); // Executing the controller renders the associated template via template engine. $this->view->set('modules_repeater', $output); } } Any suggestions?

@bernhard Is there a way to generate and insert content into a repeater matrix item via RockMigrations? First I generate the fields needed for the repeater matrix and add the repeater matrix field to a page. Then I want to create a new hero item on that page and insert some contents in it.

I try to setup a repeater matrix field. Can anybody like @aComAdi provide a working example, how to do this? EDIT: It turned out, that I needed version 5 of the RepeaterMatrix field.

ProcessJumplinks could be modified to use this. Don't know if @Mike Rockett is still working on v2?

Thanks. Great addition. It's like routes in Laravel. Much needed

That was my first thought

This could be because TracyDebugger loads Logfiles (by default?), namely Tracy Logs and ProcessWire Logs. If these files are large, it could take a while and make the site unresponsive. Try to disable them in Tracy's panel selector and see if that helps.

Please provide the code that you use. The error says, that it is trying to read the property of a null object. That means, that $my_page is not a page and therefore ProcessWire can't get the id of this page. If you have an id for the page do `$pages->get(insertIdHere)->trash();`

Thanks for all your work on the community requests. I would recommend to close issues/requests instead of adding the completed label for them (or does this label has some automation behind it?). The advantage of this is, that the list of issues get smaller and the issuer knows that the issue/request is fixed. Are you waiting for feedback for "completed" requests? If not, it's just fine to close the issue. If the OP has something to add he can still add a comment or reopen the issue. But thanks again for your efforts on this. I really feel like involving the community more, like you do now, can take take ProcessWire to new heights and make it even more one of the best CMS out there. Keep up the good work.

Your example pdf.php looks absolutely fine. Please try to save the PDF file via $pdf->save() or $pdf->download() and then take a look if the PDF is generated.

@Ralf Which error do you get? Does the page render correctly without using RockPDF?

I am willing to help with that. I also know the pains of npm, but also know (sometimes) how to tackle them.

Is this theme still under development @Noel Boss? There are issues from 2019. I really like the theme and think there could be some improvements made. But it only makes sense to contribute, if it is still maintained. Or else we have to fork it and work on an optimized version.

I think you should post this in processwire-requests, so we are able to vote for this feature and it does not get burried here in the forums.

@teppo I modified my post about the stale plugin. You can configure the label and if the issue should be closed automatically.

I also want to bring GitHub Apps - Stale to your attention @ryan. This bot adds a "stale" (or whatever you configured) label to all abandoned issues after a period of inactivity. After another period the issue is automatically closed (configurable). If a user or the original creator posts a comment, then the stale label is removed and the issue persists. Don't know if this is a good or a bad thing, but wanted to mention it.

That has to be me, because some/many other Open Source repositories handle requests this way, and thats how I have done it there. Let ProcessWires users decide, what is most important to them. Also the thumbsup/+1 is a better way to handle this instead of a "I also have this issue" comment, because else you would get nagged by the comments, and they provide no additional value. This is a good step to let the community know that their word and wishes also matter and they play a role in ProcessWire development. The README and issue/request templates should reflect this procedure.

The Page Lister (a centerpiece of PW) is also in need of major improvement IMHO. The icons are not always in the same place due to page titles of different lengths, which is very annoying and distracts a good workflow. A tabular representation or other optimized view, would be better suited here. Here, again, everyone may have a different preference, so an option of which display type to use would be a good idea. This has been mentioned here before. I would be willing to work on a proposal for an optimized layout. Moving entries in the page lister, doesn't work very well and it's cumbersome. I found a great Tree JavaScript a while ago that implements drag and drop much better http://www.treejs.cn/v3/demo.php#_307 and was actually going to work on integrating it to PW, but unfortunately didn't have enough time. The looks of that script can be completely customized. Then I didn't know if it was worth it, since I know that many PR's just never get integrated and I also lacked the time. I had made first attempts, but noticed that the PageLister is very extensive and nested.