dotnetic

@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.

One of the things that bothers me about ProcessWire is the integration of the community into the development process. It is not clear which features or ideas will be implemented and if and how you can influence this decision at all. For example, it would be conceivable that within a period (for example a quarter) you look at which Github issues have the most thumbsup and then fix or implement them. If there are too many features, or they have the same number of thumbsups, you could also make a poll in the forum, what the community would like to have implemented faster. The pull requests sometimes are not integrated for years. Even if a control or a rewrite would be necessary for this, it would be good to have a feedback if the PR is "under consideration" or "won't merge" or "working on it" or a comment. Because the way it is now, it seems like the PRs are just decaying unseen and there is no point in working on this open source project. Ryan wrote: My preference is always that we talk about the PR before someone takes the time to code and submit one, so that we are on the same page about the goals and timeline for it, and getting all the details right. PR's that come in unsolicited are fine too, but they do take me a lot longer to get through. It would be nice if this was also listed in the Contribution Guidelines https://github.com/processwire/processwire-issues/blob/master/CONTRIBUTING.md These guidelines are also the place to say how new ideas or fixes are handled and under what conditions they are integrated. If Ryan discloses his criteria that he has as a requirement for features, enough developers might follow those guidelines when creating a PR. After all, it would be great if there were a few selected contributors and they could then merge PRs, or at least do a pre-review, so that Ryan has an easier time integrating them later.

Wow. So many great input here, but instead of making one large post, I split this up to multiple ones, so I can talk about more features and wishes specifically. While cool no doubt, this is where I get into more of a grey area as to whether ProcessWire should be involved in this sort of thing at all. It just seems it steps maybe too much outside the scope of content management. Yes, this makes sense. This is what I liked about that editor.js option, as it seems like (combined with its plugins) it's already a clean system for doing this. Interested to hear of others think this approach would be a good path to take. I had the idea to implement editor.js some years ago (but did not done it yet), and think it would be a great addition to ProcessWire, because building blocks are something requested by one large client of me. He now has the ability to add content blocks with Repeater Matrix, but I think its cumbersome and not very intuitive, and has its drawbacks. That is the same for every page builder and content block solution, that I have seen here on the forums except FieldtypeEditorJs. Everything in my opinion and please don't feel offended. Editor.js and the Bard fieldtype from Statamic (which is extended in V3 of Statamic, Bard is based on ProseMirror) are very good, because they save content not in HTML (but you can, If you want to) , but as structured data, which then can be rendered via partials however you like (that's how I do it in Statamic). As an explanation you can read my post The FieldtypeEditorJs : Preview of a productivity fiedltype for editors. - Module/Plugin Development - ProcessWire Support Forums is a first good looking implementation of this fieldtype, but is not released yet. Maybe you can talk to @flydev ?? about integrating it into the core. I think there would be enough people to sponsor this feature. I do not think, that we need another website page builder which is responsible for the whole layout. Block based contents would be enough in my opinion. But that's just my two cents and I know, that opinions might differ on this.

Hey @flydev ??. Now that half a year has passed, any news ? A release date? Will this fieldtype be free or paid?