Leaderboard

A huge shout out thank you to all the PW developers who have, and continue to help me.

The naming of the OR-groups is not correct. You only name OR-groups if there is more than one set of OR-groups and one group in each named set must match. Your selector here is saying that both (date<$start,date_end='') and (date<$start,date_end>=$start) must match which is impossible because these contradict each other. Wrong use of OR-group syntax with only one OR condition. Wrong use of pipe character. The pipe character can only go between field names in a selector clause... field_a|field_b~=foo ...or between values in a selector clause... field_a%=foo|bar

Here are links for a few different approaches to the general question: https://github.com/LostKobrakai/Paginator https://gist.github.com/somatonic/5420536 https://processwire.com/talk/topic/5558-adding-pagination-after-merging-two-pagearrays/?do=findComment&amp;comment=54122 And my own suggestion: // Find all the matches, but only find the IDs to reduce memory overhead $matchest = $pages->findIDs("title~=$q, template=BN-article|BN-infopage"); $matchest_str = implode('|', $matchest); $matchesb = $pages->findIDs("body~=$q, template=BN-article|BN-infopage, id!=$matchest_str"); $match_ids = array_merge($matchest, $matchesb); // Define some pagination settings $items_per_page = 10; $start = ($input->pageNum - 1) * $items_per_page; $total = count($match_ids); // Get the IDs for this page of the pagination $item_ids = array_slice($match_ids, $start, $items_per_page); // Get the pages using the IDs $items = $pages->getById($item_ids); // Apply the pagination settings to the pager $items->setTotal($total); $items->setLimit($items_per_page); $items->setStart($start); // Output the items as needed foreach($items as $item) { echo "{$item->title}<br>"; } // Output the pager echo $items->renderPager();

To see all the places where a particular method is called by the core you would need to search the core code. In the case of Fieldtype::getInputfield the most significant places are in Field::getInputfield, which returns the inputfield according to the fieldtype of that field, which in turn is called by Fieldgroup::getPageInputfields, which loops through all the fields that belong to a fieldgroup (you can think of a fieldgroup as being sort of the same as the template) to get and populate their inputfields so they can be displayed in Page Edit (for instance). But you probably don't need to spend time working through all of that in order to successfully create a Fieldtype module. An important thing to understand if you don't already is that your Fieldtype module extends the Fieldtype class. This is called Object Inheritance: http://php.net/manual/en/language.oop5.inheritance.php So all the methods in the Fieldtype class also belong to your module, and the code for those methods is what you see in Fieldtype.php unless you override the method by including it in your module. To illustrate with an example, we can see that Fieldtype::getBlankValue returns an empty string: https://github.com/processwire/processwire/blob/cbfe97de207e3166451f16865429c02c081791e8/wire/core/Fieldtype.php#L494 If we look at FieldtypeText we see that it doesn't include a getBlankValue() method - it doesn't need to because the getBlankValue() method of Fieldtype already returns the right value for a blank text field. But if we look at FieldtypeCheckbox we see it does include a getBlankValue() method - that's because an empty string isn't the right type of value for a blank (unchecked) checkbox, so it implements its own method to return 0.

Hi Brian, I wrote a tutorial about this some time ago: It's not complete and building Fieldtypes is not that easy... One important note: "Fieldtype" = the field, including all logic to save the value to the database, store it, etc "Inputfield" = the inputfield that is shown to the user (the UI) Often it is easier to modify an existing Inputfield or extend/modify one via hooks. You can see my first module for an example: Don't have more time right now, but maybe this already helps a little ?

Thank you for pointing this out. Very new to all this. Will be more cautious and take the time to, as much as I can, read most of the thread before posting. No bad intentions here. I guess I am still under shock for what happened with WP and Gutenberg, saw the title and felt it would be good to voice my concern before things get going. Thank you indeed.

Not sure, but I think lower case is specified.

We are using the included in PW jQueryUI drag, drop, sorter.

It's jQuery UI! And the sidepanel is just an animated div, nothing fancy really.

Excellent. Do you mean a native/ProcessWire core way to output JSON data from the databse through the use of a then native REST api that is called with vanilla JS? That is, as far as I can see from being about 48h into ProcessWire, the only thing I could not find. But again I found modules that do this, so perhaps leave it in modules? it would somehow be very cool though to have core team approved modules that work with the Basic site profile so devs new to this can build from there and learn. Is there a core dev team or is Ryan the one and only being able to commit to ProcessWire? I agree though in a certain way. There are devs that work per client requirements and then there are web designers that just want a page-builder to be able to sell websites/themes that then clients might buy without having to hire a dev while also wanting to use ProcessWire. I guess for the later such a page-builder would come in very handy. I am raised with the "build it yourself" frame of mind, sure not re-inventing the wheel, though the satisfaction of knowing what source will be produced is very important to me, especially knowing where the source code comes from, meaning what in the end is responsible for each line of code that the browser gets to render. But.. given a module would be made that enables devs to output clean code without having to load external libs into the frontend while also being an advantage to devs in the sense that snippets/blocks of code/content sections could be easily dropped and dragged in the backend, well I would at least give it a shot, given it is clean and does not interfere with ProcessWire, meaning if you remove such a module the database and source code produce the same result in the frontend. Quality content is kind. There is tons of well designed websites with plain bad content. I don't see Gutenberg being user friendly or a real thing to look at as a reference for what could be useful for ProcessWire in terms of SPA editing. My experience with Gutenberg was that is made me feel that the entire dashboard has become very brittle on a psychological level, meaning, you click, it shows up, but if it really is saved and will work is a different matter. Often the preview would not render anything, blank page. At least for me, opening and saving things one after another makes me feel much more in control, knowing what why when and where code will be in the frontend. But this is just personal preference. I guess I like things clean, working and working well. Bottom line, I do not find the idea bad per se, I just think something like this requires a lot of thought and careful use case consideration before any code is written, i.e. who would benefit most from such a SPA editing module and what would be the implications for ProcessWire. I say let's first get that JS api going if I understood you correctly that that is/was on the roadmap.

@tiefenbacher_bluetomato Here is an example script from my migration. Note that I did not use MarkupSeo, in my case I had two fields "seoTitle" and "seoDescription". I highly recommend using the migrations module to execute such logic. $pages = $this->wire('pages')->findMany("seoTitle|seoDescription!='',include=all"); foreach ($pages as $page) { if (!$page->hasField('seo')) { continue; } $page->of(false); foreach ($this->wire('languages') as $language) { $this->wire('user')->language = $language; $title = $page->seoTitle->getLanguageValue($language); $desc = $page->seoDescription->getLanguageValue($language); $page->seo->meta->title = $title ?: 'inherit'; $page->seo->meta->description = $desc ?: 'inherit'; } $page->save(); }

This. Please read this before you post. Not a single person here has, to my best understanding, suggested that there should be a page builder in the core. This very topic is in the Modules/Plugins development area of the forum. This topic is not about the ProcessWire core. Thank you ?

Nobody's talking about bringing content builder stuff to the core. I guess only Ryan could)) But the request for content building is high. Content is king. And RepeaterMatrix + Hanna codes are not as user friendly as Gutenberg seem to be. SPA editing is way more pleasant than opening and saving things one after another and adding images only after 1st save. PageTable Extended showed a way true block editing could be done in PW. Frontend editing is another step that could revolutionize content editing, but I never read about any good implementation. RepeaterMatrix is cool and could be even better if it would be PageTableMatrix with a similar Inputfield))) I think we can and should find a way to solve this need in true ProcessWire way. And we have to look at competition. Gutenberg might be hard and messy for developers, but it is desirable for end users. Let's make good for both using our strong points. P.S. js page api was on the roadmap. Might be a good fit here once it's done.

Or too much whisky last night...? I tend to do all my personal coding in the little hours with something to drink ?

If this is the case then I'm a total idiot. Thanks!

Maybe an extension like this can also help: https://chrome.google.com/webstore/detail/redirect-path/aomidfkchockcldhbkggjokdkkebmdll

By default regular expressions are case sensitive and in the message only a-z is displayed and I guess Ryan wanted to make sure there can be no issues with these filenames when writing to a case sensitive filesystem.

Longtime WP user. Came here to escape the madness that is Gutenberg. Please, for love of ProcessWire, do not include any such editor crap inside core. People can do so via modules or even admin themes but keep PW clean, neat, tight, free and fresh from such nonsense. Just learned about ProcessWire a couple days ago at a JS workshop/conference. Reading the docs, doing first examples and totally in love with it all. Keep it that way please. Regarding Gutenberg. Not only do you need to know React deeply, no also JS and a lot of it and deeply also, then you get to work with a "the WP way" version of React to build things. With Gutenberg WP has set the bar to entry into the WP world way above average, all the hobby coders that could easily make a WP site given a month of learning are now facing a very steep and intense learning curve. This will surly show going forward. This is what got WP off the ground in the first place. Ease of use and also ease of getting a site done. This has changed. Kids these days want to see results, fast. Sure if you don't care about PageSpeed or WebPageTest, just need a page-builder, plaster external libs all over the source, go ahead, if that is your game, and if that is what you unknowing client pays for, the sure, yes, use WP and Gutenberg exactly for this kind of crap. But if you really do care about all these things and want to make a good site that performs well where the client can have multiple custom blocks showing in the frontend, then you are going to have to invest a lot of time learning JS and React and "the WP way of React". Not something I see any entry level coder feeling up to. For example Just go ahead and make a responsive image block, and I don't mean just the img tag but something more like this. https://dev.opera.com/articles/responsive-images/ Asked around many frequented channels, senior and seasoned devs could not come up with something that produces usable source code. One guy had a solution, asked him if he could show the code "sorry, no, we have a team of devs working on that in our agency and cannot show it publicly". Go figure. A whole team of devs at an agency for a responsive image block to work in WP. Well done Matt and super smooth more there Mark, slipping React into WP that way. A good colleague that has been using WP all his life and knows PHP inside out tells me "I am going to stay away from Gutenberg for as long as I can". By your means, feel free and make a module, load the editor of your choice, give the client what you think they need or want, but do all this strictly kept away from the beautiful, clean and nice source that is ProcessWire. Given the WP mess I am sure there will be more and more people going to use ProcessWire in the future. I plan to speak publicly about ProcessWire at a conf as well as hold workshops, I am that much convinced about it. I would not even go this way if I would have discovered any dependencies on external libs or any such page-builder crap that now WP has built in. And now back to the docs and examples. It is such a pleasure. ProcessWire.

Thank you @szabesz - the thread you linked to was perfect, I don't know how I missed it in my search of the Processwire forums for the word "search" ? . Oops. Yes, my situation is a simple case of the one you linked to - just what I needed. Thank you @Robin S for the response here and in that thread - the info was very valuable. I've tried it out on my site and it's working perfectly!! ? Thank you both.? Now I'm just trying to figure out how to use the Limit selector on the resultant array (for pagination). But thankfully the main thing is that now it's giving the results I want in the correct order.

The key thing is to make sure $matchesb does not contain any of the pages in $matchest - otherwise the order will not be what you expect when you join the PageArrays together. So you could use removeItems() as per my reply in the thread @szabesz linked to, or you could exclude the $matchest items in the selector for $matchesb: $matchest = $pages->find("title~=$q, template=BN-article|BN-infopage"); $matchesb = $pages->find("body~=$q, template=BN-article|BN-infopage, id!=$matchest"); $entries = $matchest->and($matchesb);

Try in incognito mode to make sure your browser is not caching old redirects. You could also use the "What other URLs redirect to this page?" section (introduced in PW 3.0.118) and/or the modules below to look for any circular redirects (if such a thing is possible with Page Path History). This second module needs the PagePaths module installed and also needs a variable name fixed as per a reply in the support topic.

Hi @Elchin I got them in the past but the query was to slow so I finally used a custom query to achieve that, you might be interested as I don't know the number of pages your trying to fetch - I give you a small module which could be extended, shipped with a hook function which return all pages between two dates given a fieldname and a template id :

hmmm...was easier than i thought however, if someone wants to do it: here is a good how-to by Ryan: @Autofahrn you were right. makes more sense by json. it's also way faster ?

ok, somehow mixed up that this.attr, doesn't work... To access individual fields and don't want to use JSON (any reason for that), you may inject that into your DOM tree and access relative to the parent element. That way you: - combine discrete information into some markup - deal with proper escapement of special chars etc. - send that markup to client - client needs to parse markup to retrieve discrete information (and decode handling of special chars) Using the JSON version is much more straight forward, scalable and takes care of most aspects of proper data escapement.

Not being updated that long time may indicate something stable... ? I'm using Ryan's LoginRegister module for member registration: https://modules.processwire.com/modules/login-register/ You may create forms in a variety of ways, depending on your needs. FormBuilder is basically a wrapper around existing fields to handle the form submission like sending mails, storing form data into database or even into pages. Without FormBuilder you'll have to do this on your own. Either still using existing fields and process their input or using native HTML markup. This basically depends on what you like to provide to your users. If its pure text input, you may want to go with plain vanilla html. If you intend to provide something more complex like rich text editor, using existing fields is probably easier to handle.

Hi @Brian Peat, that line fails if a template doesn't have a name I was wrong, it's the editedPage being null, will add a check.

Here's @Robin S code adapted to produce the following thumbnail navigation (semi-transparent thumb #98 is the current one): <?php // Number of thumbs to show $limit = 9; // Get the number of visible siblings $num_siblings = $page->parent->numChildren(true); // The default start value is zero $start = 0; // If the number of siblings is greater than the limit then we need to adjust the start value if($num_siblings > $limit) { // Get the halfway point of the limit $half_limit = floor($limit / 2); // Get the index of the current page relative to its siblings $index = $page->index(); // Adjust the start value to keep the current page within the sibling links if($index > $half_limit) $start = $index - $half_limit; if($num_siblings - $start < $limit) $start = $num_siblings - $limit; } $items = $page->siblings("start=$start, limit=$limit"); // Next page and previous page relative to current page $next_page = $page->next(); $prev_page = $page->prev(); // Next and previous SVG icons $left_arrow = "<svg role='img' aria-labelledby='previous-icon' class='icon icon--inline' height='24' width='24'><title id='previous-icon'>Next photo: {$page->prev->title}</title><use xlink:href='#icon--left-arrow'></use></svg>"; $right_arrow = "<svg role='img' aria-labelledby='next-icon' class='icon icon--inline' height='24' width='24'><title id='next-icon'>Previous photo: {$page->next->title}</title><use xlink:href='#icon--right-arrow'></use></svg>"; ?> <?php if($items->count > 1): echo "<div class='thumb_gallery'>"; if ($prev_page->id) echo "<a class='thumbnail' href='$prev_page->url'>$left_arrow</a>"; foreach($items as $item): $number = $item->index() + 1; $current = null; if ($item == $page) $current = " aria-current='page'"; echo "<a$current class='thumbnail' href='$item->url'>"; echo "<img class='responsive-images thumbnail__image' src='{$item->photo->size(150,150)->url}' width='75' height='75' alt=''>"; echo "<span class='thumbnail__label'>$number</span>"; echo "</a>"; endforeach; if($next_page->id) echo "<a class='thumbnail' href='$next_page->url'>$right_arrow</a>"; echo "</div>"; endif; ?> I hope this can help someone else. Thanks again @Robin S !!

@horst I'm up to date as far as I know. It's running 2.0.15. I may edit my hosts file so I can see their old site again and check in there. It's possible they've been ignoring the errors for a while, but I'm not sure. Thanks!

In case anyone else has this issue with the ajax calendar disappearing when clicking on the prev/next month. My issue was the recurme-ajax template was prepending _init.php and appending _main.php files. Disabling the prepend and append under the template files tab was the fix. @adrian Thanks for digging in and discovering the cause.

yeah! thx @Autofahrn my mistake. i had a variable defined in my header.inc which was missing!

Did you check the PW logs (Setup->Logs->Errors)? Error 500 happens on server side not inside your JS code.

try: $(".button").click(function(event) { event.preventDefault(); // No default action

Did you check your error log for a more comprehensive analysis? Apart from the error: $("#date").html("<p>Loading...</p>"); should probably refer to #data and your template code should probably only return the part "// some images", otherwise you'll nest a new section for each button click. I case you intend to do more dynamic updates, returning a JSON instead of pure HTML may be an option:

Yes, a fellow agency showed me the huge performance gain, going to get an unlimited license pretty soon. ProCache rocks hard full stop. Nevertheless running ProcessWire production ready with NGINX in a Docker container each with their own process ID where you just drop the site source into it and deploy is something I will also definitely try and get going. But that is left for another day.

Does anyone know how I could edit the title of this thread to "SOLVED - Default Multi-language Install Not Working With Devilbox"? If a mod or someone with enough permissions reads this, kindly edit the title like this, thank you.

Totally agree. Keep ProcessWire clean and do what you like to do in the backend. Having a default editor that all new devs/clients must use would ruin ProcessWire for good. More a fan of "build it yourself, nice and clean" than "click and drag it yourself" .. and be left with a mess of badly performing source code full of external libs etc.

I don't think that implementing another framework would be the way to go. I think we already have a great framework for editing our content: ProcessWire (the backend, meaning ProcessPageEdit). We have a great ecosystem with our fieldtypes and inputfields. It would take huge effort to rebuild all this on another framework (like grapejs). My approach would be to keep all blocks as pages with all the benefits we get from it (setting templates, having access control, etc). Those blocks could easily be edited right away in the backend, as they are pages. Just append ?modal=1 and you have exactly what you need: A UI to edit your block. No extra work, no breaking updates etc. Repeater and Repeater Matrix already show that this is possible. It would just need a new inputfield where we can drag&drop, copy, remove, create those blocks. @joshuag and @elabx have already shown that this kind of magic can be done in the pw backend: https://processwire.com/talk/topic/19557-designme-visually-layout-your-edit-screens-preview/ @joshuag and @elabx which library are you using for this drag&drop magic and also for the side panel?

Thank you @Robin S very much.

@Elchin, try: $results = $page->children("date<today, (date_end>today), (date_end=''), sort=-date, limit=12"); You can use "today" in place of your timestamp.

Hi everyone, I'd really appreciate some comments of support on this Github issue: https://github.com/processwire/processwire-issues/issues/829 It really messes with Tracy's bluescreen stack trace. Thanks! PS - Thanks to @bernhard and David Grudl over at Nette for figuring out what was going on.

Sure, I will keep an eye on the core and merge your PR as soon as Ryan adds support for it. It's actually not that much more comprehensive. ? The only additions are the macronised vowels (āēīōū), which is something I wanted for my New Zealand context because they are used in Maori. The difference is that the list includes uppercase versions of the characters. I simply took the character list from InputfieldPageName, added the macronised vowels, and ran it through mb_strtoupper(). Adding uppercase characters to InputfieldPageName wouldn't make sense because page names are forced to lowercase. I had in mind that this sanitizer could be used for broader purposes besides converting characters to ASCII. Using the character replacements from InputfieldPageName seemed like a good starting point (particularly given the question that gave rise to the module) but a person could configure all kinds of replacements to suit their needs. There could well be cases where these substitutions would not be wanted in InputfieldPageName.

There is something similar posted over here if I'm not mistaken: Does this help?

Thank you Ryan for this information! What about all the open PR's? There are at the moment 50 of them open, some going back to 2016... Could @netcarver maybe also have an eye on them? Or do you prefer that we report feature requests also via the issues repository? thx ? PS: @kongondo recently shared how vscode integrates with pull requests. Don't know how PHPStorm handles this, but maybe VSCode can help checking all those open PRs:

Hello @kongondo I have implemented some changes to the navbar/menu: If you like it I can make a PR. What do you think?

Glad you like the updates! Hope I didn't give the wrong impression, as I didn't intend to communicate anything about a "feature freeze" (as was stated in one of the messages above). At least nothing like that was, is, or ever will be planned, except maybe for a few days prior to a master version release. This is a stable project, but not a static one. There is no freezing or thawing, just the flow—I'll try to clarify... ProcessWire was originally built out of the needs of web development projects here, and that has always been a significant driver of what and when features are focused on at any point in time. When I add or improve something, it's usually because I'm going to be using it now and always going forward in actual projects, and by extension, can also support it in this project for everyone else. Of course, I only add/improve stuff that I know has significant benefit for all PW users, regardless of whether it's recognized in the short term or not. The other major part is features that arise from needs or contributions in the community here and on GitHub. My client projects are pretty similar to those of most PW users, which is good for the project. I'm always looking for ways to optimize and improve PW and its API, especially things that will save time in my and your projects, and this has always been the case. I'm driven by it. The feature focus is always holistic and never sacrifices backwards compatibility. And the product focus is on long term quality and sustainability, being the best tool for the job, not on being popular. The focus may largely be on issue reports right now, but this should not be interpreted to mean anything beyond resolving issue reports. I'm making continuous improvements and additions where appropriate along the way, as always. Perhaps they aren't big enough things to warrant blog posts now, but stay tuned — there is lots of good stuff on the way and currently in development. Every year there are a couple of important periods of good momentum in the issues repo, especially this time around, and so I'd like to continue that as long as possible and hopefully cover everything there. The difference this time is that we've got Netcarver expertly leading the effort as well as intelligently identifying which reports are still relevant. Plus there are a whole lot more "includes suggested fix" reports this time, thanks to people like Toutouwai and many others that know their way around the core extremely well, and often figure out how to resolve issues well before I do. It's a great community collaboration.

I created this module a while ago and never got around to publicising it, but it has been outed in the latest PW Weekly so here goes the support thread... Unique Image Variations Ensures that all ImageSizer options and focus settings affect image variation filenames. Background When using methods that produce image variations such as Pageimage::size(), ProcessWire includes some of the ImageSizer settings (height, width, cropping location, etc) in the variation filename. This is useful so that if you change these settings in your size() call a new variation is generated and you see this variation on the front-end. However, ProcessWire does not include several of the other ImageSizer settings in the variation filename: upscaling cropping, when set to false or a blank string interlace sharpening quality hidpi quality focus (whether any saved focus area for an image should affect cropping) focus data (the top/left/zoom data for the focus area) This means that if you change any of these settings, either in $config->imageSizerOptions or in an $options array passed to a method like size(), and you already have variations at the requested size/crop, then ProcessWire will not create new variations and will continue to serve the old variations. In other words you won't see the effect of your changed ImageSizer options on the front-end until you delete the old variations. Features The Unique Image Variations module ensures that any changes to ImageSizer options and any changes to the focus area made in Page Edit are reflected in the variation filename, so new variations will always be generated and displayed on the front-end. Installation Install the Unique Image Variations module. In the module config, set the ImageSizer options that you want to include in image variation filenames. Warnings Installing the module (and keeping one or more of the options selected in the module config) will cause all existing image variations to be regenerated the next time they are requested. If you have an existing website with a large number of images you may not want the performance impact of that. The module is perhaps best suited to new sites where image variations have not yet been generated. Similarly, if you change the module config settings on an existing site then all image variations will be regenerated the next time they are requested. If you think you might want to change an ImageSizer option in the future (I'm thinking here primarily of options such as interlace that are typically set in $config->imageSizerOptions) and would not want that change to cause existing image variations to be regenerated then best to not include that option in the module config after you first install the module. https://github.com/Toutouwai/UniqueImageVariations https://modules.processwire.com/modules/unique-image-variations/

I still really like this solution:

I'd really question why you don't want to use plain old sessions. I mean it doesn't have to be cookie-based even if that's imho still the easiest way to not get bitten by compromised sessions. To give my argumentation a bit more ground work you might want to look into the following blogposts. The latter has a quite simple flow-chart about why JWT just doesn't work well for session authentication. http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-for-sessions/ http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/ There's also oauth, but that's mostly just another way to obtain a "session" with an service, where you allow a third party to access your content without giving away your credentials.

Hi @enrico, There is already a front end login/user registration module https://github.com/ryancramerdesign/LoginRegister As far as front-end content editing, you could use https://processwire.com/api/modules/front-end-editing/ Hope this helps Rudy

Here's a short snippet for site/ready.php that hooks after ProcessPageEdit::buildForm and moves a regular field (named "testfield here") from the Content tab to Settings. The methods used are from the InputfieldWrapper class. <?php wire()->addHookAfter("ProcessPageEdit::buildForm", null, "moveFieldToSettings"); function moveFieldToSettings(HookEvent $event) { $form = $event->return; $field = $form->find("name=testfield")->first(); if($field) { $settings = $form->find("id=ProcessPageEditSettings")->first(); // Alternatively, find a specific field to insert before/after: // $settings = $form->find("name=template")->first(); if($settings) { $form->remove($field); $settings->append($field); // In the alternative, insert before or after the found field: // $form->insertBefore($field, $settings); } } }