Unable to access the config setup page

[mbrett5062]

Just downloaded, installed and tested 2.5.10, all works fine. Then installed ProcessWireConfig as instructed, all seemed to go OK, then went to access the page under admin/setup/config and get an error.

"The connection was reset The connection to the server was reset while the page was loading." thats in firefox, and in IE "This page can’t be displayed".

I have checked the database and everything seems to be there, so no idea what is going on. Everything else still works.

One other thing I had to do, Superuser was not granted permissions automatically, so I manually set that, but still no way to access the page.

[mbrett5062]

One more thing, I am getting no errors, warnings or messages in processwire logs. And the only thing I get in PHP logs is the following which is unrelated i think.

"PHP Warning: json_decode() expects parameter 1 to be string, array given in C:\xampp\htdocs\lpwideplank\site\modules\ProcessWireUpgrade\ProcessWireUpgradeCheck.module on line 57"

[DBPreston]

I'm having the same problem that mbrett5062 reports.

config.json is not being created although assets/config/ is. In common with mbrett5062, I'm on Windows - could the problem be filesystem related?

[mbrett5062]

Quick update, I have now pushed this up to my development server (Unix) and it works there, so this is beginning to look like a windows issue.

[ryancramerdesign]

Usually when there's an error that seems to only be occurring on Windows, it has something to do with the directory separator of "\" vs. "/". But thus far I can't find anything in the code that would indicate that's the problem here. I did just commit an update that does more logging to /site/assets/logs/errors.txt, hoping that this might give a clue as to a possible read/write permission issue. What PHP version are you guys on?

A couple of other things that might be worth trying by editing the ProcessWireConfig.module.php file:

• Temporarily put a return true; at the top of the checkLoaderCode() method. Does the tool start working?
• At the end of the getConfigFileName() method (before the return $file;, add die($file);. Reload the page in your browser, and it should exit with just the json filename. Anything unusual about it?

[DBPreston]

I'm on PHP 5.3.8.

Even with the latest version, there are no errors logged.

Trying a temporary return true; doesn't do anything.

Adding die($file); outputs 'D:/wamp/www/sitename/site/assets/config/config.json', which looks ok (Windows normally translates '/' into '\' behind the scenes) - the path is correct and copy & pasting 'D:/wamp/www/sitename/site/assets/config/' into an Explorer window does open the directory. The actual 'config.json' file doesn't exist.

[mbrett5062]

I have PHP 5.5.9 local and 5.4.35 on dev server (Inmotion)

Will try your update now on local windows machine.

[mbrett5062]

Tried updated module, nothing in error log still. Tried both module code changes, first does nothing different, still not working. Second gives the following output

C:/xampp/htdocs/lpwideplank/site/assets/config/config.json

But that file does not exist in that directory.

[mbrett5062]

I have tried to debug this in PhpStorm, not sure if this is even relevant, but the debugger stops at the same place every time. Whilst walking through the regex pattern matching in getConfigOptions. It processes 1. SYSTEM MODES & 2. DATES & TIMES & 3. SESSION & 4. TEMPLATE FILES. Then as it starts 5. FILES & ASSETS it fails immediately. See 2 screenshots below, as I step through. There is no third step.

[mbrett5062]

Just received this notice when i went to the module settings page on my dev server that seems to be working.

ProcessWireConfig::getModuleConfigInputfields() or ProcessWireConfigConfig->getInputfields() did not return the expected value (InputfieldWrapper)

[horst-n]

Hi, I have the same problem, on Windows 7 with PHP 5.4.26

I have debugged till the point that mbrett5062 has found. Line #170 calling getConfigOptions($data) and to the Line #93 preg_match_all($re, $data, $matches);. Here it breaks with $data of section 5.

Then I have removed all items from that section and added one after the other. The page breaks after adding the comment and config key for $config->pagefileExtendedPaths = false; If I let this one out, I can add the next one $config->fileContentTypes which works fine. But with the next one it breaks again, the `$config->imageSizerOptions.

Also if I let out those breaking parts above, the code breaks again at Line #177, $items = $this->getConfigOptions($top);

I have not investigated further.

[ryancramerdesign]

Thanks for the great debugging help guys, this is really helpful. Though it's quite a mystery. A regex that is causing a fatal error in Windows but not on Unix... I'm not aware of any differences between the two platforms that could account for that, but there must be something. Do you guys know if it is PHP thats halting while executing the preg_match_all() function, or is execution halting sometime after that? I sure wish I could reproduce it here. But it's super helpful that you guys have narrowed it down to that regex. I'm going to focus in on that regex and see what can be adjusted.

Just out of curiosity what PCRE version do you have with your PHP? You can tell with a phpinfo(); call. My PCRE version is: 8.34 2013-12-15. If it turns out there's something common to your PCRE versions, that might help me to research if there are any known issues and how to workaround them.

[horst-n]

PHP 5.4.26 PCRE Library Version 8.32 2012-11-30

Directive Local Value Master Value pcre.backtrack_limit 1000000 1000000 pcre.recursion_limit 100000 100000

I have no entries in Apache error.log nor in PHP error.log. Also there is no entry in the access.log.

[mbrett5062]

PCRE 8.32 2012-11-30 with PHP 5.5.9.

And it halts as soon as I step into the preg_match_all()

[mbrett5062]

I have now updated my local XAMPP package and the new one includes PCRE 8.34 2013-12-15

Still not able to access the admin/setup/config page on Windows 8.1

[ryancramerdesign]

Thanks for the testing. I'm still not able to determine what this could be, so am working on re-writing the regex, which so far makes it more complex, but hoping to find something that'll work.

[mbrett5062]

Ryan, hope this can be of some help. Using the tool available online at https://regex101.com/

I have tested and corrected your regex's to return what I think you were trying to achieve (Main issue was with unescaped delimiters "/" should be "\/"

Here is the resulting regex's and what what was returned in each case as reported by that tool.

Line 92 (getConfigOptions)

$re = '{\/\*\*((?:[^\/]|[^*]\/)+?@var +([a-z]+)[^\/]+?)\*\/.*?[\s\r\n]+\$config->([_a-zA-Z0-9]+)\s*=\s*([^;]+);}s'; 

First Match ` * Enable debug mode? * * Debug mode causes additional info to appear for use during dev and debugging. * This is almost always recommended for sites in development. However, you should * always have this disabled for live/production sites. * * @var bool * `
            `bool`
            `debug`
            `false`

Line 161 (getConfigSections)

$re = '{[\r\n]\/[*]{3} (\d+\. [^*\r\n]+) .+?(?=[\r\n]|$)}s';

First Match `1. SYSTEM MODES`

I hope that is of some help. I will modify and test now, let your know the result shortly.

[mbrett5062]

Ryan, sorry ignore the second regex there, here is correct for Line 161 (getConfigSections)

[\r\n]\/[]{3} (\d+. [^\r\n]+)[].+?(?=[\r\n]\/[*]{3}|$)

[mbrett5062]

Ryan and horst-n, I finally got this working maybe this will help you too horst.

The issue was a two fold thing I think. As I stated Ryan, your regex needs to be amended for both options and sections.

Just to be sure there is no confusion here are the one's that work for me perfectly.

Options

$re = '{\/\*\*((?:[^\/]|[^*]\/)+?@var +([a-z]+)[^\/]+?)\*\/.*?[\s\r\n]+\$config->([_a-zA-Z0-9]+)\s*=\s*([^;]+);}s';

Sections

$re = '{[\r\n]\/[*]{3} (\d+\. [^*\r\n]+)[*]*.+?(?=[\r\n]\/[*]{3}|$)}s';

And finally, I noticed that I was getting some PHP errors once i had the regex's working correctly.

Parent: child process exited with status 3221225725

Searched online and found this page http://www.codexpedia.com/apache-server/parent-child-process-exited-with-status-3221225725-restarting-on-xamp-apache/

The solution there is for Windows only and is as follows.

Add to bottom of httpd.conf the following

<IfModule mpm_winnt_module> ThreadStackSize 8888888 </IfModule>

And finally all works as expected.

[ryancramerdesign]

Thanks for all the help in debugging this! I really appreciate your efforts here.

Regarding unescaped delimiters, PCRE lets you choose your delimiter. The slash "/" is the typical regex delimiter, but if you need to use slashes in your regex, you usually choose another delimiter to keep the regex readable (escaping things makes it harder to read). Since we're using { and } as open and close delimiters, the slashes are not supposed to be escaped. From php.net: "If the delimiter appears often inside the pattern, it is a good idea to choose another delimiter in order to increase readability."

For the first regex, were there any other differences? I couldn't spot any but my coffee still hasn't kicked in either. :)

For the second regex, the only difference I found beyond the escaped slashes as replacement of [*]{10} with [*]*. These two have different meanings. The first/original statement says "10 asterisks required here" whereas the replacement says they are completely optional "zero or more asterisks". We actually need the "required" part for at least 10 asterisks because otherwise it has potential to identify things as sections that aren't intended to be sections. Though it looks like either will work in the current /wire/config.php, but I think it might be good to keep the additional specificity unless you think this may have been somehow connected to the error you are seeing?

That was some excellent work tracking down the ThreadStackSize issue! I would not never found that. But also I'm not sure I can expect everyone on Windows to change that setting. Unless there's a bug in the Windows version of PHP (?), the issue couldn't have been the slashes, so am thinking it must have been this ThreadStackSize the entire time? I'm not sure what about the regex is incompatible with that ThreadStackSize, certainly there are much more complex regexes that occur in PW. But currently thinking I need to rewrite the regexes in a manner that doesn't trigger that issue in Windows. I'll start by breaking up that first regex into two parts, or maybe forego the regex completely and replace it with a lot of strpos() and substr() calls... which would be a pain, but if it avoids the issue it's worth it.

[ryancramerdesign]

The latest update I've just pushed replaces those two regexes completely with regular string functions. I'm hoping this will fix the issue on Windows. Let me know if you are able to try it? Thanks.

[mbrett5062]

Ryan of course you are completely correct. Changing the regex was not required and was not the issue. My bad, I did not understand regex enough and of course the tool i was using defaults to "/" as the delimiter, it could be changed and when I did it worked. Also my change from [*]{10} to [*]* was not required, that was just my naivete.

As for the TreadStackSize that was indeed the real issue. On Windows it is set at 1Mb and most others (Linux and such) 8Mb.

Here follows the answer from Stackoverflow site.

This problem happens more often on Windows platform, because of smaller Apache's default stack size. There is 1 MB default stack size on Windows, unlike 8 MB on Unix/Linux platforms. It could be a reason, why some for example PHP scripts works properly on Linux, but cause crash of Apache on Windows.

Furthermore, the crash is silent (segmentation fault), there is no error message, Apache just stops responding and the child process is restarted. Browser gets no data and renders a blank page, so it's a bit difficult to decide what's wrong.

It's a common problem when working with long regular expressions in PHP.

There is one notice in Apache's error log only, which tells, that child process crashed:

Parent: child process exited with status 3221225725 -- Restarting

The best way to alter the Apache's stack size is using the ThreadStackSize directive in the Apache's configuration file. There is a description of the ThreadStackSize directive in Apache's documentation: http://httpd.apache.org/docs/2.2/mod/mpm_common.html#ThreadStackSize

So increase of the Apache's stack size on Windows might looks like this:

<IfModule mpm_winnt_module> ThreadStackSize 8388608 </IfModule>

These lines should be put in the Apache's configuration file. For simplicity, you could put it to httpd.conf. Or better (but not necessary), put it to httpd-mpm.conf file and in httpd.conf uncomment this line:

Include conf/extra/httpd-mpm.conf

It sets Apache's stack size to 8 MB, so it's the same as a default value on Linux.

And don't forget to restart Apache! :)

[mbrett5062]

OK Ryan, I am going to test your recent change now as well whilst commenting out the TreadStackSize change for reference.

Shame that the setting for ThreadStackSize is not the same across the board anyway. But like you say, getting all Windows users to make that change may not be the best way to go.

[mbrett5062]

Have now commented out the change to TreadStackSize, then overridden module with the latest here. Restarted Apache and tested the functionality. I can now access the page on Windows. This issue is now closed as far as I am concerned, however I think i will keep the TreadStackSize change also, and request at Apache Friends that they include that change by default.

Ryan, would you like to close this issue now or should I?

[horst-n]

@mbrett5062: Wow! Many thanks for finding this ThreadStack-thingy! Also it isn't needed here with v 0.0.3, I have added it to my Apache. :)

@ryancramerdesign: The 0.0.3 works just fine now.