Robin S

Maybe the arrows could float right next to the Save button? Besides not moving so much between pages, on the default theme it would also have the benefit of less confusion with the breadcrumb separators (which look quite similar).

Thanks for the speedy implementation!

Could you just pass null as the title argument in that case? Or is that just as much hassle? Looks great to me.

Maybe remove the space between the label and the dump output? Ryan does that sort of thing all through the core so I figure it's not too hacky.

Hi @adrian, What do you think about adding a way to label dumps in the console, similar to what is possible with barDump? So you could do: d($foo, 'Foo'); d($bar, 'Bar'); This would help to identify which dump is which.

Not working in what way? Your files are listed but in the wrong order? It looks like it should work.

That reminds me of when I first came to ProcessWire. My impression was that PW was really powerful so I expected it to be difficult to use and so I thought "I'll only use PW for really complex sites that need it". But as soon as I had built my first site I knew I was never going to use anything but PW from that point on, even for basic brochure sites. Once you have understood the basics then development with PW is super fast. For developing custom sites (i.e. excluding off-the-shelf themes tied to a specific CMS, and who wants to work on those anyway?) I think PW is the fastest, most intuitive and most elegant framework out there.

The templates folder is at /site/templates/, so it's still within /site/. I don't recommend changing any of the security restrictions in the PW htaccess file.

Just a correction to this (from the docs):

PW blocks direct access to PHP files within /site/ Alternatives are to place your PHP file outside of /site/ (e.g. in the root directory) or to use a PW template/page to respond to your AJAX request. The latter would be nice solution in this case because you could use an images field in the template to hold your animation images.

I spent my first seven years of life in Canvastown and have fond memories of that area (Pelorus Bridge especially). A beautiful spot.

Got it. If you have ProFields then Table could be a good alternative to a Repeater that avoids the overhead of extra pages. A PageArray is not a type of field, but several fieldtypes return their value as a PageArray. Repeater, PageTable and "multiple" Page Reference fields all return PageArrays. I think you are meaning a Page Reference field. If so, did you manage to get it working? I tested it and you should be able to match the title of a page inside a Page Reference field inside a Repeater with: authors.authors_name.title%=$q_word

You could use WireArray::getValues() to get a regular array (with a zero-based index) of your team players: $teamPlayersArray = $teamPlayers->getValues(); Edit: another possibility that keeps the team players as a PageArray: $teamPlayersReindexed = new PageArray(); $teamPlayersReindexed->import($teamPlayers);

I think that is because in that example you are adding files to the repeater page. A page has to be saved before you can add files or images to it.

Your code copied from the GitHub issue: $options = wirecommerce_get_all_variations($page); $variations = $page->wirecommerce_variations; // Detect added $added = 0; foreach($options as $option) { if(!$variations->has("wirecommerce_variation_value='$option'")) { $new_option = $variations->getNewItem(); $new_option->wirecommerce_variation_value = $option; $new_option->save(); $added++; } } if($added > 0) $this->message("$added variations added."); The code example for adding a repeater item from the documentation: $building = $page->buildings->getNew(); $building->title = 'One Atlantic Center'; $building->feet_high = 880; $building->num_floors = 50; $building->year_built = 1997; $building->save(); $page->buildings->add($building); $page->save(); So I think your code should be: $options = wirecommerce_get_all_variations($page); $variations = $page->wirecommerce_variations; // Detect added $added = 0; foreach($options as $option) { if(!$variations->has("wirecommerce_variation_value='$option'")) { $new_option = $variations->getNew(); // Or getNewItem(), they are the same thing $new_option->wirecommerce_variation_value = $option; $new_option->save(); $variations->add($new_option); $added++; } } $page->save(); if($added > 0) $this->message("$added variations added.");

I think Ryan is talking about setting the sort on the parent page of the repeater page, not for a template. So you locate the parent page under Admin > Repeaters and set a sort on the Children tab. But... this doesn't work because when setting an automatic sort like this it doesn't actually change the "sort" value of the pages in the database, which is what a repeater field uses to determine the sorting within the inputfield. A related post that might be useful:

@alan, you might be better off using a mod_rewrite rule than using Redirect, because then you can use the [L] flag to avoid the other rewrite rules affecting the URL. So instead of... Redirect 301 /my-short-cut http://example.com/the/long/page/to/go-to/#theAnchorIwant ...try... RewriteRule ^my-short-cut$ http://example.com/the/long/page/to/go-to/#theAnchorIwant [R=301,NE,L] ...just after... RewriteEngine On

How do you mean? The test is if the user doesn't have the permission then the contenteditable attribute does get removed.

@gmclelland, turns out it is a piece of cake with str_replace. Create a custom permission "rename-images" and give that to roles that you want to allow to rename images. Then add the following to /site/ready.php $wire->addHookAfter('InputfieldImage::renderItem', function(HookEvent $event) { if(!$this->user->hasPermission('rename-images')) { $event->return = str_replace(" contenteditable='true'", "", $event->return); } });

Sure, but I suspect that if you look at the code that creates the inputfield markup there will be nothing hookable that lets you change that attribute in isolation. And it might be a long time before such a thing gets implemented in the core given the number of existing feature requests. Often you just have to do what you can to solve this kind of thing yourself. Edit: if there's nothing else in the inputfield with the contenteditable attribute apart from the name fields you might be able to do a string replace on the markup returned from InputfieldImage::render to strip out that attribute. Pretty hacky but no more so than the JS approach I guess.

An idea on how you could achieve this: Add a body class in admin according to the user's role: This has also been added to AdminOnSteroids if you are using that. Then add a custom javascript to ProcessPageEdit that selects .InputfieldImageEdit__name inside a particular body class and removes the "contenteditable" attribute from the inner <span>. You'd put this into a function and have it fire on domready and ajaxcomplete events.

@gmclelland, I just figured it out by clicking around as you replied. Cool, I had no idea that was possible!

How do you rename images through the admin UI? I wasn't aware that was possible.

The login details for your superuser account must be coming from somewhere. One place they might be coming from is your browser in the form of a saved login. Do you get the same problem if you access this page from a different browser that has never been used to login to your superuser account? In this line here... if(/* !$user->isLoggedin() && */ $input->get->confirmcode && $input->get->confirmcode == $session->get("confirmcode")){ ...I see that the check to make sure the user is not already logged in is commented out. So I wonder if you might already be logged in as superuser at this point. Does your header or footer contain a login form that might be getting auto-filled with your superuser login details?

I don't think WireException is involved there. What you are seeing is a fatal error message from PHP, and you can't "catch" a fatal error AFAIK.