cstevensjr

Please try more than one web speed testing tool

https://github.com/ryancramerdesign/ProcessWire/releases/tag/2.3.0

The important thing is that the emails are processed and work. I believe if wireMail() is working then this module is working (as it uses wireMail()). If you could open an issue on Github, the module creator/maintainer can have a look at the issue you are reporting.

Just so we don't keep going back and forth, you need to run some type of pagespeed test to see where the bottleneck is occurring. Here are one of a few online sites that can do that for you: https://www.iispeed.com/pagespeed/test https://developers.google.com/speed/pagespeed/ https://varvy.com/pagespeed/ https://gtmetrix.com/analyze.html Some have a YSlow or Waterfall tabs that will show you where things are dragging. That is where you want to put your resources towards decreasing the page load. Additionally, using some type of caching will help the response time. ProcessWire has a myriad of caching solutions, to include the paid ProCache option.

Are you using File or DB sessions?

Please tell us some information about your PW install? Is there any type of caching/CDN being used? Thanks.

Can you please provide some information regarding your setup for this website (versions of PHP/ProcessWire, type of hosting used, the hosting provider/or whether local hosted)? Have you followed the instructions from your hosting provider regarding SMTP setup details, if not locally hosted?

You beat me to it, I had just read the article

You can change the amount of minutes to show. If you add more minutes, it will likely show some information.

Please review this Stackoverflow thread http://stackoverflow.com/questions/18537887/mamp-localhost-resolving-very-slowly Also, please look at this ProcessWire Forum thread https://processwire.com/talk/topic/8805-slow-admin-localhost/

It would be very helpful to the troubleshooting effort if we knew what versions you are running (PW, PHP, MySQL, etc....). Any other specific information regarding your installation would also be beneficial. Thanks.

Please look at the following post for possible help https://processwire.com/talk/topic/8805-slow-admin-localhost/

The key is your post max size must be larger than your upload max size, per the PHP manual. Right now you have both at the same exact size. I don't know if that will resolve your issue, however the PHP manual says that it must be that way.

post_max_size integer Sets max size of post data allowed. This setting also affects file upload. To upload large files, this value must be larger than upload_max_filesize. Generally speaking, memory_limit should be larger than post_max_size. When an integer is used, the value is measured in bytes. Shorthand notation, as described in this FAQ, may also be used. If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. <form action="edit.php?processed=1">, and then checking if $_GET['processed'] is set. Note: PHP allows shortcuts for byte values, including K (kilo), M (mega) and G (giga). PHP will do the conversions automatically if you use any of these. Be careful not to exceed the 32 bit signed integer limit (if you're using 32bit versions) as it will cause your script to fail. Changelog for post_max_size Version Description 5.3.4 post_max_size = 0 will not disable the limit when the content type is application/x-www-form-urlencoded or is not registered with PHP. 5.3.2 , 5.2.12 Allow unlimited post size by setting post_max_size to 0. http://php.net/manual/en/ini.core.php

Related Thread https://processwire.com/talk/topic/11078-specific-php-selector-for-pagefield-dont-work/#entry103774

https://processwire.com/docs/tutorials/default-site-profile/

From Southern California (via Time Warner Internet link) From Southern California (via AT&T Internet Link) As an aside, hopefully your customers aren't getting your website confused with this one which is medstarlabs.com versus medstarlab.com Best Regards, Charles

Of course GoDaddy can see the website (it's local to them, they pushed or received the DNS change, they have multiple high capacity links and the affected website is at one of their facilities). Of course register.com can see the website (they pushed or received the DNS change and have multiple high capacity links). Other people (your users throughout the world) won't see the new website until the probable DNS propagation issue is resolved. That's the most likely situation for this issue, however it's still most likely a hosting provider (ISP) problem and there could be other configuration issues. The propagation of DNS information could be affected by many reasons (for the users who cannot see the new website).

Sorry, I wasn't very detailed. i actually meant you or the hosting provider (ISP) needs to flush the DNS cache from the cPanel (or it's equivalent). On some hosting providers, you can do it yourself (i.e. DreamHost). Normal DNS propagation takes at least 72 hours or longer. It all depends on where the actual server is located, that's why some see the website where it's been moved to and others still see the old DNS information. There are times where due to traffic congestion or other router issues, the updated information doesn't make it everywhere (across the world) in a timely manner. Flushing the DNS cache will restart the process and usually things will start working as required. You are correct that you need to work with the hosting provider (ISP) to clear this up. GoDaddy support should have been on top of this, since they are hosting the website now. Please open a trouble ticket with them and good luck.

The only thing I would recommend is to flush the DNS cache for that domain.

If you are actually having a problem, could you please be more specific and detail what your issues are? Thanks.

There is a Github page dedicated to this Module (Beta).

Please open a ticket with the hosting provider to resolve this configuration issue.

The Title field should already be on the template you are trying to add fields to (that's why it's greyed out).

I have liked the Default theme from the beginning and I also think Reno is a great alternative. I use the Default theme all of the time. Occasionally, I will use the Reno theme just to make sure any client using it won't have any issues. My clients have never had a problem with using the Default theme. Some of them do like the Reno theme and some of them are more comfortable with the Default theme. I like the fact that you actually have a choice in ProcessWire and certainly wouldn't mind if there were more alternative themes.