adrian

Hi @jmartsch - I haven't used TEF and Smarty, so not sure here - maybe @Wanze will have some more insight. If there is anything that can be changed in my module to help out, please let me know.

The latest version now contains three different versions of the Tracy core! Yes, it's a pain and I don't want to maintain them either, and hopefully I can ditch one of these versions shortly if PW's SessionHandlerDB module can be tweaked to work with Tracy - more details below. Stable (now the old 2.3 branch) supports PHP 5.3 and because PW supports 5.3, I'll keep this version included until PW shifts to 5.4. doesn't capture AJAX requests works with the PW core SessionHandlerDB module Master (this version is actually a version from a couple of months ago now) needs PHP 5.4 doesn't capture AJAX requests works with the PW core SessionHandlerDB module Latest (this is the current dev version, currently 2.4 - I'll keep this fairly up to date) needs PHP 5.4 captures AJAX requests it does NOT currently work properly with the PW core SessionHandlerDB module - there are db table field length restrictions, issues with the MYSQL max_allowed_packet setting, and it prevents the capturing of AJAX requests if it's installed. The errors can be fixed by tweaking your sql settings, but you still can't get AJAX requests working. Yes, the names of these versions are no longer correct. I will be changing these soon, but didn't want to do too much on this at once. I personally have decided to give up on SessionHandlerDB until it can be tweaked so that it doesn't break the latest version of Tracy. I find the features in the latest Tracy core worth it, but it's up to you guys what you want to do. I'd be curious to hear which version you decide to use. Let me know if you have any questions.

New version just committed that takes care of most of the problems/suggestions that @bernhard noted above. The console code is now also saved to LocalStorage as you type. I am also hoping that the conflict issue that @Macrura brought up is also fixed. Please let me know! PS - the issue with the garbled code in the "open in window" mode was very painful to fix, but at least I learned a lot more about the inner workings of ACE and the Tracy core from reading through the source code. I discovered a nice shortcut for when you want the "open in window" mode - simply SHIFT+CLICK on an icon in the debug bar to avoid going through the FLOAT mode first.

Thanks @Macrura - I think it should simply be a matter of assigning ACE to a different variable, rather than `editor` which is used in all the setup examples. I'll make this change for the next version. If you could keep an eye out for it and let me know if that solves the problem for you.

Yeah, it looks like this module really needs to move away from using Flourish. Anyone out there experienced with any good alternatives for reading emails?

Thanks - I have relinked them all. Looks like the id of each post has changed since the forum upgrade too. Seems like the upgrade process rewrote all the internal links, but I think any external links to posts will now be broken

Maybe this issue should be brought up the Flourish guys since that is where the error message is coming from. Perhaps the first thing to try is to replace the files in the flourishlib subfolder of this module with the latest versions from: https://github.com/flourishlib/flourish-classes Even though there haven't been many changes in a while, this module is still using an outdated version of fMailbox.php Would you mind replacing all these and seeing if it helps?

I would go for: require_once($config->paths->root . 'stat/config/tracking_code.php');

For security reasons you can't directly access php files under site/templates. You will either need to put it in the root of your site, or create a page in the admin page tree and assign it a template that is linked to the required php file.

You might also want to consider making use of PW's sanitizer, rather than simply using stripslashes. Maybe not worth changing at this point, but I would also recommend SwiftMailer over PHP Mailer. I don't honestly remember the reasons - it's been a lot of years since I first chose Swift, but it certainly seemed like the better choice at the time. Seems like they are both very actively developed now, so maybe it makes no difference. Actually, I think maybe the reason at the time was to do with being able to send multipart text and html versions together with proper mimetypes. Maybe PHP Mailer does that now too, or maybe it always did, but swift seemed so much easier.

You need to install the new ProcessTracyConsole helper module. This is installed automatically for new installs of Tracy, but for those upgrading, you need to manually install it. Because you can't directly call a PHP file from the modules directory in PW, it was either this or moving the file to the root of the site and I thought this was cleaner and potential less hassle for the user. Hi @bernhard - glad you're finding the Console panel so useful! Firstly, a friendly reminder about PW's each(): d($pages->find('id>1')->each("title")); Depending on your needs, that will give you much nicer output if you are testing a selector. Also useful is ->getArray() and ->getIterator() Back to topic now - thanks for pointing out the issue when converting the console into a new window - that is weird - hopefully I can fix it. Just a note that once the new window is open, it seems to manage the code fine after that. What I would really like is for Tracy panels to be drag resizable - maybe that's something I should request or build and PR them, but for now, I have made the console panel almost full width. This will be committed shortly, I just want to take a look at that weird code issue when opening in new window as well. Multiple consoles sounds pretty cool too, but probably not possible without core hacks, but maybe I can come up with something that achieves your needs in a different way. I am giving thought to the idea of a snippets manager so you can save and load snippets - this should certainly help in your case although may not be quite as convenient. Now that the console panel is full width, I think the snippets library can be in a sidebar on the right which should make it easy to switch between snippets. Thanks again for the feedback.

I get a 404 for that page on the front-end. By the way, you shouldn't be editing anything inside wire - the config.php file in there contains all the defaults. Just change/add settings from it to site/config.php to make changes.

Thanks for testing @cstevensjr @Werner Pilnei - are you running the site as https? Can you try having the cron call the standard http version of the url instead?

This morning's commits add to the color scheme: Red: The current page is using a different template. Orange: The current page is using it's default template file, but there are other pages on the site that are using a different template file (obviously via the Sticky option). Use "Reset All" to clear this when you're done testing. Green: All pages on the site are using their default template files. This is now documented on the blog post.

Or just trust the color of the template path icon in the Tracy Debug bar: Red: You have selected a different template file. Green: You're using the default template file.

Tracy to the rescue: https://processwire.com/blog/posts/introducing-tracy-debugger/#template-path-panel or you could place something like this in your site/ready.php file: if($user ......) { $page->template->filename = '_dev-' . $page->template->filename; } else { }

Yeah, good idea - I have made those changes locally - they should be committed later today. I think that was/is my thought. I am not sure where or how else you would want to run them. My idea was to just have a way to store common debug snippets and also perhaps admin/db cleanup, manipulation, batch operation type snippets. Maybe you have some better / different ideas to share?

Glad it helps - if you want some extended reading, here is the post that spawned my module: Lots of interesting reading on those file/image hooks.

Actually it does, but you need to send as an array: $footer = $ftvar->render(array('partial' => 'true')); Then you can get these using the $options variable: $options['partial'];

You could use this module: http://modules.processwire.com/modules/process-custom-upload-names/ Or if it looks too heavy for your needs, grab some code from it: Admin InputfieldFile::fileAdded - https://github.com/adrianbj/CustomUploadNames/blob/master/ProcessCustomUploadNames.module#L97 Frontend API calls Pagefile::install - https://github.com/adrianbj/CustomUploadNames/blob/master/ProcessCustomUploadNames.module#L101

Hey @netcarver - do you mean as a way to install/switch PW version, or for switching branches of your website code (ie site folder) ? I have actually been thinking about the latter - I think it could be very cool, but I wonder how standard different devs are in their approach to versioning their site folder, vs the website root. How are they using gitignore? There are some topics around this, some of which you have contributed to: https://processwire.com/talk/topic/2885-what-filesfolders-should-be-added-to-gitignore-for-regular-development/ https://processwire.com/talk/topic/8505-pw-and-git/ https://processwire.com/talk/topic/5417-using-git-with-a-cms-for-version-control-and-deployment-on-multiple-machines/ Do you have any specific ideas?

Hi @psy- thanks for creating your module. Could you also please edit the Github link to go to: https://github.com/clipmagic/MarkupJsonLDSchema/ instead of linking directly to the zip. That way we can read more about and can more easily choose how we might want to get/install it. Thanks!

@Ivan Gretsky - you can click the tick mark next to the name of your activity stream, or even next to "Unread Content" on this page: https://processwire.com/talk/discover/unread/ - that will create a shortcut to this page: The tick goes green and results in the "Unread Content" link at the top right of the page. This works for any of your custom Activity Streams.

Thanks @Macrura - I have gone with your suggestion and packaged the three required ACE files. I thought about using CDNJS instead, but if it's down, things would break and I'd need to add the textarea fallback anyway. This way just seems simpler. Thanks for your thoughts on the snippets manager - I think it could be quite useful - so expect that to be added sometime soon. The latest version just committed includes ACE editor, along with yet another new panel ProcessWire Version Switcher This new PW Version Panel lets you choose from any of the versions you have available and gives you the ability to switch versions instantly. The available versions come from Ryan's ProcessWire Upgrades module - so any version that you installed via it will be available. When you click change, it swaps the names of: wire/, .htaccess, and index.php - much easier than manually renaming. The icon is green when you are using the latest version that is available on your system, and orange for any other version. Please let me know if you have any problems with either of these additions. PS - It's probably obvious, but the switcher is not recommended for live sites, so don't blame me if a version change breaks your site!