gebeer

Hi @teppo and thank you for this module. I am evaluating Whether we can use this for a bigger project. The project makes heavy use of Repeater Matrix fields. And those seem not to be supported atm. Could you make the Indexer::indexPage method hookable? That way we could implement our own code for non supported fieldtypes. That would be awesome.

@wbmnfktr Thank you so much for breathing life back into this project. Website already looks awesome. I have an idea/suggestion: it would be great if all the code snippets could easily be integrated and used in our IDE. With the current way of how they are stored on GH I wouldn't how this could be achieved. There is a vscode extension that lets you use gists as code snippets. So if the actual code snippets were organized in gists it would be possible to use those from within the IDE. Maybe there is an automated way of storing all snippets as gists from within your build process?

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?

Thank you Moritz!

@MoritzLost is your module ready for PHP 8?

Same experience with our clients. They are coming from TYPO3 and are used to organize media in folders. Trying to explain that the MM approach is much more flexible. But they'd still love to have their folders back. Technically this would mean that there is some kind of default categorisation apart from media type. I think using tags would be the best and most flexible method.

If it is a field called "type" in store_template, it should be as simple as // for text field or select options $pages->get("template=store_template,equipment_ref.title='Equipment2, type="Type1"'); // for page ref field $pages->get("template=store_template,equipment_ref.title='Equipment2, type.title="Type1"'); Even if you have a page reference field with multiple entries, this selector will return a page as long as one of the entries has title "Type1".

Where is the condition Type1 in your structure?

Behind the scenes entries in a PageTable field are just regular pages in a regular PageArray. Lets say you have a field "pagetable" and it is configured to use template "blog-post" for items. You can create a new page with new items in the pagetable field like this: // create page that holds pagetable items $p = new Page(); $p->template = 'basic-page'; $p->parent = '/foo/'; $p->title = "Bar"; $p->save(); // get parent id for pagetable items from field config $parentID = $p->getField('pagetable')->parent_id; // create item page for field pagetable $item = new Page(); $item->template = 'blog-post'; $item->parent = $parentID; $item->title = "Item Foo"; $item->save(); // add item page to pagetable field $p->pagetable->add($item); $p->save('pagetable'); Since the value of $p->pagetable is a PageArray, you can find and manipulate the pagetable items with methods from Pages, PageArray and WireArray. To remove a specific item: $item = $p->pagetable->get('title="Item Foo"'); $p->of(false); $p->pagetable->remove($item); $p->save('pagetable'); You can also use WireArray manipulation methods insertBefore(), insertAfter(), append(), prepend() to add items in a specific order.

Unfortunately not anymore since 8.0. The docs say But thanks for looking into it ?

Glad you sorted it out ? My example was in a mudule's config inputfields context. That is why $inputfields was null in your context. Are you still using Hannacode? You don't really need it.

I think what you are looking for is an https://processwire.com/api/ref/inputfield-markup/ inside your Block Ordering Tab. You can use that to output the markup that is being supplied by your Hannacode. And you don't even need that Hannacode. Because your development template ordering lives on a single page that doesn't change in different contexts. So you can produce the markup for InputfieldMarkup from that page id. For InputfieldMarkup you can set the property markupFunktion to a closure that outputs your block order. Something like /** @var InputfieldMarkup $f */ $f = $this->wire->modules->get('InputfieldMarkup'); $f->set('label', 'Development Template Ordering Status'); $f->set('markupFunction', function () { $markup = ''; foreach(wire('pages')->get(yourid)->get('block_order_field') as $block) { $markup .= "{$block->title}<br>"; } return $markup; }); $inputfields->add($f); This will output something like

Yeah, I guess that is why. My understanding is that every FieldsetPage field value is stored on page in the Admin pagetree behind the scenes. And by default those are not accessible for guest users.

Have you tried adding include=all to your children selector?

In your selector the Repater Matrix Type is missing. Your "items" repeater matrix field needs to have some named "types" setup in the field configuration screen. The textfield is inside that type. If repeater matrix field "items" with type "image_text" has a field "textfield", your selector would look like: content_sections.items.type=image_text To get all pages that have items of type image_text you can use. $pagesWithType = $pages->find("content_sections.items.type=image_text"); To get all the texts you need to loop through those pages and get your textfield value foreach($pagesWithType as $p) { $term = $p->get('textfield'); } Or you can get an array of all terms like this $terms = $pagesWithType->explode('textfield'); Seehttps://processwire.com/api/ref/wire-array/explode/ EDIT: removed initial selector added code with loop etc

Time to revive this 8 year old thread ? I'm using vscodium as editor and recently for code formatting I moved from the excellent https://intelephense.com/ extension to an extension that uses https://github.com/PHP-CS-Fixer/PHP-CS-Fixer which is based on https://github.com/squizlabs/PHP_CodeSniffer. This allows custom style definitions (rulesets) https://github.com/squizlabs/PHP_CodeSniffer/wiki/Advanced-Usage#using-a-default-configuration-file PW coding style guide says: Has anybody ever gone through the trouble of creating a custom PW ruleset.xml? Just asking before I start spending my time on that. Other CMSs/Frameworks do have their ruleset files. See https://github.com/WordPress/WordPress-Coding-Standards https://www.drupal.org/docs/contributed-modules/code-review-module/installing-coder-sniffer https://github.com/fossbarrow/laravel-phpcs Would be great if we had one for ProcessWire, too. Maybe @ryan already uses one and can share it? If not, we could start a community effort to produce such ruleset. It would help tremendously for PRs to the PW core or for module development.

Just installed Tabnine and went on coding as usual on PW projects. It seems that it is not aware of all the PW specific classes, methods, API variables etc. Or do you experience differently? Maybe it takes some time until it picks up PW specific stuff. It surely was not trained on PW core code because the PW licensing model is not permissive by Tabnine's definition since it uses MPL 2.0 alongside MIT and others. Maybe GHs Copilot has an advantage there?

I've been working further on the module concept and found a (mostly reliable) way to react on all error types in PW. Just wanted to share my findings before a release. Looking through PW core, I found that nowhere PW registers custom error or exception handlers. So I decided to use set_error_handler() for warnings/notices and set_exception_handler() for exceptions. To also cover fatal errors, I hook into WireShutdown::fatalError instead of registering my own shutdown function. Gladly Ryan provides that hook ? So the basis for my operations looks like this in the module's init(): $this->originalErrorHandler = set_error_handler(array($this, 'errorHandler'), E_NOTICE|E_USER_NOTICE|E_WARNING|E_USER_WARNING); $this->originalExceptionHandler = set_exception_handler(array($this, 'exceptionHandler')); $this->wire->addHookAfter('WireShutdown::fatalError', $this, 'fatalHandler'); Note, how I save the original error and exception handlers, so I can set them back once I've finished my operations so that my module doesn't interfere with other modules that use their own handlers (like TracyDebugger). For now I'm only doing the send email based on error type part. The https://rollbar.com/ part will most likely go into a separate module. I still need to test some on a production site until there will be an alpha/beta release. Related question: does anybody know how to deliberately cause an E_NOTICE error, other than using trigger_error('My error', E_USER_NOTICE) in PHP > 8? I couldn't find or think of a real world example. Before PHP 8 we could use "echo $undeclaredVariable". But since 8 those notices are converted to warnings.

@kongondo Where are messages from MM actions like uploads etc are supposed to appear in the GUI? I mean messages that are generated during executeAjax(). I can see them as JSON response in the dev tools for requests to e.g. /processwire/media-manager/ajax/ like { "files": [ { "name": "csm_us_ziehmvisionrfdhybridedition-usa-forweb_1080x1080px_7c9dea3ab6.jpg", "size": 34682 } ], "count_total": 1, "count_success": 1, "count_fail": 0, "message": "error", "notice": "Media Manager: No valid media found to add to Media Library. If replacing media, check that they are not locked.", "nothingAddedYet": "Nothing added yet.", "action": "upload", "currentPageID": 0, "mediaManagerFieldID": 0, "insertAndClose": 0, "galleryID": "", "notice2": "Media Manager: Some media were not added because names already in use (csm_us_ziehmvisionrfdhybridedition-usa-forweb_1080x1080px_7c9dea3ab6.jpg)." } But there is no message output in the GUI after upload. In this case a duplicate image was ignored for upload. Are these JSON responses supposed to be shown as messages in the GUI? If not, it would be awesome if they could be shown to the user.

Just to recap in case anyone else experienced this: After MM install I ended up with pages with wrong names (media-manager--audio, --document, --image, --video) under Admin->Media Manager. As a consequence all created media pages got saved under parent Admin->Media Manager->Media Manager:Audio. This also had an impact on duplicate media pages. They could not be detected. So no matter what the settings for duplicate media, all media got uploaded even if it was duplicates. I used this code to rename pages under Admin->Media Manager to have correct names like (media-manager-audio, -document, -image, -video) and move all media pages to live under their correct parent pages: // FIX wrong Media Manager page names under Admin -> Media Manager and sort media pages under correct parent $types = ['audio', 'document', 'image', 'video']; // fix page names from "media-manager--$type" to "media-manager-$type" foreach($types as $type) { $pID = $this->wire->pages->getId("parent.name=media-manager, name=media-manager--{$type}"); if($pID) { $this->wire->pages->get($pID)->setAndSave('name', "media-manager-{$type}"); } } // move media pages from wrong parent media-manager-audio to correct parent "media-manager-$type" foreach($types as $type) { // get all media pages under media-manager-audio parent $ids = $this->wire->pages->findIDs("parent.name=media-manager-audio, media_manager_{$type}!="); // put them under correct parent if(count($ids)) { $parentID = $this->wire->pages->getID("parent.name=media-manager, name=media-manager-{$type}"); if($parentID) { foreach($ids as $id) { $p = $this->wire->pages->get($id); $p->setAndSave('parent', $parentID); } } } }

You can make URLs to PDFs look nicer Further up in that thread, you can see how you can implement output.

I moved from Joomla/Seblod to ProcessWire about 10 years ago. It was the best decision I ever made in my developer life. Happy coding with PW :-)

Installation went smoothly with 3.1.0. Thank you!

Hi @bernhardjust installed a brandnew PW with https://github.com/processwire/site-regular/blob/main/README.md site profile on a local ddev with PHP 8.1. First thing I wanted to install was RockMigrations. After going to Modules->Site->Add New and pasting in the class name and clicking on Get Module Info, I got an exception: DEBUG MODE BACKTRACE ($config->debug == true): #0 /var/www/html/wire/core/Modules.php(688): ProcessWire\ProcessPageEditImageSelect->init() #1 /var/www/html/wire/core/Modules.php(1455): ProcessWire\Modules->initModule(Object(ProcessWire\ProcessPageEditImageSelect), Array) #2 /var/www/html/wire/core/Modules.php(1262): ProcessWire\Modules->getModule('ProcessPageEdit...') #3 /var/www/html/wire/core/Modules.php(1712): ProcessWire\Modules->get('ProcessPageEdit...') #4 /var/www/html/wire/core/WireArray.php(1789): ProcessWire\Modules->find('alsosetincompos...') #5 /var/www/html/wire/core/WireArray.php(583): ProcessWire\WireArray->findOne('alsosetincompos...') #6 /var/www/html/wire/core/Modules.php(1913): ProcessWire\WireArray->get('alsosetincompos...') #7 /var/www/html/wire/modules/Process/ProcessModule/ProcessModule.module(1166): ProcessWire\Modules->isInstalled('alsosetincompos...') #8 /var/www/html/wire/core/Wire.php(419): ProcessWire\ProcessModule->___buildDownloadConfirmForm(Array, false) #9 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___buildDownloa...', Array) #10 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessModule), 'buildDownloadCo...', Array) #11 /var/www/html/wire/modules/Process/ProcessModule/ProcessModule.module(1080): ProcessWire\Wire->__call('buildDownloadCo...', Array) #12 /var/www/html/wire/modules/Process/ProcessModule/ProcessModule.module(340): ProcessWire\ProcessModule->downloadConfirm('RockMigrations') #13 /var/www/html/wire/core/Wire.php(413): ProcessWire\ProcessModule->___execute() #14 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___execute', Array) #15 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessModule), 'execute', Array) #16 /var/www/html/wire/core/ProcessController.php(350): ProcessWire\Wire->__call('execute', Array) #17 /var/www/html/wire/core/Wire.php(413): ProcessWire\ProcessController->___execute() #18 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___execute', Array) #19 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessController), 'execute', Array) #20 /var/www/html/wire/core/admin.php(160): ProcessWire\Wire->__call('execute', Array) #21 /var/www/html/site/templates/admin.php(16): require('/var/www/html/w...') #22 /var/www/html/wire/core/TemplateFile.php(328): require('/var/www/html/s...') #23 /var/www/html/wire/core/Wire.php(413): ProcessWire\TemplateFile->___render() #24 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___render', Array) #25 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\TemplateFile), 'render', Array) #26 /var/www/html/wire/modules/PageRender.module(575): ProcessWire\Wire->__call('render', Array) #27 /var/www/html/wire/core/Wire.php(416): ProcessWire\PageRender->___renderPage(Object(ProcessWire\HookEvent)) #28 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___renderPage', Array) #29 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\PageRender), 'renderPage', Array) #30 /var/www/html/wire/core/WireHooks.php(1060): ProcessWire\Wire->__call('renderPage', Array) #31 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\Page), 'render', Array) #32 /var/www/html/wire/modules/Process/ProcessPageView.module(184): ProcessWire\Wire->__call('render', Array) #33 /var/www/html/wire/modules/Process/ProcessPageView.module(114): ProcessWire\ProcessPageView->renderPage(Object(ProcessWire\Page), Object(ProcessWire\PagesRequest)) #34 /var/www/html/wire/core/Wire.php(416): ProcessWire\ProcessPageView->___execute(true) #35 /var/www/html/wire/core/WireHooks.php(952): ProcessWire\Wire->_callMethod('___execute', Array) #36 /var/www/html/wire/core/Wire.php(484): ProcessWire\WireHooks->runHooks(Object(ProcessWire\ProcessPageView), 'execute', Array) #37 /var/www/html/index.php(55): ProcessWire\Wire->__call('execute', Array) #38 {main} Other module installs I tested (ProcessWireUpgrade, ProcessDatabaseBackups), went fine. Don't know if this is related to the site profile or your module. Just wanted to let you know.

Rollbar can be initiated without setting it's own error handler. https://docs.rollbar.com/docs/basic-php-installation-setup But thanks for your concern.