rick

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?

Exactly. That is the crux of the problem here. It's not any different than the other module developers here selling pro versions. Unscrupulous people will always find a way to circumvent licensing. The best you can do is trust the customer to honor your license models. You save the license id, transaction id, or whatever id for future reference. It could be in a database or a spreadsheet so that any inquiries from a customer can be checked against that database for validity.

Basically, the simplest solution, for example, is to use something similar to paypal's 'buy now' buttons; one for each license type. It really doesn't matter about a specific license ID unless you want to identify a particular user when they request support, etc., and then you can pass a unique ID which is returned with the transaction confirmation. In this example, you don't need to mess with any type of license key entry in your module; The customer just downloads the module from an email link. You insert the 'transaction id' in the email for their records that you can compare with your database entry at some future date. I know my replies seem somewhat 'negative' toward a viable solution and I apologize for that. On a positive note, one method I used many years ago was to keep certain 'key' functions on the server. The program would pass the license key and specific data to be processed on the server. If the license was valid, then the result was returned to the program for further processing. Again, this requires a 'phone home' procedure, which most people, including myself, don't really like.

That is a question I've been working on since the mid 90s. There is no simple solution when dealing with publicly viewable code. Generating a unique key is straightforward (eg, GUID, etc.). Validating the key requires a 'phone home' procedure, whether you do it on install or every time the code is executed is a choice to make. The problem lies with controlling the source code execution based on that validation. It is not possible to accomplish that with publicly viewable code.