Soma

What I have since the update to latest dev is this on the very bottom of the admin "pages tree" screen... as mentioned before I thought it was only once but suddenly appeared again: Warning: date() expects parameter 2 to be long, string given in /home/.../wire/modules/Fieldtype/FieldtypeDatetime.module on line 370 Which appears random it seems and I can't reproduce why, but wasn't there before the update.

I quickly looked at the repo and no it's far from good or standard or how it should be or can be. There's just a site folder with modules folder inside that contains a Fieldtype module that is a separate module from another guy. I'm not sure why this module is in the directory and it also isn't installable by ModulesManager for example. I'm sorry as I mind sound patethic, but I always said that we should have clear guidlines how modules repos should be built and that there must be some quality assurance for modules posted to the official directory. This doesn't happen and makes me a little sad. (just a quick glance $pass = $this->sanitizer->text($this->input->post->pass); Just wrong to sanitize passwords...) /rant

BTW I thought I openend an issue with date fields but maybe haven't. But surely mentioned it in some threads that the date fields get saved with a 1970 timestamp 0 which I ran into when checking dates and empty dates. Hopefully it is now fixed.

I have very latest dev from yesterday which fixes cache delete problem. But the problem was today, BUT there was something happening on date field after updating PW on first load... could be that this page I tested still got an issue with it. As since changing values it doesn't happen anymore.

I've testing the scheduler and I had this morning a strange behavior for a page I was testing yesterday where only the publish from is filled with a datetime past the current time. The scheduler is set to 2min. I had the page unpublished and tried to see it would get published and this was what I got in the log for this page: It was getting published and then unpublished at the same time... 2013-12-04 10:30:27 guest http://removed/ Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages) 2013-12-04 10:30:27 guest http://removed/ Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 10:30:27. (SchedulePages) 2013-12-04 11:01:58 guest http://removed/ Published /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages) 2013-12-04 11:01:58 guest http://removed/ Unpublished /de/medien/medienmitteilung/2006/2006_12_22_mm.php/ with publish_from value of 03.12.2013 16:04 and publish_until value of . Current timestamp is 2013-12-04 11:01:58. (SchedulePages) Really strange. And I was trying to find out but couldn't. I set the published_until and tested again but seems like it is gone away. I blanked the publish_until again and still couldn't get the behavior as before. I tested with other pages but no luck. BTW I added before all testing, the suggested text fix you mentioned some posts earlier #180 if($p->publish_until <= $currenttime AND $p->publish_until > 1) I'm not sure what was causing it, and hope it's not something that will give surprises later

Checkboxes are 0 or 1 not "checked".

Ok. Coincidence, as there was an dev update just an hour before I posted this thread which seem to fix this cache problem for me. Will test a litte more but definately the cache gets deleted now correctly it seems

Template caching seems to be just borked... I let PW create a cache file: It is created correctly /5055/4c81f131016c84203e1525aef538e4ed.cache Soo far so good. I go to save the page 5050 (id) and there's no deleting happening, not even a message (only for parent pages, but they don't actually get deleted..) I go to the server and rename the file to: /5050/5050.cache then go to save the page again in admin, and suddenly the 5050.cache gets deleted correctly! So has anyone got template cache working at all or is using it? This is using latest PW dev. Edit: I'm using language support with 3 languages, and I can see it's creating cache for each language like: 4c81f131016c84203e1525aef538e4ed.cache 4c81f131016c84203e1525aef538e4ed_1013.cache 4c81f131016c84203e1525aef538e4ed_1014.cache Also I noticed that the cache files time on the server is 1 hour behind of what a timestamp in php would return.

Anyone has good experience with template caching? I have set the cache for a template, and set the page to clear cache on save and all parents above including homepage. When I save a page I get the message like: Session: Cleared cache file: /home/.../site/assets/cache/Page/1040/1040.cache But the file on server is still there! And the file is not /1040/1040.cache but /1040/4c81f131016c84203e1525aef538e4ed.cache Further more I don't see a message for the current page I save, that the cache file gets deleted, which is confusing again. So when I view the page 1040 which is a parent page I still get the cached file. Permissions are not a problem on server at all and I'm confused and lost to why it doesn't work. Any ideas? Once it would work: Apart from that: How does this work when I save the page via API? Would it also delete all the cache files according to the cache setting?

RE: Ahhh, I think I found what the problem is. It's that I have template cache enabled for most pages. Any ideas how to make it work with cache enabled? If that makes sense at all Edit: Need to analyse this a litte if this is a problem at all. If at least some pages are not cached, or cache gets newly created for any of the pages, it should trigger tha lazy cron. So I can see this is not as much if a problem as I first thought.

I installed this modules as I have a need to a scheduler, thanks for all the work put into it. I have a problem that the scheduler doesn't run then visitors visit the site. It only runs when I am logged in. This doesn't make a lot of sense, and I'm suprised that nobody run into this? Any ideas? Also it would be nice when installing if it would check if fields already exists and only try to create them if not present. I already had them created beforehand with the same names (lucky) without knowing I would install this module. Also when deinstalling the module I'm not sure It should try to remove the fields at all ,even if the fields are not used on any template anymore. Maybe the dev wants to keep them. Thanks

Any news if the issue is solved with this?

I'm not sure what version you got, but the p tag wasn't missing closing tag, but it was wrong and not needed. Thanks for mention. I pushed a little update with other small fixes.

Also worth noting that the same selector works when you enter custom php code for a page field: return $pages->find("template=user, roles=company, sort=name"); But there's a note in the source code that : if($field->findPagesCode) { // TODO: we don't currently validate these }

Using the ID here works. I'm not sure what's wrong, cause the selector using the "roles=name" obviously works to find the pages and they are the right users. So they should also be valid! Try this script as a testcase in a template to see what happens: $selector = "template=user, roles=company, sort=name"; $pa = $pages->find($selector); foreach($pa as $p){ echo "user: " . $p->name; if(!$p->matches($selector)){ echo " (not valid)<br>"; } else { echo " (valid)<br>"; } } gives me user: testuser1 (not valid) user: testuser2 (not valid) Also using subfield doesn't give valid pages $selector = "template=user, roles.name=company, sort=name"; only changing selector to using the id of the role works $selector = "template=user, roles=1027, sort=name"; Seems strange to me that matches doesn't valid pages that are returned using find() using the exact same selector.

They are the same. Like with first, child or children. Both version can be used. They're for convenience.

No sorry, I have no idea currently. Any more hints to how you set up or reproduce? Where do you get these errors? Invalid file extension, please use one of: .... (one of what?) Are the file extensions set correctly for the image field? Missing required value, means there's no image sent... ?

I'm not sure "guest" user has or should have anything to do with default language! (but maybe it could (?)) As said when using LanguageSupportPageNames, the front end language is controlled via the requested url and not the user language set in the backend. So if you access site with /de/somepage/ the user language is set to "de" (or whatever this is) and the system spits out all stuff in this language: page values, urls etc. Regardless of the pw user's language. Also worth mentioning that "default" is something that you can define what language that is, so you can easily set default to be german and throw in the language pack on the "default", so default is what you make it. BUT, I'm really not sure what the best option would be for this special case of the "home" page, but surely not something that doesn't let me control it. I wasn't really aware that the module makes assumptions and redirects me to "/" when I access "/de/" (being the default language). It should be possible to go to /de/ and actually stay there. So some configuration on this behavior would be welcome. So I could do my own redirect from "/" to a language I wish. Or maybe control it simply by being able to define one of the languages as the default? (I'm sure this might as well not easy possible the way Ryan implement all this) I think Ryan is still ear to such stuff as he's also not so experienced with languages and it should be possible to adjust those things to better suit what people need.

Hm, there was something going on when Ryan implemented LanguageSupportPageNames about the language segment /de/ /en/ which is something that not really is needed when using this localized urls, but some think it would be nice to still be able to have them. This was when he made "home" page name configurable which normally without this module has no page name. I thought it would be possible to have the default language i.e /de/ be possible, but it looks like it's not, as it will redirect you to "/" root. I've not used this feature since LanguageSupportPageNames came out and wasn't aware, sorry. I'm not sure what you could do right now but the code that does this is in #294 if($page->id == 1) { // special case: homepage //$name = $isDefault ? $page->get("name") : $page->get("name$language"); $name = $isDefault ? '' : $page->get("name$language"); if($name == self::HOME_NAME_DEFAULT || !strlen($name)) return '/'; return "/$name/"; } If you uncomment this line //$name = $isDefault ? $page->get("name") : $page->get("name$language"); And comment out the line $name = $isDefault ? '' : $page->get("name$language"); This would allow you to redirect and stay there like "/de/" or "/en/". But further more this will also automaticly redirect "/" to the default "/de/" and you can't change it really again. So to make "en" default you would have to redirect again. This might be possible with some hook magic, but this seems rather silly. Since the line is still there I think Ryan was also unsure what would make the most sense and how to behave for the home page if segments are set or not, and I think some configuration should be possible to define the behavior of the special case.

Ok then if you have url segments set for both languages I just would redirect from root domain to what you want the language to be when domain.com is accessed. From there the user is free to change language. I do this in a lot of projects ever since creating multilanguage websites and don't really see why this is bad. Everything fine here. Only I see problems for in case of pw the default language is used as a fallback and for labeling the admin backend .. so if that's a problem there is no easy way out. but usually also not something that you just change and should be considered well from the beginning.

Maybe it would help to clarify what language approach you use and what you expect from saying "default" language. Also what pw version. Just not sure what the thinking here is and it's just there's a ton of factors and also ways to handle language on front end. It's correct that guest user has nothing to do with admin or editor and is just the public not logged in user that visits your site. But depending on how you handle fronted language changing guest user doesn't have any effect unless you explicitly use it for defining language on frontend. In case of LanguageSupportPageNames the language is set by what url you request and the user language set in backend is then ignored. So theres no default language unless you take another approach. Also worth mentioning that default language has its role as it can be used for label and language fields as the fallback value if alternative language has no value. So there's some things to consider when building multilanguage sites. You could also just swop the language packs and rename the alternative language but usually once setup its almost impossible to change everything or becomes a burden as you would need to also change all values of fields and related stuff.

When we at least get field/fieldset dependencies on repeaters I think it has shown that this could be one possible more or less solid way to go. I see them as nice to have and only for where it really fits the needs and maybe not all and everything should bebuilt using them. There's also Hanna code or Wysiwyg solutions. Or sometimes child pages do well. Using a dropdown (page select or custom select) to switch between "fieldset", using dependencies (showIf), that represent a set of fields. This works out and would let you specify a couple (not unlimited) at max maybe 5 or little more block types. So you can benefit from a already existing interface and system with repeaters for searching them or creating them. They lack some features people requested and generally make sense to have them with repeaters (limit, title etc), it looks like it just takes some time for Ryan to catch up. So I think the two options I see Options1 Rely on the repeaters and give them some love Option2 Build a proprietary system that will be quite complex (at least for me) to build and would have to be well built and thought out, I'm not sure it would end having something like repeaters anyway I would probably go option 1 route Although you can't use repeaters inside repeaters and also but most of the time if it gets this far there would have to be a custom fieldtype for such cases that fit. I also think searching them can be either easy or hard depending how many types there are. But really this solution should only be used to build blocks with mainly text and images maybe video or galleries and not to build calendars or directories where other approaches are better suited. I still use child pages for articles that require block layout and some options, although they're leaf pages on outmost level of tree so having child pages isn't that much of a problem, but still would like to get rid of them for various reasons we all know.

$c = $page->children->eq(1);

Little update 1.1.1 added live search filtering, fuzzy text search only on name, author, categories and action some minor refactoring