Pages being created with URL name of 0

[tigerchops]

Bit of a weird one. I've got an install of processwire that has developed an interesting (read: infuriating!) issue.

So, this wasn't always the case, but now when you create new pages, they are given a URL name of 0. The jquery is succesfully filling in the field on the Add a Page screen, and the name value is definately being passed on to ProcessPageAdd ( I echoed it out to make sure ) but somewhere beyond that it is being changed to the number 0. (Ok so technically speaking 0 is not a number but whatever  )

Obviously this is causing issues as now if you create another page on the same level under the same parent page, it throws the following error:

"TemplateFile: Duplicate entry '0-5766' for key 2 INSERT INTO pages SET parent_id=5766, templates_id=40, name='0', modified_users_id=2, status=2049, sort=3,modified=NOW(), created=NOW(), created_users_id=2"

The interesting thing is that if you go back to edit the previously created page with URL name 0, and change the URL name to something more suitable, when you save it it now gives it a URL name of it's page ID. Only if you go back and edit a second time will it keep whatever string you give it as a URL name.

Yeah.... what?

So, to illustrate what is happening with an example:

Lets say I create a child page of my page called Blog. I call it "Test Post".

As I type this in, the field below (URL name) is automatically filled with the slug: "test-post".

However when I save the page, and check under the settings, I see that the URL name is given as 0.

So, I manually change it to "test-post" and press save.

I look again and it is "5567" - the page id.

So I change it once more and this time it sticks.

Any thoughts? Where should I be looking for the problem?

[ryan]

That is definitely strange. There is no connection between the page ID and page name, so it's particularly odd that your name field is getting populated with the ID. It almost sounds to me like the browser is mixing up the fields. What browser are you using?

Also what version of ProcessWire is this? (2.0 or 2.1) and how recently did you download it? Do you have any 3rd party modules installed?

You mentioned that it developed this issue. Does that mean that it wasn't doing it, and then it started recently? If so, can you think of anything that changed, whether in your PW install, the server, or the browser you are using to access it?

[tigerchops]

Thanks for getting back so quickly!

I doubt it is a browser issue, it occurs with Firefox and Chrome, and with debugging on it shows the $_POST array to contain the right string being passed as the name variable.

It's processwire 2.0.0, must have downloaded it a few weeks ago?

Yes, it wasn't doing it from the start (and I have not encountered it with other installs) - I've been racking my brains to think what I could have done! I haven't installed any modules, I haven't mucked about with any files other than my template files.

I am fairly sure it must be an issue with the server, one, as it seems like it can't be much else, and two because I've had issues with it in the past. I know that it will be difficult for you to help with this but maybe you can point me to the right area.

Basically anything that needs permissions to run system commands like mkdir, chmod etc have always been tricky to get working. It's not a question of file permissions as they are all set correctly  - basically we always have to run a script called phpcgi and for some reason that helps. So anyway, I was having problems initially with creating new pages etc as it didn't have the ability to create the folders for their assets. This was fixed by running the above script. I suspect that this issue showed up sometime after that.

Hopefully you can help, but I understand if not!

From my earlier poking about I know that it passes the name variable correctly to ProcessPageAdd.module so presumably something goes awry when it calls the save method:

$this->pages->save($this->page);

Thanks again.

[ryan]

Can you PM or email me a link to your phpinfo? I want to get a look at your PHP and MySQL version. This would be a URL to a file like "test.php" that contains nothing but this:

<?php phpinfo(); 

Or if you know the versions already, post in here.

If your versions are good, one thing you may want to try is to download a new copy of PW and replace the /wire/ directory with the one from the new copy. Just in case there is a corrupted file or something off in that commit, that will at least correct it.

If that doesn't do it, you may want to look at running a database repair. If you have access to PhpMyAdmin, view the database being used by PW and "check all" the tables, and select "repair" in the select box at the bottom.

If neither of those do the trick, can you post list of your field names and template names?

[tigerchops]

Unfortunately neither seemed to help: I have repaired all the tables, and replaced wire with a fresh download.

My Field Names are as follows:

body

buy_button

date

documents

extracts

headline

image

images

media

process

quote

reviews

sidebar

slideshow

summary

synopsis

time

title

And my Template names:

admin

blog

book

books

event

event_parent

home

page

post

search

sitemap

I will pm you now with a link to my phpinfo!

[ryan]

The field names look fine. In the past there have been a couple of reserved words that I'd forgotten to reserve in the system, so just wanted to make sure we weren't running into something like that. I will keep an eye out for your phpinfo and then reply here as soon as I get a look at it.

[ryan]

I got a look at your phpinfo and nothing jumps out as a known problem (versions look good, etc.). It's a mystery so far. I've seen this problem when the PHP version was less than 5.2.4, and that's one of the reasons why that's the minimum version required by PW. But you are running 5.2.17, so no problem there. If you want to set me up with a temporary PW superuser login and FTP, I will be glad to go in and find where exactly the problem is. My email is ryan at the domain name of this site. Or if you prefer, I can tell you how to debug it yourself. We should be able to find out where it's happening relatively easily since it's apparently either in ProcessPageAdd::processInput() or Pages::save(). So it's just a matter of inserting: "die($page->name);" until we find the location where it's changing from the actual name to "0", and there aren't many lines of code to test here. I'm confident we'll be able to find a fix.

[tigerchops]

Good call, wish I'd thought more about that earlier, and identified where the issue is happening. This is what I found:

In ProcessPagePart.module, in the method processInput:

$nameField = $form->children->get('name'); 
$name = $nameField->value; 
if(!strlen("$name")) {
    $this->error("Missing required field 'name'"); 
    return false; 
}
$templatesId = (int) $form->children->get('template')->value; 
$template = $this->templates->get($templatesId); 

$this->page = new Page($template); 
$this->page->parent = $this->parent; 
$this->page->name = $name;
$this->page->sort = $this->parent->numChildren; 

If I pop in a:

die($name);

The correct string is returned;

However, if I use:

die($this->page->name);

nothing is returned. If I use print_r instead of die, it prints out 0.

So it looks like this is where it's having problems. I am more than happy to give you access if you want to have a look about? Or do you know what is causing it now?

[ryan]

Was the die($this->page->name) placed after this line?

$this->page->name = $name; 

For example, I'm wondering what this would do:

$this->page = new Page($template); // existing lines
$this->page->parent = $this->parent;
$this->page->name = $name;

var_dump($this->page->name); die(); // add this line right after the above

Trying to determine if $this->page->name is "0" after specifically setting it.

[tigerchops]

Yes, I was placing it after the name should have been set. Using the line you suggest i see:

int(0)

[ryan]

That's interesting. So it sounds like it's failing in the Page::set() method. In this part near the top:

case 'name':
    if($this->isLoaded) {
        $beautify = empty($this->settings[$key]);
        $value = $this->fuel('sanitizer')->pageName($value, $beautify);
        if($this->settings[$key] !== $value) $this->trackChange($key);
    }
    $this->settings[$key] = $value;
    break;

Following the path of calls, Sanitizer::pageName() is the next place to look. It's in the file /wire/core/Sanitizer.php. I've got my eye on these lines:

if($beautify) {
    $value = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value);
}

$value = strtolower($this->nameFilter($value, array('-', '_', '.'), '-'));

Do you want to try removing or commenting out those lines and seeing if it makes any difference? I'm especially wondering about the iconv(), and if it might be returning something different on your server.

[tigerchops]

We must be getting closer!

If I comment out the if statement in Sanitizer ie:

/*if($beautify) {
    $value = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value);
}*/

Then the page is created fine...

If I do:

if($beautify) {
    $value = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value);
    var_dump($value);die();
}

I see: string(0) ""

[ryan]

Thanks for testing that. It looks like the iconv() is the culprit then. The strange thing is that I just compared my phpinfo() to yours, and our iconv() versions and settings are identical.

Looking on php.net, it sounds like some people are reporting  strangeness with iconv when combined with "//TRANSLIT//IGNORE" in some rare instances. But they were able to solve it by swapping the order to "//IGNORE//TRANSLIT". Do you want to try that?

Replace:

$value = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value);

With this:

$value = iconv("UTF-8", "ASCII//IGNORE//TRANSLIT", $value);

If that doesn't do it, then then you can remove that line entirely. It's only there to provide better translation of accented characters and such, and it's not required. If you take it out, it'll just replace unknown characters with dashes rather than trying to translate from UTF-8 to ASCII.

[ryan]

Btw, if we find that swapping the order of translit//ignore doesn't do it, then I'm going to modify the source to ignore the return value if it's blank, and instead use the value pre-iconv instead. That way it should ignore the iconv() on systems where it fails, but continue to use it where it doesn't. This is the first instance I've seen where it fails, but what turns up once it bound to turn up again. So while this sounds like a rare problem, I doubt it's unique to your server.

[tigerchops]

Unfortunately it seems that even with that swap, it still returns an empty string. I've altered the code to read as follows:

if($beautify) {
$iconvValue = iconv("UTF-8", "ASCII//TRANSLIT//IGNORE", $value);
if($iconvValue!="") {
	$value = $iconvValue;
} 
}

So now it is working well as far as I can tell!

Ryan, thankyou so much for your persistence and helpfulness. Silly things like this aside, Processwire is fast becoming my go-to CMS for all kinds of different sites, it's genuinely awesome.

Hopefully next time I'm posting on the forums I'll be contributing!

[ryan]

Thanks, I have updated my source trees to have the same update as yours, and will push to GitHub tomorrow. 

And thanks for the feedback on ProcessWire, glad you are finding it useful--at least, now that we can get it to create pages.

Ryan