Leaderboard

This last week my wife and daughter took a trip to NYC and it was my daughter's first time there. I was browsing around online looking at things they could do and so I visited the Guggenheim museum website to look into that option... I've always been a fan of the building, a Frank Lloyd Wright masterpiece. In addition to New York, I learned from the website that Guggenheim also has museums in Abu Dhabi, Bilbao and Venice, so I clicked through to view them as well. I really liked the Venice Guggenheim website, which had a much nicer website than the other locations. It was such a nice site that I was curious what they were running, so I viewed the source and... not WordPress (like the others), but ProcessWire. What a nice surprise. Then I was curious about who made such a nice site and there was a credits link in the bottom right corner that says the site was made by basili.co, nice work! It's always fun to come across a ProcessWire powered website randomly like that, and I thought you all would enjoy this one too. This week there are fairly minor updates on the core dev branch. Though the updates include one I've been meaning to do for a long time: improve the API for processing Inputfield forms. Previously there's been no way to check if a form is submitted, short of checking an $input variable yourself. Today I committed an update that adds a $form->isSubmitted() method that solves that, and more. It can identify which form was submitted, which submit button was used, and it also performs additional checks to make sure it's a valid submission before deciding that it's a form worth processing. It improves reliability, accuracy and security. Next week I'll be updating several of the admin forms to use it, among other updates. A few other useful helper methods were added to the Inputfield forms API as well. I realize that these updates may only be of interest to module authors, but I like keep you up-to-date with the week's updates either way. Thanks for reading and have a great weekend!

I'd be very interested in some details and explanations on this ? I've been working with forms quite a bit and sometimes things where a little unclear to be honest. For example sometimes I had to do a $this->trackChange('value') to make my inputfield module save anything. While I found a way to make it work it would be nice to better understand the inner workings of the whole process ?

Well, more of a suggestion than a recommendation in https://processwire.com/blog/posts/pw-3.0.152/#custom-page-classes-vs-hooks Thx. He is just showing what you CAN do, if you want to. But there's no need for doing that. You could for example create a specific page class for your project that all custom page classes extend on. That could be helpful to share some common business logic. Let's say we had a project FOO and we had custom page classes EVENT and NEWS. Maybe both EVENT and NEWS share a common method that returns the slogan of our FOO project, which is "FOO is a great project!". You could create a FooPage: class FooPage extends Page { public function slogan() { return "FOO is a great project!"; } } and then if you extend that FooPage rather than the PW Page from your EVENT and NEWS pageclasses you can access the slogan from both: class EventPage extends FooPage {...} class NewsPage extends FooPage {...} $event = new EventPage(); echo $event->slogan(); $news = new NewsPage(); echo $news->slogan(); Now if you wanted to change the slogan you'd just need to change the slogan in FooPage and all other classes would reflect that change. You can also use traits for a similar thing which is even more flexible since you can let your classes use multiple traits. That's what I'm doing with my RockMigrations MagicPage to make those pages have (and also trigger) init/ready/migrate methods. But still they are just extending the "Page" class. Absolutely, but it is a rather large app, so difficult to encapsulate. The context is the same as the worked example here (which I will repeat for ease of reading): I'm still not sure I fully understand but I'm not using Repeaters or RepeaterMatrix at all nowadays, so I can't say much about them. The problems you are facing might just be another reason why I'm avoiding them ? But I might be wrong. I don't know ? I've built several apps based on Repeaters and I always got into trouble later. So I stick to the fundamentals, which are Pages rather than repeater items. Another example would be RockMatrix, where all items are just Pages and all have a common base class that they extend. So that could also be an example of the first question I answered above.

I have used both and now just use this one on new projects. They both work fine in normal circumstances (and are easy enough to just temporarily install and play with), but @Robin S's is simpler with less to go wrong - I had a few problems with @kongondo's in a multi-instance environment (which I think are fixed). On the other hand @kongondo's has a slightly more feature-rich GUI. You could always build your own simple module rather than just use hooks if you want more than the basic RuntimeOnly and want control over the code - I forked this module to include a custom Fieldtype in my ProcessDbMigrate module. As @bernhard says, it all depends what you are trying to do.

I'll share my youtube videos in this thread and if you have questions this is the place to ask. You can also subscribe to this thread to get notified when I post new videos ? Here is the link to my channel: baumrock.com/youtube --- Hey! I've just published my very first ProcessWire video. It's about RockFrontend: https://processwire.com/talk/topic/27417-rockfrontend-??-take-your-processwire-frontend-development-to-the-next-level/#comment-225666 Here is the video: What do you think? Do you understand what I'm trying to explain (despite the many ääähms und öööhms...)? ? What about the length?? I really didn't plan do get to 40mins... Did anybody even watch it till the end? ? Would it be easier to follow when having a small thumbnail in the bottom corner when working on the code? Or better without? Is it worth the effort of creating a video or would a readme be just as good? ? Any tips for better sound/lighting? I'm not really knowing what I do, so any ideas for improvements are very welcome ? Better with or without background music? So many questions... So much to learn... ? But it's fun and I'm a bit proud ?

Just my two cents: used to avoid Repeaters as well, because in the beginning they were quite unstable, but from my point of view they have matured nicely. For years I/we have used them a lot — in fact nearly all sites we've built last couple of years have used a Repeater Matrix based page builder. Can't remember the last time I had an issue directly related to repeaters ?‍♂️ That being said, I do try to keep things simple, just in case. Field dependencies is an example of a feature I've not tried with repeaters ?

That explains a lot! I have LOTS of repeaters in this new app as it seemed a really neat idea from the point of view of the admin gui. Then I ran into LOTS of problems with dependent page selectors, which I think I’ve now fixed, either by contributions to the core or by the new CustomDependSelects module. I have wondered whether it would have been wiser to use plain pages. RepeaterMatrix does seem to be very popular (and I can see why), particularly for a UI for web page blocks. Other contributions on the “repeaters or no” discussion would be helpful.

Hi, I'm working on a dashboard with some functionality that will be used by two roles "user" and "management". These both roles should not see anything else in the admin-header-section than the dashboard, like in this screenshot. Also while editing any elements they should not see "Settings" Delete and so on like seen here: All these options should only appear for the "superuser" or "developer" for maintaining everything. For the moment it would be ok if the options would be just "not visible" in the longterm it would be awesome to find a way to really block every user not in the specific role. In my actual case the users would not try to hack something but everybody know to better be safe than sorry ? Maybe it is related to that topic also: I noticed if I put all fields of a template in a "FieldsetTabOpen" the "Content"-Tab is still shown and have some wired actions (after switching to an other tab and back it shows the content of the former tab). It would be no problem to completely remove that "Content"-Tab at all by a hook and only work with "FieldsetTabOpen". I hope I could somehow explain what I would like to archive. Thank you all

Thank you for the hint with the modules also. If I just use the AdminRestrictPageTree module it also hides my self created dashboard. But I created the Dashboard by myself and not with the module mentioned in your answer. I will give that a try also. And of course you were totally right and I‘m sorry for my bad wording here. Yes I was talking about permissions and not roles. I will play around and also have a look inside the mentioned modules to maybe get some ideas out of the code. Thank you

It depend on how you configured the field. You can make it work by calling $page->images->first()->url The doc say: For more informations: https://processwire.com/docs/fields/images/

Hi Adrian, it's been a while since I needed this functionality and didn't realise I'd left my own module still up - I'll likely take it down soon and direct people to yours if you think that makes sense? I'm going to use yours for a project, but can I suggest an option to hide the login form? For normal maintenance I wouldn't let any roles log in and as superuser I'd just go to the right URL instead is my thinking. It may also be worth changing the title of your module in the directory to "Protected/Development/Maintenance Mode" so those keywords are found during search as currently only mine comes up for "maintenance".

PS: If you are using RockMigrations you can simple use the MagicPage trait and you get an autoload pageclass that automatically triggers init() ready() and migrate()

processwire-rocks.com ?

Thank you again. Sorry, I finally got around to fully installing the module. I completely get the purpose of using it now. Still works perfectly to automatically create recurring events.

TLDR: Use custom selectors in page field selector: - check_access=role1|role2 ... - to control who can see results - field=[item.id] - to select on id of repeater item containing the page field. ------------ This module extends the capabilities of selectors specified in the 'input' tab of a page reference field, specifically when that field is part of a set of dependent selectors which may be inside a repeater item. The readme also attempts to bring together various existing documentation regarding the use of dependent page selectors and the enhancements that were provided by various PW versions. See https://github.com/MetaTunes/CustomDependSelects for full readme and to download. Please note that this is an initial alpha release. Please test in your own context thoroughly before using. Also note that PW3.0.200 is required and 3.0.203 is preferred.

But role is a thing, and permissions is another and this last is what you are looking for. Look there - https://processwire.com/docs/user-access/permissions/ - and try to play with them, then give a look at those modules : https://processwire.com/modules/admin-restrict-page-tree/ https://processwire.com/modules/custom-admin-menus/ For example, I have a role "accountant" and he do not have access to the page tree or any other features than the "accounting" module.

A quick update... Version 1.2.5 allows you to deactivate url hooks and fallback into the legacy ProcessPageView::pageNotFound behavior. That's now possible in the module config. I discovered, embarrassingly just after the release of the new version 1.2.4, a case where switching to the URL hook actually causes a breaking change. In all tests before this was not noticed, so sorry if anyone discovered something similar. Now, in any case, it is easy to switch back to the old hook. Now to the problem: Maybe someone reading this has some deeper insight and can help me to understand the issue. I have a page on which I have included @Wanze`s SeoMaestro field and wanted to read the values from it via Api: <?php $page = wire('pages')->get('/'); if ($page->template->hasField('seo')) { $seoString = @$page->seo->render(); } That actually works fine when it's done in an ProcessPageView::pageNotFound hook. But if I use a url hook and call it, the seo->render() call will throw the following error: { "error": "Method Page::localUrl does not exist or is not callable in this context", "devmessage": { "class": "ProcessWire\\WireException", "code": 0, "message": "Method Page::localUrl does not exist or is not callable in this context", "location": "\/processwire\/wire\/core\/Wire.php", "line": 564 } } I've managed to step through the code and find out the source of the exception. It's a call of page->localUrl in SeoMaestro's PageFieldValue class: https://github.com/wanze/SeoMaestro/blob/master/src/PageFieldValue.php#L158 Any ideas? ?

not intended to start a fight ... but here are my pro's for using uikit ... It's called controlled bias ??

A picture (meaning a few lines of example code) is worth a thousands words :) Thanks for caring and sharing guys, btw.

I've seen a couple of questions regarding namespaces and autoloading floating around the forum recently, so I decided to write a little tutorial. In general, I often see people getting confused when they try to wrap their head around namespaces, autoloading, Composer and the mapping of namespaces to directory structures all at once. In fact, those are very much independent, distinct concepts, and it is much easier to explain and understand them separately. So this guide is structured as follows: How namespaces work in PHP. How autoloading works in PHP. Conventions for mapping namespaces to directory structures: PSR-4. How autoloading works in Composer and ProcessWire's class loader. How to use the class loader in a ProcessWire module. Feel free to skip the sections you're already familiar with. Namespaces in PHP The purpose of namespaces in PHP is to avoid naming conflicts between classes, functions and constants, especially when you're using external libraries and frameworks. Nothing more. It's important to understand that this has nothing at all to do with autoloading, directory structures or file names. You can put namespaced stuff everywhere you want. You can even have multiple namespaces inside a single file (don't try this at home). Namespaces only exist to be able to use a generic name – for example, ProcessWire's Config class – multiple times in different contexts without getting a naming conflict. Without namespaces, I couldn't use any library that includes a Config class of it's own, because that name is already taken. With namespaces, you can have a distinction between the classes ProcessWire\Config and MoritzLost\Config. You can also use sub-namespaces to further segregate your code into logical groups. For example, I can have two classes MoritzLost\Frontend\Config and MoritzLost\Backend\Config– a class name only needs to be unique within it's namespace. You can declare the namespace for a PHP file using the namespace statement at the top: // file-one.php <?php namespace ProcessWire; // file-two.php <?php namespace MoritzLost\Frontend; This way, all classes, methods and constants defined inside this file are placed in that namespace. All ProcessWire classes live in the ProcessWire namespace. Now to use one of those classes – for example, to instantiate it – you have a couple of options. You can either use it's fully qualified class name or import it into the current namespace. Also, if you are inside a namespaced file, any reference to a class is relative to that namespace. Unless it starts with a backward slash, in this case it's relative to the global namespace. So all of those examples are equivalent: // example-one.php <?php namespace ProcessWire; $page = new Page(); // example-two.php <?php use ProcessWire\Page; $page = new Page(); // example-three.php <?php $page = new ProcessWire\Page(); // example-four.php <?php namespace MoritzLost\Somewhere\Over\The\Rainbow; $page = new \ProcessWire\Page(); The use statement in the second example can be read like this: “Inside this file, all references to Page refer to the class \ProcessWire\Page” How autoloading works Every PHP program starts with one entry file – for ProcessWire, that's usually it's index.php. But you don't want to keep all your code in one file, that would get out of hand quickly. Once you start to split your code into several individual files however, you have to take care of manually including them with require or include calls. That becomes very tedious as well. The purpose of autoloading is to be able to add new code in new files without having to import them manually. This, again, has nothing to do with namespaces, not even something with file locations. Autoloading is a pretty simple concept: If you try to use a class that hasn't been loaded yet, PHP calls upon it's registered autoloaders as a last-ditch attempt to load them before throwing an exception. Let's look at a simple example: // classes.php <?php class A { /** class stuff */ } class B { /** class stuff */ } // index.php <?php spl_autoload_register(function ($class) { include_once 'classes.php'; }); new A(); new B(); This is a complete and functional autoloader. If you don't believe me, go ahead and save those two files (classes.php and index.php) and run the index.php with php -f index.php. Then comment out the include_once call and run it again, then you'll get an error that class A was not found. Now here's what happens when index.php is executed (with the autoloader active): Our anonymous function is added to the autoload queue through spl_autoload_register. PHP tries to instantiate class A, but can't because it's not loaded yet. If there was no autoloader registered, the program would die with a fatal error at this point. But since there is an autoloader ... The autoloader is called. Our autoloader includes classes.php with the class definition. That was a close one! Since the class has been loaded, execution goes back to the index.php which can now proceed to instantiate A and B. If the class was still not loaded at this point, PHP would go back to the original plan and die. One thing to note is that the autoloader will only be called once in this example. That's because both A and B are in the same file and that file is included during the first call to the autoloader. Autoloading works on files, not on classes! The important takeaway is that PHP doesn't know if the autoloader knows where to find the class it asks for or, if there are multiple autoloader, which one can load it. PHP just calls each registered autoloader in turn and checks if the class has been loaded after each one. If the class still isn't loaded after the last autoloader is done, it's error time. What the autoloader actually does is pretty much wild wild west as well. It takes the name of the class PHP is trying to load as an argument, but it doesn't have to do anything with it. Our autoloader ignores it entirely. Instead, it just includes classes.php and says to itself “My job here is done”. If class A was in another file, it wouldn't have worked. This process has two main advantages: Since autoloaders are only called on-demand to load classes just in time, we only include the files we actually need. If in the example above class A and B are not used in some scenarios, the classes.php will not be included, which will result in better performance for larger projects (though this isn't as cut and dry, since autoloading has it's own overhead, so if you load most classes anyway during a single request, it will actually be less efficient). If the autoloader is smart enough to somehow map class names to the files they're located in, we can just let the autoloader handle including the classes we need, without having to worry about jamming include statements everywhere. That brings us to ... PSR-4, namespaces and directory structures As you see, namespaces and autoloading are both pretty limited concepts. And they aren't inherently linked to each other. You can namespace your classes without ever adding an autoloader, and you can autoload classes that are all in the same namespace. But they become useful when you put them together. At the core of all that autoloading talk is a simple idea: By putting classes in files named after their class names, and putting those files in directory hierarchies based on the namespace hierarchy, the autoloader can efficiently find and load those files based on the namespace. All it needs is a list of root namespaces with their corresponding directories. The exact way class names and namespaces are mapped to directory structures and file names is purely conventional. The accepted convention for this is PSR-4. This is a super simple standard which basically just sums up the ideas above: A base namespace is mapped to a specific directory in the file system. When the autoloader is asked to load a class in that namespace (or a sub-namespace of it), it starts looking in that folder. This "base" namespace may include multiple parts – for example, I could use MoritzLost\MyAwesomeLibrary as a base and map that to my source directory. PSR-4 calls this a "namespace prefix". Each sub-namespace corresponds to a sub-directory. So by looking at the namespace, you can follow subdirectories to the location where you expect to find the class file. Finally, the class name is mapped directly to the file name. So MyCoolClass needs to be put inside MyCoolClass.php. This all sounds simple and straightforward - and it absolutely is! It's only once you mash everything together, mix up language features, accepted conventions and proprietary implementations like Composer on top that it becomes hard to grasp in one go. Composer and ProcessWire's class loader Now all that's left is to talk about how Composer and ProcessWire provide autoloading. Composer, of course, is primarily a tool for dependency management. But because most libraries use namespaces and most developers want to have the libraries they're using autoloaded, those topics become a prerequisite to understanding what Composer does in this regard. Composer can use different autoloading mechanisms; for example, you can just give it a static list of files to include for every request, or use the older PSR-0 standard. But most modern libraries use PSR-4 to autoload classes. So all Composer needs to function is a mapping of namespace prefixes to directories. Each library maintains this mapping for it's PSR-4-structured classes through the autoload information in their composer.json. You can do this for your own site to: Just include the autoload information as shown in the documentation and point it to the directory of your class files. Composer collects all that information and uses it to generate a custom file at vendor/autoload.php — that's the one you need to include somewhere whenever you set up Composer in one of your projects. Bells and whistles aside, this file just registers an autoloader function that will use all the information collected from your own and your included libraries' composer.json to locate and include class files on demand. You can read more about how to optimize Composer's autoloader for production usage here. If you want to read up on how to set up Composer for your own sites, read my ProcessWire + Composer integration guide instead. And finally, what does ProcessWire do to handle all this? Turns out, ProcessWire has it's own autoloader implementation that is more or less PSR-4 compliant. You can access it as an API variable ($classLoader or wire('classLoader'), depending on context). Instead of using a static configuration file like Composer, the namespace -> directory mapping is added during the runtime by calling $classLoader->addNamespace. As you would expect, this function accepts a namespace and a directory path. You can use this to register your own custom namespaces. Alternatively, if you have site-specific classes within the ProcessWire namespace, you can just add their location to the class loader using the same method: $classLoader->addNamespace('ProcessWire', '/path/to/your/classes/'). Utilizing custom namespaces and autoloading in ProcessWire modules Now as a final remark, I wanted to give an example of how to use custom namespaces and the class loader in your own modules. I'll use my TrelloWire module as an example: Decide what namespace you're going to use. The main module file should live in the ProcessWire namespace, but if you have other classes in your module, they can and should use a custom namespace to avoid collisions with other modules. TrelloWire uses ProcessWire\TrelloWire, but you can also use something outside the ProcessWire namespace. You need to make sure to add the namespace to the class loader as early as possible. If either you or a user of your module tries to instantiate one of your custom classes before that, it will fail. Good places to start are the constructor of your main module file, or their init or ready methods. Here's a complete example. The module uses only one custom namespaced class: ProcessWire\TrelloWire\TrelloWireApi, located in the src/ directory of the module. But with this setup, I can add more classes whenever I need without having to modify anything else. /** * The constructor registers the TrelloWire namespace used by this module. */ public function __construct() { $namespace = 'ProcessWire\\TrelloWire'; $classLoader = $this->wire('classLoader'); if (!$classLoader->hasNamespace($namespace)) { $srcPath = $this->wire('config')->paths->get($this) . 'src/'; $classLoader->addNamespace($namespace, $srcPath); } } Source Thanks for making it through to the very end! I gotta learn to keep those things short. Anyway, I hope this clears up some questions about namespaces and autoloading. Let me know if I got something wrong, and feel free to add your own tips and tricks!