adrian

Not if your field is set to only store the date, and not the date and time. ie, if it looks like this: In this situation, the date gets stored as: 2015-05-5. There is no way to store a date (without the time) as a timestamp. So when you go to "find" using a selector, you need something like: $pages->find("date<".date("Y-m-d")); or: $pages->find("date<today");

Hi Bernhard, I finally made some time to add a validator panel. At the moment it only works with live sites because I am using the standard "doc" method for sending the URL to the validator.nu service. If you guys are interested in a version that also works with local dev sites, let me know and I'll add that too - looks like it's possible, but this was the easiest way to get started to see what you think. The debugger icon is changed based on the report so you have a quick visual of the result. The panel is not enabled by default. Anyway, let me know what you think.

But you mention above that your index has a line 254:

Someone else has seen this error: https://processwire.com/talk/topic/957-how-to-find-elements-with-empty-field/?p=8041 Maybe there is something in that thread that can help to narrow it down for you.

Try check_access=0 in your selector: http://cheatsheet.processwire.com/selectors/built-in-page-selector-properties/check_access-0/ foreach ($top->children("check_access=0") as $child)

Hi, and welcome to the forums! When paginating, you need to put the date check in the initial pages selector. You should do that anyway because it is much more efficient to only get the pages you need in the first place, rather than getting them all and limiting later on. $allNews = $page->children("template=news, date<=".strtotime('now')); Keep in mind that I think you also have another issue - using strtotime('now') or time() will always get all articles. You want to be comparing date to date, not date to a timestamp.

Maybe you have simplified your example, but why not simply do this: echo "<div class='container inner-{$page->switchColor}'>"; or to take care of no selection: $switchColor = $page->switchColor ? $page->switchColor : 'green'; echo "<div class='container inner-{$switchColor}'>"; PS I think you might actually be looking for $page->switchColor->value or $page->switchColor->title but I would need to confirm as I haven't used the Options fieldtype very often. Look at the docs: https://processwire.com/api/modules/select-options-fieldtype/#separate-option-values

https://github.com/ryancramerdesign/ProcessWire/issues Why not make article_snippet_video required? Your hook will take care of the image if the video field is required.

A few comments - I think this is a PW bug and should be reported. Do you really need to make the field required? If you are populating the image automatically, then how could it be empty? You should only save the field, not the entire page - this way the save hook won't be triggered again, so do this: $page->save('article_visual_snippet'); Just looking for maxresdefault.jpg will bite you at some point because not all YouTube videos have this image - this is why in my module (http://modules.processwire.com/modules/process-get-video-thumbs/) I look through all the possible options so you will always get something.

https://processwire.com/talk/topic/383-module-import-pages-from-csv-file/?p=119390

I know this thread is old, but happened to notice someone browsing it today so I thought I should "close" this now that the Users page in the admin uses the Lister interface which makes it very easy to search and sort users.

No, I don't think it is the correct/desirable behaviour, but I thought it might explain why it was happening. That is correct - it should match an empty checkbox.

Hi Soma, Just taking a first look at this as I think it could be quite useful for a particular purpose. I have a wireCache that caches a query that takes several minutes to run. I have it set to never expire - the content driving this query only gets changed once a year, but when it is being changed, it takes many edits to many different pages, so I don't want the cache to be cleared by any rules. I just want to clear it once after all the data has been changed. I thought your module might be a nice way to do this, rather than manually deleting the row from the caches table, but you have this: As found in the wire cache DB table except those that never expire. Is there any reason you are not listing those caches that never expire? I assume it is to protect the content? Could this be optional? I may end up going with a different approach because I think this module is too complex for client use anyway - of course awesome for devs which I assume is your target anyway. Still I thought I would ask because it still might be safer for me to be the one that clears that cache when it is time and your module would be a simple way to do this.

Hey kongondo, I have noticed an issue when using unpublished or hidden pages. Here is my scenario. I am using this custom php code as the row selector: return $pages->find("parent=/report-cards/{$page->parent->parent->name}/years/, sort=sort, include=all"); The "include=all" ensures that even though the latest year is unpublished (we are currently adding data and it's not ready to be live yet), we still see that year as a row in the matrix table. The problem is this line: https://github.com/kongondo/FieldtypeMatrix/blob/master/InputfieldMatrix.module#L439 //remove matrix-rows that are no longer needed i.e. 'unpublished', 'hidden', 'deleted' or 'trashed' if(!$rp || $rp->is(Page::statusUnpublished) || $rp->isHidden() || $rp->isTrash()) continue; Even though data is saved to the db, that line prevents it from being displayed in the matrix table - you enter and save, but it appears blank. For my needs I have commented this line and it seems to be working fine. I am not sure of the best fix - perhaps this line is simply not necessary or maybe it needs to be an option? The same issue occurs with columns as well. Please let me know if I haven't explained properly or if you have any other questions. Thanks!

Nice one. I also employed a little trickery in my EmailNewUser module, although I took a slightly different approach. $this->addHookBefore('InputfieldPassword::processInput', $this, 'removeRequired'); public function removeRequired(HookEvent $event) { $event->object->required = false; //hack to remove required status so that automatically generated password can be added on save }

Did you see the Issue at the end of that thread: https://github.com/ryancramerdesign/ProcessWire/issues/378 - this was supposed to be fixed Feb 2014. Are you using a really old version of PW? If not, it might be worth adding a comment to that issue to say that there are still issues.

Just make sure you run Modules > Refresh after renaming and they will work again. The reason I think it's important is so that you can use the Upgrades module to upgrade all your modules to new versions easily. And in future if you install using the ClassName or the zip (via URL or upload), then you won't ever have to deal with the "-master".

I just committed a new version - it now ignores pages under admin and trash. Before it just excluded pages with the "admin" template. I think this should take care of the problem with WireQueue. I also fixed a bug with images being blank in RTEs when you haven't manually specified the max number of images for the images field that is used.

First question - how are you going to handle the editing? The pub/unpub/trash are easy, but if editing you need to figure out if they will get a modal popup for editing there, or if they will be redirected to the admin for this. You might want to take a look at these modules: http://modules.processwire.com/modules/front-end-edit-lightbox/ http://modules.processwire.com/modules/fredi/ As for the pub/unpub/trash - there are a few ways to tackle this - I think the first thing you need to decide on is whether you want it done via ajax, or whether a page reload is acceptable. If the latter, then you can simply have a link like: http://mysite.com/change-status/?pid=1001&change=trash The template file for the change-status page would contain something like this: if($user->hasRole("required-role")) { $p = $pages->get((int) $input->get->pid); if($p->id) { if($input->get->change == 'trash') { $p->trash(); } else { if($input->get->change == 'unpublish') { $p->addStatus(Page::statusUnpublished); } elseif($input->get->change == 'publish') { $p->removeStatus(Page::statusUnpublished); } $p->save(); } } } Then you'd want to redirect back to the main dashboard page using $session->redirect() Personally I'd prefer an AJAX approach. I would make use of jquery for this and call the above page via: $('#trash').click(function(){ $.get( '/change-status', function( data ) { //code to update status in dashboard Of course there is more to it than that, but maybe you already know your way around jquery and ajax so I'll leave you to figure that bit out.

Sorry, it just occurred to me that that was a rather useless answer You'll probably want to make use of the API and do something like this: $p = $pages->get("page to alter"); $p->addStatus(Page::statusUnpublished); $p->save(); You could put this inside a conditional that checks that the user has the correct role/permission. You may also want to do it based on the passing of a get or post variable so it can be part of your existing template file. Hopefully that will get you started but let us know if you have any specific implementation questions.

It sounds like you are assuming that the file compiler works like a cache converting the values of these variables into hard values at the time of compilation? As LK and ryan mention, this is not the case - the file compiler is really just for dealing with Namespace issues (although it can be used for other things like tags compiling). The key thing is that the resulting file is still all php with variables intact.

@shamus - sorry for the delay in getting back to you - I have made a start on investigating this and improving the importing in general - stay tuned! @Robin S - I posted about this here: https://processwire.com/talk/topic/10517-frontend-password-reset/?p=119386 - it's a bug in the Password Reset module, but I have implemented a check in BCE that will prevent the error - instructions on how to implement are also in that thread.

The unknown template error is due to a bug in the settings for the password-reset template. 67 password-reset 121 0 0 {"childTemplates":[120] There is no template with an id of 120 in my system. 120 refers to the fieldgroup for the password-reset-request template, rather than the id of that template itself. This is the culprit: https://github.com/plauclair/PasswordReset/blob/master/PasswordReset.module#L279 That said, I have added an additional check to BatchChildEditor so the error won't occur. I am currently working on some other changes to BCE so I won't commit this fix just yet, but you can do it yourself by changing: https://github.com/adrianbj/BatchChildEditor/blob/master/BatchChildEditor.module#L711 if(!$this->isAllowedTemplateAdd($templateId, $pp)) continue; to: if(!$t->id || !$this->isAllowedTemplateAdd($t, $pp)) continue;

Did you test AdminRestrictBranch with 2.4 or are you just basing it on what it says in the modules directory? If you did test and got an error, could you post for me - maybe it will be an easy fix - no promises - I don't want to spend a lot of time making it work with such an old version of PW, but if I can help, I will.

Take a look at the links for the action buttons in the admin. To unpublish for example, looks like: http://pw.dev/processwire/page/?action=unpub&id=1005 Presumably the users with access to these links will be logged in and their role will have permission to perform these actions?