adrian

https://processwire.com/blog/posts/processwire-3.0-alpha-2-and-2.6.22-rc1/#new-module-file-compiler-tags

Sorry - another minor improvement. You now have "Once" vs "Sticky" options. "Sticky" behaves like the previous version - the selected panels will remain until you reset or close the browser. The new "Once" option will only change the panels for the one reload that happens when you click the button. This should make it even easier to quickly view a panel you rarely need like PHP Info for example.

Latest version adds a "Panel Selector" panel to the debugger bar. I added this because I noticed that the overhead of having all panels loaded all the time can sometimes be a few seconds depending on the server. With this new feature you can pare down the main "Show Panels" module config setting to just the ones you want all the time and then use this new panel to quickly and easily enable additional panels for a specific purpose without having to go to the module's settings and mess with the defaults. The changes to the list of panels is stored in a session cookie, so as soon as you close the browser (or you use the "Reset Default" option), you'll return to your default set of panels. Hopefully you'll find this speeds things up for you. On this note, if you are finding things slow you may want to consider the config setting for switching to the stable version of the Tracy core (this was mentioned several posts ago, but in case you missed it, it can make a huge difference. Hopefully the Tracy guys will come up with a solution (https://github.com/nette/tracy/issues/157) for the master/dev branch before it is marked stable). I am also going to do some code review on all the panels in an attempt to speed things up - I am sure there are some things I overlooked in initial development that can be dramatically improved. Let me know if anyone has any ideas though.

Check out this: https://processwire.com/docs/tutorials/troubleshooting-guide/page3 I am guessing it's a rewritebase issue

I really love the enhancements you show horst - showing the names and filtering will be very helpful. This can be done automatically via CustomUploadNames (http://modules.processwire.com/modules/process-custom-upload-names/), but I would also like to the option for manual renaming in the core.

A small, but hopefully useful timesaver - I have added a new method: TD::debugAll() debugAll() da() This will output the content via all dumping/logging methods: barDump(), dump(), fireLog(), log() This can come in handy when you want the expandable tree that you get with barDump, dump and fireLog, but also want to store in a log file for later comparisons. It can also be useful in AJAX calls or some other instance when you're not sure if barDump / dump will work or not, or if there is a page redirect which causes them to disappear from fireLog / dump Obviously this will be a little slower (depending on the complexity of what is being dumped), so maybe don't use it by default, but it's as another useful timesaving tool in your arsenal. Note - you'll need to enable the debugAll() and da() shortcuts in the config settings.

Hey Pete - be sure to post about this in the Tracy support thread so I can take a look. It works out of the box with the settings as they are. For more info though, be sure to check out the blog post: https://processwire.com/blog/posts/introducing-tracy-debugger/

I decided to go ahead and make the validator work with local dev sites as well (note the local ".dev" domain in the results). Also note that the validator is now using the html5.validator.nu version when it sees a HTML5 doctype declaration. Note the colored "cross" icon indicating some errors.

Apologies - you are correct - I don't think I ever realized PW did that. If you look at the database tables for a date field (without time) it is stored as Y-m-d, so I guess I assumed it would return just that. Note that it returns the timestamp for 12:00:00AM GMT that day. By contrast, a datetime field is stored as a timestamp so I would expect a timestamp to be returned as the unformatted value.

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.