Soma

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

So with the selector of above you could get the lastest modified date with $selArray = array( "id!=$config->adminRootPageID|$config->trashPageID|$config->http404PageID", "template!=admin", "has_parent!=$config->adminRootPageID", "include=all", "sort=-modified" ); $lastDateModified = date("Y.m.d H:i:s", $pages->get(implode(",",$selArray))->modified); // or $lastDateModified = date("Y.m.d H:i:s", $pages->findOne(implode(",",$selArray))->modified);

This should give you some understanding: $selArray = array( "id!=$config->adminRootPageID|$config->trashPageID|$config->http404PageID", // ID as in /wire/config.php "template!=admin", "has_parent!=$config->adminRootPageID", // excludes "admin" branch all children recursively "include=all", // all pages regardless of access and status "sort=-modified", ); $list = ""; foreach($pages->find(implode(",",$selArray)) as $p) { $date = date("Y.m.d H:i:s", $p->modified); $list .= "<li><a href='{$config->urls->admin}page/edit/?id=$p->id'>$date - $p->path</a></li>"; } echo "<ul>$list</ul>";

TextDomainHelper is just a rough Helper module I did for some guy helping with finding translations in admin and not sure of any side effects. I put TextDomainHelper.module in site/modules/ and it's still working. Then I installed it, along with ChromePhpLogger.module and I also get a timeout on ModulesManager. Other than what you mentioned but ok. Little testing, it seems the ChromePhp::log() output in TextDomainHelper.module to output infos is causing trouble. So it looks like ChomePhp is the problem here but no idea what exactly or why, maybe something with loading files from assets. Just can say that using ChromePhp logger in the admin (turned off in the module by default) works well with ModulesManager. But glad you found out why it wasn't working, I don't think you need TextDomainHelper anyway.

TextHelperDomain? You mean TextDomainHelper from my gists https://gist.github.com/somatonic/4520324 ? I'm not sure what this would have to do with the problems you have/had. ?

You can also populate a page field with a custom php code in the field settings and use api to fill dropdown with child pages of current page. Like context aware.

I have a custom css that positions the error below field with position absolute and some trickery. Custom required message I'm not not sure really is needed instead of a generalized message that it requires a value but see it being useful for certain cases.

Delete cache ... load page ... see if it created a new cache.

Oh and I gladly will accept any PR or help if anyone finds the time to implement those fixes. Currently short on bandwidth. No and I don't have any notices on php 5.3.