Leaderboard

Hi @teppo after checking your module code more carefully I found the already hookable methods ___getPageIndex and ___getFieldIndex. So please ignore my post above ?

@kongondo And because it is so much fun to think about the new MM and which requirements are more difficult to implement so far, I have another feature request. ? I have a few multi-language websites that keep running into the problem that different images have to be displayed depending on the language, e.g. because there is text on the images. Currently, I can only solve this in a complicated way using the PW-internal option with image tags. Personally, I find this a design workflow break in the whole PW concept, because the rest works wonderfully with the LangTabs modules. Perhaps also a feature request to @ryan at this point. ? My wish here would be to map the MM-InputfieldImage in the same way as multi-lang text fields. So with a simple language switch, select another item from the library.

@kongondo From my experience, my clients are overwhelmed with the InputfieldSelector and Lister and don't know what to do with them. I would also prefer a very simple approach here: "Search field for text", optional filter options in a simple UI: file type, time period (of the upload).

WebP to JPG Converts WebP images to JPG format on upload. This allows the converted image to be used in ProcessWire image fields, seeing as WebP is not supported as a source image format. Config You can set the quality (0 – 100) to be used for the JPG conversion in the module config. Usage You must set your image fields to allow the webp file extension, otherwise the upload of WebP images will be blocked before this module has a chance to convert the images to JPG format. https://github.com/Toutouwai/WebpToJpg https://processwire.com/modules/webp-to-jpg/

I'm creating a new topic in response to @cst989's question in the RM thread as I think this is a common question and misunderstanding when evaluating RockMigrations. It's also easier to communicate in separate threads than in one huge multi-page-thread... Hi @cst989 thx for your question and interest in RockMigrations. This sounds like you have a misconception in your head which is quite common I guess. Did you watch my latest video on RM, especially this part? https://www.youtube.com/watch?v=o6O859d3cFA&t=576s So why do you think it is a good thing to have one file per migration? I know that this is the way migrations usually work. But I don't think that this is the best way to do it. I'm not saying one way is right and the other is not. I'm just saying I'm having a really, really good time with RockMigrations and it makes working with PW in a more professional setup (meaning either working in a team and/or deploying PW to multiple locations and of course managing everything with GIT) a lot more fun an a lot faster and more efficient. If we look at how migrations usually work we can have a look at the other PW migrations module, which works just like usual migration modules work: You create one file per migration and you end up with a list of migrations that get executed one after another. See this screenshot from the modue's docs: In my opinion that screenshot perfectly shows one huge disadvantage of that approach: You don't see what's going on. You end up with a huge list of migrations that you can't understand on first sight. In RockMigrations this is totally different. You don't create one file per migration. You put all the necessary migrations where they belong and - in my opinion - make the most sense. An example: Let's say we want to add 2 fields to the homepage: "foo" and "bar". Ideally you are already using Custom Page Classes (see my video here https://www.youtube.com/watch?v=D651-w95M0A). They are not only a good idea for organizing your hooks but also your migrations! Just like adding all your HomePage-related hooks into the HomePage pageclass init() or ready() method, you'd add the migrations for your 3 fields into the HomePage pageclasses migrate() method. This could look something like this: Now let's say we develop things further and realise we also need a "bar" field: Do so see what we changed? I guess yes ? Now one big difference to a regular migration approach is that you don't write downgrade() or reversion migrations - unless you don't want to revert the changes! In real life I've almost never ever needed to revert changes. Why? Because you develop things locally and only push changes you really want to have on your production system. If you happen to have to remove some changes that you applied on your dev it's easy to do, though: You see what we did? Nice! So does everybody else that has access to the project's GIT repo! So all your team mates will instantly see and understand what you did. Pro-tip: You don't even need lies 43-45 if you didn't push those changes to production! If you only created those fields on your local dev you can simply restore the staging database on your local dev environment and remove the migrations that create the fields. Pro-tip 2: Also have a look at RockShell, then restoring staging or production data is as easy as "php rockshell db-pull staging" Pro-tip 3: When restoring a DB dump from the staging system it can easily happen that you have data in your database that was created only on the remote and you don't have on your dev system (like new blog posts for example). If you then open those new blog posts on your dev system processwire and the blog post contains images processwire will not be able to show those images (as only the file path is stored in the DB and not the whole image!). Just add $config->filesOnDemand = "http://yourstagingsite.example.com" to your config.php file and RockMigrations will download those files once PW requests the file (either on the frontend or also on the backend)! Having all your changes now in your git history you can even jump back and forth in time with your IDE: You could. I thought about that as well. But I think it does not really make sense and I hope my examples above show why. I'm always open to input though and happy to try to think about it from other perspectives. One final note: I'm not sure if what you say about $rm->watch() makes sense here. If you watch() a file that means that RM checks it's modified timestamp. If that timestamp is later than the last migration that RM ran, then RM will automatically execute the migrations that are in that file. All other files and migrations will be ignored. That makes it a lot more efficient when working on projects that have many migration files in many different places. When triggered from the CLI though or if you do a modules refresh then it will always trigger all migrations in all watched files. I hope that makes sense! --- Ok, now really a final note ? One HUGE benefit of how RockMigrations works (meaning that you write migrations in page classes or in modules) is that you create reusable pieces of work/code. For example let's say you work on a website that needs a blog. So you create a blog module and in that module you have some migrations like this: <?php $rm->createTemplate('blogparent'); $rm->createTemplate('blogitem'); $rm->setParentChild('blogparent', 'blogitem'); $rm->migrate([ 'fields' => [...], // create fields headline, date, body 'templates' => [...], // add those fields to the blogitem template ]); You'd typically have those lines in Blog.module.php::migrate() What if you need a blog in another project? Yep --> just git clone that module into the new project and execute migrations! For example in migrate.php this: <?php $rm->installModule('Blog'); If you follow a regular migrations concept where all project-migrations are stored in a central folder you can't do that! Of course you don't have to work like this. You can still write all your migrations in the project's migrate.php file. Because I have to admit that it is a lot harder to build a blog module that can be reused across different projects than just creating one for one single project! It always depends on the situation. But - and now I'll really leave it for today ? - you could also make your Blog-Module's migrate() method hookable and that would make it possible that you build a generic blog for all projects and then you add field "foo" to your blog in project-a and you add field "bar" to your blog of project-b. Have fun discovering RockMigrations. I understand it can look frightening at first, but it is an extremely rewarding investment! Ask @dotnetic if you don't believe me ?

https://github.com/elabx/FieldtypeRecurringDates Well a few summers later, finally got like a sort of working version. For info please take a look at the repo's readme. It's still super alpha but going to deploy into a couple websites to replace Recurme so wish me luck. This module is only a Fieldtype and Inputfield, there are no "markup" modules as there used to be in Recurme. I'd appreciate any testing or any kind of comments.

Oh great, thank you. So this means that Repeater Matrix fields are supported out of the box or do you need to tell the module how to process them? If there is custom code/hooks involved would you mind sharing a snippet? ? EDIT: I just saw that Indexer::getFieldIndex has logic for repeater fieldtypes. So no need for a snippet.

Hi @gebeer! I'm currently using RepeaterMatrix with SearchEngine successfully, though I'm not using any non-native PW FieldTypes. I did run into an issue where RepeaterMatrix-based fields, if customized by a template to not include one of it's available fields would cause an error and not complete the index. I have a pull request pending for the repository which, in my testing, seems to have fixed the problem. Although I suspect this might not be your issue, I wanted to share on the small chance that it does help.

@wbmnfktr I checked our list and don't see your email is on it. So next I checked the list activity log and see that we got 3 bounces from your email about 2 years ago. After 3 bounces it removes you from the list, as Mailgun doesn't like it if we keep sending to an address that bounces. I think it can be solved just by re-subscribing. Please let me know if you find it doesn't. Thanks.

Very good approach, but possibly not or not only via a template approach. I am very fond of the PW-internal possibilities of input and field dependencies (https://processwire.com/docs/fields/dependencies/). Here is a productive scenario of how I run it in an editorial workflow on another system I developed from scratch: The article template has the input fields date, category of the article (page reference or select), article images, etc. The editor can upload new images (or select existing ones from the library and add them) directly to the input field of the article images by dragging and dropping. When the new images are uploaded, they are automatically assigned in the library on the basis of the selected category and date. This eliminates a complete step of manual assignment for editors. @kongondo My idea for the MM: to enable a configuration for the input field that assigns new images to defined categories on the basis of other fields of the template and their values when they are uploaded. If this option is not configured, then I would also prefer the default behaviour "uncategorised" as lying in a "root folder" and the editors have to clean up themselves.

I hope we all together can keep this project stay alive, and make it a super-awesome-meta-collection-of-goodness for ProcessWire. There are so many awesome solutions and answers to common questions and challenges for whatever task buried deep into the forums. From basic questions to full-blown Pro module solutions. Maybe we all should be more sensitive to answers and solutions we get and at least should think about submitting those answers to the repository. In my opinion this repo/project should have the goal to be the starting point for all ProcessWire Newcomers. From easy tutorials to advanced setups. BUT... that's just my thought for the moment. To make this whole project NOT my personal project, I will add more and more people from our community as maintainers/owners to this whole repo and will think about a solution to find a way to finance the domain without me. But those are future tasks. Just wanted to let you know. It's not about me, but the thought behind all this!

Thank you, @gebeer for the awesome feedback. I love that idea! I wish we could create some sort of snippet collection (right now) from all of these recipes in some kind or another. While it would be quite easy for me to export each recipe to another format of almost any kind, almost each and every recipe has to follow some or all rules of formatting. Right now... the formatting is super basic but we can work on it and even could create snippets for only those recipes that support the wanted formatting. I could export those snippets, each and every time into another repository, when a recipe get's flagged as "isSnippet=true". If we can find a workable solution and formatting for real snippets... I'm here to support it! But first we should define a default/standard format for recipes and go from there. I wish we could go through all of the recipes to make them some kind of uniform, working with ProcessWire 2+, and mark those which only work with ProcessWire 3, or whatever version of ProcessWire, just to find a solid foundation. From there we could work out a snippet format and necessary fields, export them and even publish them to whereever we want. Something I forgot... there are snippets, ready.php snippets, common hook snippets... and probably more... so we have to classify snippets and recipes right from the start in some kind. But sure... that's possible. This will be fun! I really love this idea.

That would be perfect! ATM there are too many steps involved when tagging uploaded media. Doing the tagging based on the "folder" would be a big improvement. I agree this should be separate from the media types. Maybe something like "uncategorized" This should definitely be possible. So media that has multiple categories would appear in multiple virtual folders. Yes and no ? The inbuilt image/file tags could be used in the background to store the tags. But for editing I would prefer if I did not have to edit an image before I can input tags. It would be cleaner and faster for editors if they can just edit tags directly without having to go the extra step to edit the image. So the tags field would have to live on the MM page that holds the media. Does that make sense? Also there should be a way how we can pre-define available categories. Just like we can pre-define available tags for aan image/file field. The simpler the better ? Almost all of my clients are overwhelmed by PW Lister filters. Even with predefined filter profiles it is hard for non-techy people to understand the concept and what they see in the dropdown selects. I think this is a very tough one to tackle. If you have just one search input like in WP, you get back results that you where not looking for because the search is too broad. Maybe a combination of a text input that searches for file names and one select dropdown that determines the category you want to search in could work? Totally agree. It could be a configurable option whether to include files from subfolders in the view or not. Great suggestions. For the time being a config option for icon size would be helpful. Or do the Preview maximum width/height settings already have an effect on those icons?

Hi @kongondo It would be nice to have a full text search, which would always be visible. If this is not possible, it would be nice, if the filter would be always open, so one can start typing immediately and previously set filter values would be visible right away. Also a more compact view for pdf documents would be great, because the current grid and list view both require a lot of space if one has some hundred pdfs in the library. In a past project I added the pdf filenames to the grid view by modifiying some javascript files, to have a more compact view with the filenames visible. Perhaps, pdf icons could be a lot smaller or omitted at all in the document view. The UI elements could be smaller and information like how many times an image was used, filesize, etc. could be hidden and made visible with a toggle button, so everything would take up less space and more image and document items would fit on the screen.

@kongondo Sorry, I'm a bit tied up at the moment. But it behaves like real folders. When you click on "People", only two folders are displayed, but no pictures from both subfolders. I would also prefer this. Inheriting subitems in the view works well for a few folders, but not for 20, 50, 100 and then recursively over several levels lower.

I just noticed that the field doesn't really work within selectors as I expected, but working on it! ? Here's the problem laid out a bit:

Hi, just a little idea i often think about, when you create a fieldset field and you give it one or more tags in the advanced tab, it may be a good idea that the fieldset_END gets the same tag(s) by default instead of ending in the fields with no tags list ? have a nice day

Checkout the new PAGEGRID online demo ? Now I'm working on a couple of video tutorials to highlight some use cases and features. I also added a changelog to the first post so you can stay up to date. As I use PAGEGRID for some of my own projects, I'll be updating the module to meet my needs. But I'm also interested in your feedback. What features would you like to see in PAGEGRID?

I think namespacing your file with the ProcessWire namespace should fix your issue.

I had a different setup where I wanted my files served from a sub-domain (even though in the end it was from /site/assets/files), but it's somehow related. What I did was to point the sub-domain to /site/assets/files, and then add this hook in ready.php : $wire->addHookAfter("Pagefile::url", function($event) { static $n = 0; if(++$n === 1) { $file = $event->object; $url = $file->httpUrl; $host = wire("config")->httpHost; $url = str_replace("$host/site/assets/files", "sub.domain.com", $url); $event->return = $url; } $n--; }); You could replace "sub.domain.com" to "domainB.com/site/assets/files" (or even clear the "site/assets/files" part in your case). Hope it helps !

It does, it's just not documented unfortunately. I linked to information about it in my earlier post above. Here is a demo... Page structure: Field settings for subcategory field: "page.category" will be replaced with the ID of the page selected in the Category inputfield in Page Edit, whenever that field changes. The "has_parent" part is just to avoid unwanted pages appearing in the Subcategory inputfield if the Category inputfield is changed to empty (no page selected). Result:

Doesn't "template=user, !login_end<=today" work?