adrian

New Template Editor panel just added! This is an alternative to the Template Path panel (which I still think is a great option) if you need to edit a live site, which of course you never do The difference with this compared to Nico's Template File Editor (http://modules.processwire.com/modules/template-editor/) is that it allows you to test changes without affecting other users currently viewing the site. Note that there are three buttons: Test: This will reload the page using the code in the editor - no changes are made to the template file or the code served to all other users of the site. Push Live: This will save the editor code to the template file, making this a live and permanent change. Reset: This will reload the page (and the code in the editor) with the code from the saved template file. Possible use scenarios Use this panel similarly to your dev console for tweaking CSS/HTML - it still requires a page reload, but there are likely less clicks than your normal workflow. Use it to tweak a live site if you're away from your computer and need a quick way to fix something, but want the ability to test first without breaking something temporarily due to a simple syntax error mistake or more serious code mistake. Use it to add debug statements: fl(), bd(), d() etc to your template code without ever touching the actual template files. This is a first version of this panel - I am looking for feedback and feature/behavior suggestions. At the moment this only lets you edit the template file for the currently viewed page. I am considering adding a dropdown where you can load other files (included files, JS, CSS files etc), but want to see what you guys think.

Typically the file compiler in PW3 takes care of making modules without namespaces work in 3.x, however I have had a couple of situations where I have had to conditionally check if a class exists and if not, prefix it with \ProcessWire\

I personally haven't noticed this and hope it's not happening - the Version Switching panel in Tracy relies on these renamed folders/files being left after the upgrade. Maybe going back to old versions is not that critical for the average user, but as a module developer, it is super convenient to be able to instantly switch between versions, including the 2.x and 3.x branch. And honestly I think it can be useful for others too for helping to report core PW bugs - it makes for a very quick way to revert to previous versions to see if the problem exists there also.

Hey Marty, Unfortunately I never got around to finishing it - I just took a quick look at what I have and I think that rather than being a dedicated module, it might be better to convert it to an Action for ListerPro. I know that will obviously mean that you'll need a ListerPro license, but leveraging LP's ability to perform actions on just matched pages and its built-in batching will make for a more powerful and performant tool.

https://github.com/ryancramerdesign/ProcessWire/blob/7e8c7c6836282b6b64de81263f5aaa8112fd51ae/site-beginner/templates/_head.php#L21

Thanks @tpr - I have decided to remove that setMaxAllowedPacket method in the latest version - it's most likely not going to work for a standard SQL user on most shared hosts anyway. So, the message for everyone out there is if the debug bar isn't working and you have the PW core SessionHandlerDB module installed, you have three options: Uninstall SessionHandlerDB Increase your SQL max_allowed_packet setting (in your my.ini or my.cnf file, or via SET GLOBAL max_allowed_packet) - http://stackoverflow.com/a/5688506/1524576 Use the "Legacy" option for the Tracy core setting in the module config (not really recommended as you'll be missing out on core updates)

Hi and welcome to PW. That CNN URL is not a valid feed - it needs to return an XML document, but that one is just a directory of actual feeds - choose one from the list and it should work fine. What was the other URL you tried before switching to the CNN one?

Thanks to @netcarver - http://pwgeeks.spreadshirt.co.uk/

Hi @tpr - sorry about that - is that working version the last one that works for you? Everything is fine here, so it's hard for me to track this down without more info. Would you mind doing a little debugging - I am honestly not even sure where to start for this one. Can you please at least post a screenshot of the error so I can see the file and line number that is generating the error? Thanks!

Hi everyone! Thanks to a tip from Ryan, I now have the latest version of the Tracy core working properly when the core SessionHandlerDB module is installed. This means that I have been able to consolidate the number of packaged versions down to two: Legacy and Master. Now the only reason not to use Master is if you are running PHP < 5.4.4 I will keep the Master version updated with changes to core after testing to make sure there are no issues. The module now automatically adjusts your MySQL max_allowed_packet setting so that it is large enough to handle storing the Tracy debug bar data when you have SessionHandlerDB installed. Ryan has changed the "data" field in the "sessions" database table from text to mediumtext and says he'll be adding this to the upgrade routine shortly, but if you have problems with the Master version, please make this change yourself. Please let me know if you have any problems with the new Master version.

Thanks Wanze - very good point! When I wrote that module I initially had things set up quite differently such that it required rendering the template file directly. More recent changes mean that it no longer needs to do that. Rendering the page directly (like you noted) works fine here, so I will make that change to the module anyway and hopefully it will solve the problem with TEF. PS New version with this change just committed.

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?