Leaderboard

@Ivan Gretsky Hooks have already been added for this, and I think they were present in the dev version I posted in the ProFields board a few months back? I don't remember for sure, but I'm trying to make everything hookable so that people can modify the output as needed, and will keep looking for additional opportunities for that as I build in more related features. @teppo Yes there's a renderAddMatrixItemLink() hookable method for this, and it renders a link for one matrix item type, and gets called for each of them. So you could change the output to be anything you want. This is already present, but with the changes being made, chances are another hookable method will be added related to this. @Pete If I understand correctly, this is already there. See the "Matrix types to allow for adding new items" on the "Input" tab when editing your matrix field. This can be configured in template context which enables you to specify some types for one template and other types for another, etc. @mlfct Thanks, I was able to reproduce that here too and have pushed a fix on the dev branch.

v0.0.3 saves database value in terms of base units. Selector fieldname.magnitude then operates consistently regardless of what units are chosen - selecting values in terms of base units. Thanks for the tip @kongondo

EDIT: ************* Note that this OP relates to the original version of the module. Version 0.0.19 is now published to the modules library at https://processwire.com/modules/fieldtype-measurement/. As well as many bug fixes and small enhancements, it now also includes an 'in-field' interactive conversion feature and dependent-select in the config. See the readme on the module page for up-to-date details and see this post for a bit of a demo. ************* This fieldtype and inputfield bundle was built for storing measurement values within a field, rendering them in a variety of formats and converting them to other units or otherwise modifying them via the API. The API consists of a number of predefined functions, some of which include... render() for rendering the measurement object, valueAs() for converting the value to another unit value, convertTo() for converting the whole measurement object to different units, and add() and subtract() for for modifying the stored value by the value (converted as required) in another measurement. In the admin the inputfield includes a checkbox (which can be optionally disabled) for converting values on page save. For an example if a value was typed in as centimeters, the unit was changed to metres, and the page saved with this checkbox selected, said value would be automatically converted so that e.g. 170 cm becomes 1.7 m. A simple length field using Fieldtype Measurement and Inputfield Measurement. Combination units (e.g. feet and inches) are also supported. Please note that this module is 'proof of concept' at the moment - there are limited units available and quite a lot of code tidying to do. More units will be added shortly. See the GitHub at https://github.com/MetaTunes/FieldtypeMeasurement for full details and updates.

As @Jan Romero wrote, its more often than not that a link's textual information is generated dynamically from its relationship (e.g. the page/template it's on or that's referenced). For manual entry of link texts, creating separate fields for the link target and the text like you did is the way to go. You can, however, make your developer life easier when you have multiple occurrences of that combination in different templates by wrapping both in another field type. This can be a Repeater if you have multiple entries, or for a single one you can use either FieldsetPage or FieldsetGroup, depending on whether you want the link entry to live under a unique property of your page. With fieldsetgroup it is $page->urlfield and $page->linktextfield, while in fieldsetpage its $page->myfieldsetpagefield->urlfield and $page->myfieldsetpagefield->linktextfield. The former is more performant, while the latter makes it more clear that both fields are related.

Free access to Flutter Apprentice from October 6, 2021 through January 6, 2022. https://flutter.dev/apprentice-giveaway

It took a little more time this week to wrap up what I was finishing last week (and the week[s] before). But I think it's now at a good spot to move on to something else, and so I started with some Repeater and RepeaterMatrix updates. In Repeater, a new feature was added that's been requested for awhile: the ability to add items anywhere you choose. Previously you could do it only by adding items to the bottom, and then drag them in place. Now you can click insert before/after [icons] in each repeater item header and it will add the new item in place. It is also depth-aware. This is something that I think will also be useful especially for people using repeaters for page builder type contexts. (Note: the feature does not [yet] work if you have all Ajax features turned OFF in your repeater settings). There's a GIF screencast below that shows you how it works. You can click the "insert before" or "insert after" actions and it inserts a new item in place. Alternatively, if you hover either action for a second, it'll show you where it's going to insert an item and you can click either the the item, or the action, to complete the insertion. There's still likely some optimizations and improvements to make in the JS here but so far it seems to be working well. (I made this as a GIF but for some reason IP.Board won't accept it, so here's a YouTube embed instead): Everything in Repeater also gets inherited by RepeaterMatrix, so you'll find this feature there too. But it's not fully functional there just yet. That's because RepeaterMatrix items also have a "type", so I'm working on a new version of RepeaterMatrix that lets you select a type once you've chosen where to insert the item. Another related feature in progress in RepeaterMatrix at the same time is a dropdown/select option for choosing what matrix type you want to add for items. This is an alternative to the current list of links that appears at the bottom. The dropdown also gives you the option of having groups of related types. More on that soon, potentially next week. Thanks for reading and have a great weekend.

If I remember right, in such cases I use a URL field for external URLs and a page select field for internal (multilanguage) links. If the URL field is empty, the page select field is shown, if a (external) URL is given, the page select field is hidden (showIf). (In the notes of the URL field is a hint that clearing the field will show the internal page select field). In template files I first check if there is given a URL or if that is field empty, and according to that I display external or internal URL.

Hi @gregory. Session or cookies.

Hi @ryan, thank you for the update! Don't know, if i should rather open a dedicated thread for that, but as it is related to the .186 update: I am running into some issues with the new "page not available in language" feature. Whilst the normal 404 is working, the 301/302 redirect option throws an error (at least for my current multilingual pw project) I could just trace it back to the newly introduced ___pageNotAvailableInLanguage in LanguageSupportPageNames.module. Tbh. as my PHP skills are still kind of lacking, i am not sure, if it is related to my setup or something more general.

Usually when you use a page reference or URL field, you do so to model a specific relationship. That way it is often sufficient to have a fixed link text describing that relationship, or to generate it based on the target page. For example, links might always just say “more info” or “related: <?=$page_reference->title?>”, or the domain name extracted from a URL field. If you want arbitrary link text that is editable by users, your solution seems perfectly fine.

Hey @Pete! You can limit types by template out of the box - look at the template overrides. There is a nice module by @Robin S that can do more than that. Is you need to restrict in part of the page tree, you will need to reach for hooks. You can look at the ones Robin uses in his module.

@MrSnoozles thanks for your kind words. Yeah my main intent is to handle ProcessWire in a sane way with current "best-practices" in PHP Userland. Which includes things like Composer all the way Dependency Injection Migrations!!! Separation of concerns (hello Twig for example) proper Headless Content distribution Nice, I had the exact same thoughts so far ? I really like ProcessWire and it is my first go to whenever I need a MVP or an Prototype. But in the long run, or whenever I have more than 1 Developer working on the code the nightmare begins, atleast for me. I really dont know ? The main problem is the way ProcessWire is organized, as it was never intended to be used as Dependency in another Project. So yeah, right now, whenever @ryan is in production mode and pushes new Versions I have to manually update the codebase. The thing is, I started to develop Symprowire because I had a Prototype in ProcessWire which acted as a Proof of Concept for some client presentations. To develop the concept and bring it to production ProcessWire just wasnt enough, I learned it the hard way ? *cough* migrations *cough cough* So in the course of 1 1/2 year I ported the PoC to Laravel with the intent to use Laravel Spark as our Product is a SaaS with fully fledged Multi-tenancy. Unfortunatly Laravel Spark wasnt that good of a solution back in the days as it was too opinionated and the general direction Laravel as a Framework is developed... mhhh I would say is not my cup of tea. So I started to port over to Symfony as we worked with Symfony some years ago to develop a Marketplace supporting 72 Languages and had ~ 350 active sellers from the beginning. I would say it was a fairly big project and I felt confident to work with the Framework, but I missed ProcessWire's CMS/CMF possibilites which ultimatly brings us to Symprowire. As of today, we ditched ProcessWire completly from our Product and went full ham with Symfony as we are using symfony/notifier for async notifications symfony/messenger for RabbitMQ api platform for our headless needs and all the bits and pieces symfony brings To give you an idea, I just published a basic Fullstack Template covering all our needs. You can find it here: https://github.com/Luis85/symfony-full-skeleton Right now, I really dont know how to develop Symprowire or in which direction I would like to go with the Project. I have a lot of Ideas but every idea would be a complete refactor. I thought something like, yeah just copy the Data Modell ProcessWire uses and port it to Symfony to make a new CMS based on Symfony with the spirit of ProcessWire. I really dont know right now ? What I know is, I want to contribute to ProcessWire.

My question relates to one of my live sites. I empirically managed to solve my login issue of "This request was aborted because it appears to be forged" [details below], but I don't understand the inner workings of PW, so I don't understand the theory behind why/how I fixed it, and thus, I don't know if I've managed to inadvertently introduce a security issue/loophole. Would anyone please be willing to let me know if my change, moving forward, is likely to cause any such issues? I don't have any reason to believe I *do* have a security issue (I made my change only an hour ago) but I am hoping other users can weigh in on this. DETAILS: The problem: Yesterday I updated 2 of my sites from 3.0.165 to 3.0.184 from within PW admin page, using the upgrade module - this is the way I've always done it. Immediately afterword, both sites appeared to be working fine from front-end and admin, and I even wrote and saved an (unpublished) article in what would become the problem site, then I logged out. Unfortunately, this morning, although both sites were fine from front-end, I could not log into the admin area of the problem site, getting "This request was aborted because it appears to be forged". The other site was fine and I could log into that. The solution: Since both my sites were on the same web host and had a lot of similarities, this was actually incredibly helpful as it let me narrow down where the issue might be. I won't go into everything that *didn't* work (although I noted it all down at the time so I have it if anyone asks for it), EXCEPT for 1 thing that might turn out to be relevant: the "good" site had site/config.php perms of 0644, and the "problem" site had perms of 0400. I tried changing the problem site perms to 0644 but that didn't fix the issue, so then I changed it to 0600 so I could at least write to it (e.g. to change $debug to true, etc). By comparing the contents of the 2 site/config.php files, I was able to narrow down the difference (this was AFTER ruling out a bunch of other things that I won't go into here). The difference is that the problem site had these extra lines which were absent in the good site: $config->sessionAllow = function($session) { // if there is a session cookie, a session is likely already in use so keep it going if($session->hasCookie()) return true; // if URL is an admin URL, allow session if(strpos($_SERVER['REQUEST_URI'], $session->config->urls->admin) === 0) return true; // otherwise disallow session return false; }; I commented out those lines and afterwards everything worked and I could log back into the admin area of the problem site. So, problem fixed, yay!! But - WHY were those lines there in the first place? They must have been from an older version of PW that I was running in the past. So they must have been doing SOMETHING, so have I caused a security issue in deleting them? Any advice you have about that would be very helpful. And also, was it therefore a bad idea to have my site/config.php perms on 0400? They're on 0600 right now on that site in case future PW upgrades need to change config.php. I thought 0400 was 'good' based on https://processwire.com/docs/security/file-permissions/#potential-permissions-for-site-config.php but perhaps I should have done 0600. Thank you for reading this and for any insight you can provide.

@Rob(AU), glad to hear you've got something working. Something to think about though: seeing as each portfolio page may have multiple tags, what happens if a user opens a portfolio page in a new tab via "tag=foo" and then the same portfolio page in a different tab via "tag=bar"? You only have a single session variable for the tagged pages so these will overwrite each other, and the portfolio page doesn't "know" which tag it is being viewed under. I think it would be better not to use session but to pass the relevant tag as a parameter in the URL. So you would write link URLs to portfolio pages under tag "foo" like "/path/to/page/?tag=foo" and under tag "bar" they would be "/path/to/page/?tag=bar". Then in your portfolio template you would have some code like this: // Initialise some null pages as fallback $prev_page = new NullPage(); $next_page = new NullPage(); // Get the tag from $input if any $tag = $input->get->text('tag'); // If there is a tag if($tag) { // Get the IDs of portfolio pages with this tag - assumes a tag field named "tag" // It's more efficient to just get the IDs rather than the full Page objects, especially if there are a lot of portfolio pages $tagged_ids = $pages->findIDs("template=portfolio, tag=$tag"); // Get the position (key) of this current page in the array $page_position = array_search($page->id, $tagged_ids); // Get the previous page if any if(isset($tagged_ids[$page_position - 1])) { $prev_page = $pages($tagged_ids[$page_position - 1]); } // Get the next page if any if(isset($tagged_ids[$page_position + 1])) { $next_page = $pages($tagged_ids[$page_position + 1]); } } And where you want to output the prev/next links: <?php if($prev_page->id): ?> <p><a href="<?= $prev_page->url ?>?tag=<?= $tag ?>">Prev page</a></p> <?php endif; ?> <?php if($next_page->id): ?> <p><a href="<?= $next_page->url ?>?tag=<?= $tag ?>">Next page</a></p> <?php endif; ?> This way each portfolio page knows the tag it is being viewed under, and it means you can do things like share a link to a portfolio page such that the tag is specified.

I have found a solution and thought I would share it for the benefit of others. It may not be the most efficient or elegant solution but it is working. After some trial and error the solutions suggested in topic 7659, especially by formulate, began to make sense. In the tagging.php template file is the following code: $fullList = $pages->find("$searchTxt=$thisTag"); // this select all pages where page field "Tags" contains a page with title of our tag $tagList = $pages->find("$searchTxt=$thisTag, limit=10"); // this selects the same as above but limits the rsults for pagination $session->taggedPages=(string)$fullList; // save the result of the first search for use in the portfolio template In the portfiolio.php template file the following gets the prev / next pages from the tag search: $fullList=$pages->find("id=" .$session->taggedPages); $next = $page->next($fullList); $prev = $page->prev($fullList); This means that going to the prev / next page is not limited to those paginated on the tagging page. I hope that makes sense and helps someone else.