Leaderboard

My wife loves to cook, and I always like to further my knowledge around Processwire. So I thought I'll build a small page with the some small function to learn something. Used modules: ProMailer RepeaterMatrix Pages2PDF AIOM and some other litte modules Current functions: JSON-LD for recipes and page search Automatic ingredient calculation when changing the number of servings Creation of a PDF of the recipe Basic PWA (here is something to do, actually) Planned functions: a lot ? Site: https://www.dothiscookingthing.de

One of my first projects with ProcessWire. Online for a while, but still up to date and currently new features are being developed again. The most interesting feature of the site is the integration of the external tool and the PDF creation of the registration form with integrated API connection to always be able to directly output the most current dates. External Service: SEMCO ( https://www.semcosoft.com/de/ ) Used Modules: HannahCode Pages2PDF AIOM+ MarkupSitemap XML and some others In Development: Shop with Padloper Site: https://www.school-dynamic.de/ At this point I like to say Processwire makes it so easy for me to solve even more complicated tasks and get impressive results. Because I must confess, my PHP skills are unfortunately not yet where I would like to be.

This not really a deciding point, but about awareness that constants (as they are always static) are, just like static properties, subject to early binding. A lot of code (even mine, I have to admit) uses self:: to reference class constants and static properties, which is going to cause headache whenever such a class is extended and a constant or static property is changed. To be inheritance safe, any code that references such a value needs to use static:: instead of self:: (or address the property through the object instance). A short illustration: <?php class A { const one = 'ONE'; const two = 'TWO'; public static $three = 'THREE'; public static $four = 'FOUR'; public $five = 'FIVE'; const six = 'SIX'; function showMe() { echo self::one . PHP_EOL; echo static::two . PHP_EOL; echo self::$three . PHP_EOL; echo static::$four . PHP_EOL; echo $this->five . PHP_EOL; echo $this::six . PHP_EOL; } } class B extends A { const one = 'UNO'; const two = 'DUE'; public static $three = 'TRE'; public static $four = 'QUATTRO'; public $five = 'CINQUE'; const six = 'SEI'; } $b = new B(); $b->showMe(); That in mind, I guess the decision depends on a few questions: Is the code that is using the value executed often? In that case, constants have a small but perhaps noticeable performance advantage. If not, does my IDE of choice favor one over the other between constants and static properties? May the naming be changed at run time for an individual instance of the class? In that case, the actual value bearers have to be instance properties. For the later case, I like to use a mixed approach where my initial values are declared as constants (though a static property would be just as good) since they jump the eye: <?php class TestClass { const CLASS_PREFIX_DEFAULT = 'tpl_'; public function __construct() { $this->class_prefix = static::CLASS_PREFIX_DEFAULT; } //... } I try to avoid static access through $this:: (last line in the showMe() method above) as much as possible for my own sanity, as my head wants to make an immediate connection to instance access once it sees $this, and I'll likely end up with expressions like $this::$staticVariable, which to me looks too much like $class->$memberName, yet behaves differently.

Hi, you may try to copy the complete wire/modules InputfieldFile folder with all files into site/modules InputfieldFile. Then PW should ask you in the admin that there are two modules and which one you want to use. But please better first try this in a backup copy. I used this sometimes in the past, but not with newer PW versions.

I'm not sure he will. Generally, a new feature needs to be used by an estimated 30% of users to be accepted into the core. There are, however, exceptions to the rule - especially where hosting issues are concerned. I'm not happy with my adaptions yet, though, since they work on some installations here but not on others. I'm still on the lookout for the issue there. However, once I work out the kinks, and if the change doesn't have to get more complicated, I think it could have a good chance to be accepted (adding a feature request at processwire-requests and finding others who vote for it would certainly help).

Thanks a lot ☺️ I can show you the structure of the recipe template. Here are all accordions open. Tags are reference fields for the categories as well as the ingredients that are used as reference for individual ingredient pages. New categories and ingredients are created automatically when you enter the recipe. Especially with the ingredients there is still a lot to do, because the individual pages (e.g. https://www.dothiscookingthing.de/zutaten/balsamico/ ) should still get texts and images. Maybe also a bit of SEO texts. ?

Fair point and it's true that in practice I rarely change names, but I just feel more comfortable with (a) them all being declared at the top of the class so they can be changed there if necessary and (b) the IDE recognising the names and prompting, rather than relying on 'magic methods'. Either approach achieves that. Really good example. Thanks a lot. Food for thought!

Many thanks Bernhard, for your reply and your time. I’ll surely look at this and try. Then I will update you. Thanks again.

Actually @teppo - I might have found a bug. If I specify a 'results_list_group_heading' then I find that when there are more than one page of results, that heading sometimes appears twice on a page. I've changed to appending the heading I want to 'tabs_tablist' and that avoids the issue, but obviously it would be nice to 'results_list_group_heading' if possible. Let me know if you can't reproduce and I'll set up an example for you.

My repeater field's name is 'repeater'. So the template name of pages that this repeater creates in the background is 'repeater_repeater'. If my repeater field was named 'myrepeaterfield' then the template would be 'repeater_myrepeaterfield'. Repeater fields create one page for each repeater entry to store the data. Those pages are located in the page tree under Admin->Repeaters. In my case it looks like If you edit one of those pages, you can see the template name that PW creates automatically

Interesting idea. I've had a look. There is no way of doing this via PHP, but it's quite simple to do via JS: $(document).ready(function() { pwPanels.addPanel($("#pw-masthead a[href=/your/admin/link/url]")); }); Note that this will not work for json loaded links. You'd need to intercept the click event and init the panel on the fly, see https://github.com/processwire/processwire-requests/issues/176

Is there a way to have a unique Textfield? A Textfield which value is unique to all other pages with the same template? I found https://processwire.com/modules/fieldtype-text-unique/ but saw that it is not maintained for a long time. I had in my mind, that some others here had this issue already but my search did not result in anything....

Thanks for posting this, I was about to as something similar. I'm not sure the “Unique” status is a good fix to what I'm after doing. It looks like a hook per @Robin S‘s code would do the job nicely. I love PW. One thing I do think would be nice though for a future version would be for the core to offer some of the data integrity features of a rational database but managed through template and page settings: Something to mimic CASCADE and RESTRICT so that in a page reference, for example, you can restrict it being deleted if another page references it Make a field (of fields) unique as above

Nice stuff, I’m definitely going to try some of these ? What’s the smiley little guy who is sometimes a sofa? Maybe add a title attribute?

ONE DUE THREE QUATTRO CINQUE SEI Grazie many @BitPoet

At the moment tab labels can be customized by hooking into Renderer::renderTabLabel — does that seem feasible to you? Could also have a setting for this, but I'm not yet sure about that; it would get a bit complicated, particularly if I end up adding more group_by options. My initial impression is that current approach might be better, especially considering accessibility: users should get some kind of "summary" before the tabs, so that they know what's going on. Solving this with a "tabs first layout" could mean a) visible order that is not the same as real order, or b) visually hidden heading above tabs and then a visible heading hidden from screen readers below them. (Loosely related note: accessibility is not "perfectly" handled right now, I'll likely make some tweaks in this area soon.) I'll have to think about this a bit more. At the moment you have a couple of options: The module currently outputs a heading above the tabs and a summary below them. You could modify that first heading so that it's visually hidden and then hook into results rendering and inject your own "heading" above the summary element. This is a bit tricky right now, but I can make the heading rendering part hookable separately, I think that'd make sense anyway. Modify the order with JS. (Yes, this is a bit ugly... ?) So no real answer here, just some ideas, but I think that this level of control will likely require some sort of hook based solution anyway.

That was the solution. Thanks.

Hi all! In free time, I've played a bit with WireMailSmtp. Thanks to a lot of tutorials/explanation found on these forum and in the API pages, I find my way and my settings. For future readers taht maybe could need somthing similar, I've started here, here and here ( tks @ryan, @horst and many other contributors) . The power of PW always impresses... Bye!

Don't overthink it. You're gonna need a way to reference a specific field anyway. Hiding the name away behind a constant, config or whatever isn't going to change that. If you're worried about changing field names, you should instead invest the time to find better names for your fields. Why would your field names change? Probably because the data they hold or the thing they represent have changed - both of those cases will require adjustments in the templates anyway. I've never understood the benefit of "hiding" a property or method name behind a constant. I mean, what are you gonna do if the field name behind it changes? Let's say I have the field field_for_thing_a and use a constant FIELD_NAME_THING_A to hide the dirty, dirty field name string behind a nice, verbose constant. Now I need to rename the field to field_for_different_thing_b. Am I just gonna leave the constant in place? So FIELD_NAME_THING_A now references something completely different? No, I'm gonna rename it, in which case I could just find+replace the name of the thing itself and will introduce a BC break anyway. But if the field needs to change, it's not backwards compatible anyway. The only backwards compatibility I'm maintaining at this point is unreadable cargo cult code ? Of course, there are exceptions. Depends on what you're building. If you're talking about a module which might need to access a user-defined field, by all means, store the field name in a variable (it's gonna be pulled from the database anyway if it's configured in the module settings). Maybe I'm way off base here. What problem are you actually trying to solve? Maintainability is a spectrum and doesn't exist in a vacuum. What maintenance burden do you want to avoid?

You can think of it like this: Fieldtype = responsible for storing/sanitizing data Inputfield = responsible for UI/markup That's why it is very simple to create an inputfield. A very basic inputfield could just output "hello world" without any connection to the DB or other business logic. It's not exciting to avoid the DB, but if its not necessary because you use the Inputfield just for presentation then you can simply save time/effort that is not needed ? On the other hand using Inputfields instead of plain HTML has the benefit that you get a UI component that every PW user is familiar with and that you can control like any other Inputfield (setting columnWidth, toggling, label, icon, ...). See https://processwire.com/blog/posts/building-custom-admin-pages-with-process-modules/#adding-your-first-field-inputfieldmarkup The name INPUTfield can be a little confusing at the beginning, but after time it made a lot of sense for me and I could not think of a better wording now.

I've reworked this slightly, based on the helpful suggestion of @Kiwi Chris. The individual migration items are now entered in a repeater field and so the sequence can take into account any dependencies. Each item can be either 'new', 'changed' or 'removed'. When a migration is uninstalled, the sequence is automatically reversed and 'new' items are changed to 'removed' and vice versa. Example below shows a migration testing a page reference dependency (it works!). This is the appearance in the source database (pre-export): If you click 'Preview' you see what changes are proposed to export (see below). This feature also operates to review (in the target database) what changes will happen on install or uninstall - or, if the install has failed, what changes remain (either by modifying the migration or applying a manual fix if all else fails). Export is shown as 'no object' in the above, because the migration has not yet been exported. I think this all seems to work as designed, but am grateful for any futher thoughts on the design. I will now work on tidying the code a bit and doing a bit of documentation. There may still be a few bugs. There are some at the moment that I can't pin down but they are cosmetic rather than fundamental - I think I may need some help from those who understand the inner workings of PW better ( @adrian ?). Promises of help will encourage me to get on and release some code ? Meanwhile, I am happy to answer any further questions.

After looking into the code, adding support for a parallel uploads limit wasn't too hard, I think. If you're willing to try, I've created a fork of the current PW dev branch and added that functionality. This lets you set a configurable limit for how many uploads happen at once, the rest is queued and processed as soon as others finish.

I'm not so sure about that. AFAIK, PW has its own Ajax upload implementation in InputfieldFile.js and doesn't queue uploads at all.

Ah.... I have mistaken this with the "Unique" Page Name Status.

Maybe there's nothing wrong with it that needs maintaining. Alternatively you could use an ordinary text field and use a hook to validate the inputfield value: $wire->addHookAfter('InputfieldText::processInput', function(HookEvent $event) { $inputfield = $event->object; $field = $inputfield->hasField; if($field && $field->name === 'text_unique') { // Look for existing page with the field value $value = $event->wire()->sanitizer->selectorValue($inputfield->value); $existing_page = $event->wire()->pages->get("text_unique=$value, template=news_item"); if($existing_page->id) { // Show an error message $inputfield->error("Value '{$inputfield->value}' already in use on page '{$existing_page->title}'."); // Clear value $inputfield->value = ''; } } });

php files in /site/templates/ are protected against direct access. So you have to create a template and a (hidden) page using this template to use a page with ajax in templates folder. For example: rename the file to "ajax.php", create a template called "ajax" and a hidden page called "ajax" using this template. Now you can use ajax requests with an url like "http://yourcomain.com/ajax/". You can combime all your needed ajax stuff in this template. Just pass some "get" parameters with your ajax request like "?action=getuserinfo".