rick

// after your loop if( array_key_exists( 'fieldname', $input->post ) ) { // add yes stuff to email } else { // add no stuff to email } or if( is_null( $form->getChildByName( 'fieldname' ) ) { // add no stuff to email } else { // add yes stuff to email }

@neophronYou already know this, I'm just thinkin' out loud. There are three ways to present a segmented data entry interface: 1) A single form with all data fields displayed and editable at one time on the same page. Data is visually isolated usually by framing. 2) A single form with multiple sections (ie, viewable tabs or steps). For example, step 1 could be personal info (name, address, etc.), step 2 could be product customization, and step 3 could be payment information. Having data segmented like this implies a sequential entry method where the user must progress in order. 3) Separate forms for each section (obviously uniquely named) on the same page. Forms are again visually framed. This is random in that the user may complete none or more sections (forms) in any order. Personally, I don't care for this method. I only included it because it can be done (not that it should be done). You say the 'designer' wants the form displayed in the uikit switcher. This sounds to me like they want the second option as they believe the data to be segmented and sequential. I believe Ryan has (or is working on) the Pro Forms module which handles a sequential method rather than coding it yourself. I remember seeing that topic from Ryan but I do not remember the status. Maybe someone can educate me of that status. The first two presentation options are standard practice but depends entirely on the type of information you are trying to obtain and how you as the programmer want the user to perform. For example, an academic test application might be better suited for the sequential method. Since the user should be logged in prior to accessing the form(s) you already have the 'account' information to which the form data belongs. Saving the data from whichever presentation method is easily done to that account via ajax and/or a normal submit function. <Off Topic> I put designer in quotes above because it takes me back many years when I did instructional design work. It is not the designer's job to state how the interface should function. That is determined by you and the SME (subject matter expert). Now if that designer is also the SME, then you're good to go. Otherwise, you should provide the designer with the guidelines to create the necessary interface based off your needs analysis. </Off Topic> Anyway, I hope all this blabberin' helps you some way.

Have you tried the actual path rather than docroot?

No. If both sites are now functional, then your hosting doesn't need special treatment.

As long as your virtual hosts file points each domain to the proper doc root, you should not have any issues moving domain2 over to the domain1 host and run it in a sub dir. I do this many times with clients. You may also need to update domain2 htaccess and config.

The "S" stands for stealthy 😄

Probably the easiest method would be having their clients each with their own page, and each report is it's own child page. One template for the client pages and one template for the pdf pages. You can add the necessary fields to the pdf template to facilitate searching. Personally, I shy away from building intelligence into a naming conventions. You might have your client person(s) doing the uploading select the client then select the pdf file, and enter any other necessary data associated with that report. If your client already has a data system from which the reports are generated at a specific interval, then you might tap into that workflow. You might also consider using the created user ids for access control. Your client has clients (customers). Each customer would be a user in the system. That customer user id is used for their page and subsequent report page. Now you can use the logged in user to determine which pages are accessible. Just some thoughts out loud.

When pages are automatically sorted on a field, the move option is still enabled. Attempting to move one of those pages results in the following error: Your sort was not saved because these pages are automatically sorted by 'fieldname' PW .179 PHP 7.4 Personally, I think the move option should be removed when a field sort is defined, rather than just catching this exception.

Make sure that your from address is the same as your user (login) address, and that you have the dns records defined as netcarver stated. On a similar note, I don't use mailinabox, rather an old squirrel mail install for linuxdude. It is a pita running your own mail server by keeping up with the spammers. And you will have spammers.

Can you edit the topic as solved so others know this is the place for answers to similar issues.

From your segment... $p->of(false); // output formatting should be off prior to editing page data. $p->singleImage->add($remoteUrl); //grab the image. $p->save(); $p->of(false); // page save resets output formatting, so turn it off again. $image = $p->singleImage->first(); //load up image that was just saved. $newFilename = $parentName . '-' . $childName . '.' . strtolower($image->ext()); $p->singleImage->rename($image, $newFilename); $p->save(); //save changes to page.

Do you have output formatting off prior to working with the page data? It's not shown in your snippet, so I'm asking if it was included above the code segment you posted.

Very nice photos!

Thank you.

I doubt it is an email server issue or wiremail issue. The logs show one email sent but yet you receive two. Correct? What email client are you using and do you have any rules defined for that email address?