adrian

Sorry about that - I have just committed a fix that I think should take care of it. Please let me know if it works for you now. Not sure why you got that error, but I have never seen it - maybe a PHP version difference? Also, note that it requires PW dev due to the way I set up the module info in a separate file.

PW 2.5 (https://github.com/ryancramerdesign/ProcessWire/tree/dev) will be released within the next couple of weeks. Many of us have been using the dev version in production with no problems. It always pays to test though, so if you don't have a test server setup, rename your existing wire folder to wire-old or similar so you can revert quickly should there be any problems.

Sorry that didn't work. I think I must not be fully understanding the setup you have, because that should work. Can you please show us the selector you are using to define $menus ?

If it's a multiple select page field, then you either need to convert it to single select, or grab the first one: $menu->pagereference->first()->url;

Maybe you're right - maybe I shouldn't worry about it - maybe it really doesn't matter how messy it gets in there

I believe Wanze's solution to the filesystem limit problem has been added to the dev core: https://github.com/ryancramerdesign/ProcessWire/issues/432#issuecomment-40951719

I think this will fix it: $newsposts = wire("pages")->find("template=254_news_article,limit=5,sort=-published_date,start=0"); Note the addition of start=0 - this is to override the insertion of start from the pagination code.

Hey Martijn, I managed this by using the automatic naming option and by setting the title field to hidden and not required in the template context settings (so it doesn't affect other templates) and that seems to be working ok. The one thing I am really missing (and maybe this is just me) is for the PageTable sub pages to be stored in some sort of hierarchy when using an alternate parent page. I can see a complete mess of hundreds of pages ending up in there, with various -n name appendices. Maybe it would be unnecessary extra cruft, but what if sub parent pages (named to match the actual page that uses the PageTable field) were made to store the PageTable pages. e.g.: Home ----About (has a PT field called Sections) ----Portfolio (has PT field called Jobs) PageTableItems (hidden) ----About -------Sections -----------Section 1 -----------Section 2 -----------Section 3 ----Portfolio -------Jobs -----------Job 1 -----------Job 2 instead of the current situation of: PageTableItems (hidden) Section 1 Section 2 Section 3 Job 1 Job 2 I know the latter looks simpler, but I can see it becoming a mess and confusing when page names were automatically changed to avoid conflicts. Anyone agree, or am I on my own

Hey teppo - one minor enhancement I made locally is to add a "View Page" link next to the "Edit Page" option (it also only shows on hover). I think it makes a nice enhancement - would you considering adding it also? By the way, there is an errant </em> tag on the line where the edit link is created. Thanks.

Is that because you are wanting to replace, rather than add to the list of action buttons? If so, try: $event->replace = true; If not, can you explain a little better what is and isn't working?

Quick response here, but I think what you want is $subPage->render(); You may also want to check out PageTable as an alternate option: https://processwire.com/talk/topic/7459-module-pagetableextended/

Antti - thanks for suggesting the cache field option here, but it still feels a little clunky to me. Seems to me that if I add a PageTable field that has a body subfield, and my site search selector includes the body field as a field to search, then PW should return pages that contain a PageTable field with a matching body subfield automatically. I think the current situation will catch people out and their search system won't work as expected. Maybe it's just me?

Can you work from Nico's Delete button module where he adds a delete action after edit, view, new: https://github.com/NicoKnoll/ProcessPageDelete/blob/master/ProcessPageDelete.module

http://processwire.com/api/variables/session/ Another simpler option is to use a tabbed interface approach where both views are loaded, but one is hidden, like this: http://jqueryui.com/tabs/ If you are using a css framework, they usually have something built in for this. Keep in mind that this might not be a good idea depending on the size/complexity of the content being rendered in the grid. Here is an example of how to load tabs using ajax, which would avoid the above mentioned issue: http://stackoverflow.com/questions/14361211/jquery-tabs-use-url-to-load-ajax-content

Does anything from this post from Ryan help: https://processwire.com/talk/topic/4011-cannot-login-to-admin-area/?p=39870 In particular: disable the "session fingerprinting" option in your /site/config.php and change the default session name from 'wire' to whatever PHP's default is: $config->sessionName = session_name();

Sorry if my suggestions came across as doubting / obvious - just wanted to rule some things out. It might be the session issue - of course 755 doesn't mean much if the owner/group doesn't match the apache user. Maybe try making it 777 temporarily to see if that fixes things and then worry about what it should actually be, based on your server config.

Do you actually end up at the login screen with username and password prompts, or does it say "Continue"? If the latter, then it sounds like the user you are trying to log in with does not have edit permission. Of course this doesn't really make sense as the admin user that gets created during install has superuser permission automatically. But you could dig around in the DB tables and make sure the user has edit permission, or just programmatically add it. Sorry, maybe someone else will have a bright idea

You can always create a new user and/or set a new password for an existing user via the API. Lots of examples of the latter here in the forums: https://processwire.com/talk/topic/490-how-to-reset-your-password-how-to-enable-the-forgot-password-function/

The config file contains access details for the database (including the host) - is that what you are talking about? I don't think that is related to what -aj- is asking. I think he is just referring to his superuser account for logging into PW. Am I confused maybe?

The link from PW weekly is to a specific post in this thread where Ryan describes all the ProFields, including the new free PageTable field (last in the list in his post). PageTable is in the core, but not installed by default, so go to Modules > Core and scroll down to PageTable. Install it, then create a new field and you'll have a new option "PageTable" when choosing the field type. Hope that helps to clear things up

What bwakad lists for usernames is correct - no symbols are allowed. However, symbols are allowed in passwords. So, I am guessing the installer doesn't let you know that it has replaced the symbols in your username with dashes. Can you take a look at the name field in the pages table (via PHPMyAdmin etc) to confirm that the username has been changed from what you entered, and does the login work fine if you try it with the altered name?

Minor, but important update today. This morning's commits to PW 2.4.17 made the password field required for new users, which broke this module when using the automatically generated password option. I just submitted a fix for this. Please let me know if you have any troubles.

There is a new field type (PageTable) in the dev version of PW which will be released as 2.5 probably in the next week or two. There isn't much documentation on it yet, but there is already a cool extended version of it that will help you to visualize how it can work for exactly the scenario you are talking about: https://processwire.com/talk/topic/7459-module-pagetableextended/

There was some discussion about Sir Trevor, starting at this post: https://processwire.com/talk/topic/4189-flexibility-in-page-design/?p=46536

I guess I am mixing purposes a bit here - your goal was to style the output exactly as it will appear on the frontend, but I guess I am looking more for replicating the ease of editing that repeaters have. Maybe I'll make a different extension for PageTable that works more that way. Maybe not worry about the ajax saving and just use the page save to save each of PageTable components. I'll mull over it for a bit.