MSP01

Sending images using "$mail->AddEmbeddedImage" works well from frontend, but if I run the same code from backend the image will not appear in the email. First I thought content-type was the problem (for some reason it changes from multipart/alternative to text/html when sent from backend), but after I fixed it the problem persists. In this case I send an email based on data on a page. Email can be sent by filling a form on frontend, but also through backend by using checkbox and saving the page. Image in question is saved on another page.

I have a template file where I need to set $page->of(false) and then save a variable in a field. This seems to break the frontend, specifically combo fields. Settings the $page->of(true) after saving doesn't seem to do anything either. How to does one fix something like this, or is $page->of(false) something that shouldn't be used inside a template file? I'm pretty sure I've done this a lot in the past without running into issues with it. Edit: Some additional information. The saving is done inside a function where the page is passed to. $page->of(false) and $page->save() seem to work fine, but $page->of(true) does nothing. I've solved this temporarily by putting $page->of(true) right after the function call, but it seems like bit of a hack.

Is the code in a template file and does that template use pw-regions? I had a problem where a form was defined as variable at the top of a template file outside of the pw-regions, and then echoed inside a region later on on the same file. This caused it send mails twice each time someone used the form.

Now a questions, is it possible to hook language strings in the same manner?

I recently ran into the same problem. I tried to auto-activate the other languages in a saveReady hook, but it didn't work even though changing the hidden status inside the same hook works fine. Anyone got any advice on this?

@horst This could work, but I'd rather keep things very literal. A check box that says "don't show this page to certain people" is more clear than setting them hidden. @Robin S I could of course do that, but I'd really rather not. There are a lot of these pages, and there's a lot going on under the hood. I'd have to change code all over the place and it's what I'm trying to avoid in the first place. Sorry if it seems I'm trying to find the most difficult way to do a simple thing. If there's no easy fix via hook, I'll just do it manually in the code. ? It's also possible there will be need to hide pages from more than one group while showing it to other groups in the future and Horst's suggestion wouldn't work in that case. Neither would the template. Or at least I wouldn't want to create a new template every single time something like that came up. It seems like a very heavy way of doing something that should be handled within a page itself.

I have a template that is used on many pages, but some of those pages need to be disabled from guest users. An addHookBefore('Page::render'...) works fine for throwing a 404 if someone actually gets on the page. But is there a way to disable those pages in site navigation, and any other place where they might be visible in one fell swoop? I thought that addHookAfter('Page::viewable'...) could work, but I haven't been able to make it do anything at all. Basically I'd love to have a way to disable those pages without going through every single $pages->find() and similar piece of code where those pages might crop up. Using access rights would be the easy way, but I cannot change the template and most of those pages are public.

Thanks Robin, that worked perfectly.

I'm trying to make a simple module to help handling some specific pages. There's a simple dashboard and under that a page with ProcessPageLister, like the simplified example below. public function ___execute() { // Dashboard } public function ___executeBrowser() { // Browser $browser = $this->modules->get('ProcessPageLister'); return $browser->execute(); } Problem is when you use the pagination ProcessPageLister creates, you end up in Dashboard instead of staying inside the "Browser". What should I do to make this work correctly?

This is more general question but relates to need to add external file manager to PW's CKEditor (earlier message below). We have managed to call Responsive Filemanager in CKEditor, but the server is giving Server error 403 since I believe PW's .htaccess is blocking external PHP files. There is a PHP file dialog.php which have to be called in plugin config to run Responsive Filemanager plugin. Is there (a safe) work around this? Should it be run outside PW or some javascript solution?

Pretty straightforward selector string: $pages->find("template=whatever, name=pagename"); This works fine on default language, but if I change language it will only find pages if name= matches the name on default language. To find the page on second language, I need to add the language id after the name field like this: $pages->find("template=whatever, name1013=pagename"); Where 1013 is the id of the second language. Version of PW is 3.0.184, all the usual language fields and modules are enabled nor did I find anything weird in the backend. Anyone got any ideas?

Ah I see, I have a hook that auto generates names for these pages so that was the culprit. Checking for status 'trash' before doing the name change solved this problem.

Alas it was pretty fruitless: Array ( [restorable] => [notes] => Array ( [0] => Page name does not contain restore information ) [parent] => ProcessWire\NullPage Object ( [id] => 0 [name] => [parent] => [template] => ) [parent_id] => 0 [sort] => 0 [name] => [namePrevious] => [name1019] => [name7200] => [name7201] => [name7752] => [name7753] => [name7754] => ) How ever if I just echo $trashedPage->name; I will get out the data as usual.

Hello, I have one particular template that cannot be restored from trash. The hover menu that appears next to pages only has options Edit and Move. Trying remove the Trash status by api gives an error when you try to save the page "Call to a member function numChildren() on null". Trying to restore the page via api does nothing at all. Anyone else ran into something like this? PW version is 3.0.184.

Are you refreshing the page right after you have manually submitted a form? If so then that's pretty normal behavior for forms and doesn't really have anything to do with Processwire. One way to stop it is to redirect to another page after the form submission. But if you don't want to redirect, this little piece of javascript should stop it from happening. Place it at the end of the page where the form is located. <script> if ( window.history.replaceState ) { window.history.replaceState( null, null, window.location.href ); } </script>