Leaderboard

It's been out for about 10 days now, but I never really announced the changes here - wanted to see if there were any issues before publicizing. The new 4.9.x version is now available. Here's a list of the main changes: 1) New File Editor Panel Supports editing all files in your PW install (you can define the root as /, /site, or /site/templates Can be used as the handler for opening editor links from the debug bar (errors, log files, Captain Hook, ToDo, Template editor, etc), rather than your code editor. Can be enabled as the link handler for live sites only, or local as well if you prefer. Has "Test" functionality for all files so if you make a change, it will only appear for you and not other users. Makes a backup of the old version each time you save a change and provides a "Restore Backup" button to instantly revert. Supports in-code search & replace with CMD+F Syntax highlighting/linting for PHP, CSS, and JS This replaces the Template Editor panel, so that one has been removed. Handles fatal errors gracefully - this is the biggest feature in my opinion. The problem with most online file editors is that if you accidentally make a code change that results in a fatal error, it can be impossible to fix and resave because the system is not functional. This editor gets around this problem by using Tracy's custom error handling which allows debug bar panels to continue to work, so you can manually fix the problem, or click the "Restore Backup" button. Of course if you used the "Test" option, you don't even need to worry, because you are the only one to see the version with the error anyway. As a follow up to that last point. I have used the excellent ProcessFileEdit module for helping to debug some issues on other people's sites without needing FTP access, but a couple of times I have made a fatal error mistake and had to get them to restore the file, so this really is a huge feature for me! 2) Support for Process File Edit If you prefer ProcessFileEdit to this new File Editor Panel, so you can use it for handling debug bar links. Note that this won't give you the "Test" and "Restore" options, or the fatal error protection, so it's not really recommended. I added support for it before building the File Editor panel so decided to leave in case others prefer it. 3) Revamped Console Panel The code and results sections are now a "split" screen so you can adjust the size of one relative to the other with the bar in the middle. Handy for working, but especially handy when you want to post a screenshot to the forums "Large and "Small" versions of the panel - click the arrows at the top right of the panel - the large version can be very handy when you have lots of code or results to display Supports in-code search & replace with CMD+F 4) New maxDepth and maxLength shortcuts and new barDumpBig() method You can now replace dump or barDump calls like: bd($var, array('maxDepth' => 7, 'maxLength' => 500)); with: bd($var, [7,500]); You can also make use of the new: bdb($var); as a shortcut to: bd($var, [6,999]); 5) New SQL Query column in the Selector Queries section of the Debug Mode panel This is a great learning tool to see the selector queries that are run for a given page request, and what SQL query these selectors are translated into: 6) Removed old Legacy version of Tracy core It was getting too painful to maintain support for this old version. This means that TD now requires PHP 5.4.4+ 7) Namespacing and refactoring lots of Javascript code No feature changes, but code is now easier to follow and is much less prone to any name conflicts with your site 8) Reduced loading of unnecessary code Lots of refactoring here too - should see some performance gains 9) New default server type indicator in the debug bar Not a big deal, but if you want a server type indicator and don't want the full height/width bar, you can now have one in the debug bar - I think it's a handy visual clue when looking at /working on live vs dev/test versions of a site at the same time. 10) Lots and lots of bugs fixes, layout, and styling improvements It's amazing what you find when you're buried in the code for a couple of weeks solid 11) The new docs site that I mentioned earlier is now fairly complete - I just need to work on the Tips & Tricks section https://adrianbj.github.io/TracyDebugger Feel free to make a PR for improvements to the docs - everything is under the /docs folder in the main Github repo. There are also "Edit on github" links on each page so you can use those as well.

Here's an alpha proof-of-concept module if anyone is interested in taking it further: https://github.com/Toutouwai/FieldtypeFileUnrenamed/

That's what OR-groups are for. $userTest = $users->get("(nick={$input->post->nick}), (email={$input->post->email})"); Btw., don't forget to sanitize your input before using it in selectors.

I don't ever trust site/templates. I figure that site/assets/files makes it pretty definite, but as @kongondo mentioned, I always test via: isit.pw The other thing that isit.pw checks (I think), is the "it" url parameter that PW uses for all page requests. I got there from: https://w3techs.com/technologies/details/cm-processwire/all/all

/site/assets/files/1234/photo.jpg style image urls. /site/assets/pwpc/pwpc-(longmd5typehash).css tells us ProCache is being used. /site/assets/aiom/css_(longmd5typehash).css is the same, but for AllInOneMinify. 1 alone is a pretty good indication. 2 or 3 in all honesty are probably definitive. 1 + 2|3 and you can be 99.999% certain. Anyone got any other tells?

Hi, I've been searching for the answer but could only find some hacky "solutions" from the distant past. What drives me crazy is the "preview" feature of the dropdown menus: Is it possible to force the dropdowns not to apply the styles of the editor but use the styles of the button of the editor, or at least use the default styles? I need readable menu items, not those cut-off an useless styled ones. Also, only a few menu items fit in the tiny dropdown area. This is bad UX

If tab1 is a FieldsetTabOpen, you need to use $template->fieldgroup->getField('tab1')->getLabel($language);

Getting closer to an initial release. Def been a learning experience using EB's self-proclaimed "easy API". Tip for other devs when implementing other vendors' API's - check the github pull requests before committing hari-kari. In my case https://github.com/eventbrite/eventbrite-sdk-php/issues/7 - wasn't me after all, just a MAJOR bug in the API. My alpha version has the suggested solution implemented and all good so far What I can say is that if you only want to pull info from your own EB stuff into PW, you won't need my module. Simply set up the necessary in EB and create a PW page/template to handle the web hooks, eg when an event is created in Eventbrite, you can pull that info into PW with: // Retrieve the request's body and parse it as JSON $eventbrite_json = @file_get_contents("php://input"); $eventbrite_obj = json_decode($eventbrite_json); /** * Eventbrite webhooks * attendee.checked_in - Triggered when an attendee’s barcode is scanned in. * attendee.checked_out - Triggered when an attendee’s barcode is scanned out. * attendee.updated - Triggered when attendee data is updated. * event.created - Triggered when an event is initially created. * event.published - Triggered when an event is published and made live. * event.updated - Triggered when event data is updated. * event.unpublished - Triggered when an event is unpublished. * order.placed - Triggers when an order is placed for an event. Generated Webhook’s API endpoint is to the Order endpoint. * order.refunded - Triggers when an order is refunded for an event. * order.updated - Triggers when order data is updated for an event. * organizer.updated - Triggers when organizer data is updated. * ticket_class.created - Triggers when a ticket class is created. * ticket_class.deleted - Triggers when a ticket class is deleted. * ticket_class.updated - Triggers when a ticket class is updated. * venue.updated - Triggers when venue data is updated. */ switch ($eventbrite_obj->config->action) { case 'event.created': $apiUrl = $eventbrite_obj->api_url; $apiUrlArr = explode('/events/', $apiUrl); $eventId = str_ireplace('/', '', $apiUrlArr[1]); $template = wire('templates')->get('name=test-eventbrite-webhook'); $p = new Page(); $p->template = $template; $p->title = $sanitizer->text($eventId); $p->name = $sanitizer->pageName($eventId); $p->parent = pages(1); $p->save(); break; default: break; } // tell eventbrite the webhook was received. http_response_code(200); // PHP 5.4 or greater

Tracydebugger has come a long way. Thanks for developing it into the powerful tool it has become.

This is exactly what can be done with the migrations module. It totally depends on his usecase what is the best option. That it is not maintained does not mean that it does not work It's only some helper functions around pw's API - and you know how often the api changes... almost never Maybe copying over site profiles is the best option. But maybe he needs more flexibility then the other options could be handy. And maybe he wants to maintain all of those websites lateron, then site profiles would be totally useless whereas migrations could be shared across the single instances and modify them as needed.

Just a quick fix: "...the most powerful tool on this planet..."

Oops, forgot to respond.. I don't use VSC git at all. One, I was already used to sourcetree (I tried others but they never worked for me). I feel the VSC git interface looks a little bit cramped. I guess I am also a bit jittery I'd make mistakes in there. In a sense, I don't want a swiss army knife in this case. I use VSC for the text side of things and sourcetree for what it was meant to be; a git app .

I just tested with an Office365 account with these settings, it works well. WireMailSMTP 0.3.0 here. Look like its your credentials that are incorrect ? Double check

Yes thanks for catching that, it is fixed now. That's actually not the case, but looks like the latest version wasn't updated to the modules dir; i just upped the version and committed the changes to GH. the module checks for the core version and then only depends on JquerySelectize if less than 3.0.67 Yeah, i have no idea how that happened; Will try and fix/change at some point.. The module doesn't effect the listing of icons that is generated by the core; it only replaces the icons; I only use pro icons currently on my dashboard module; but it would be nice to be able to use the icons for fields and templates; i can try and research how to hook in and change those lists.

More on this here by @Robin S: https://processwire.com/talk/topic/16350-processwire-and-phpstorm/?do=findComment&comment=145018 You can also clone "your default site" easily with: https://modules.processwire.com/modules/duplicator/ by @flydev Keep in mind that using Duplicator you will get the same $config->userAuthSalt which is a minor security issue but you can apply the workaround suggested by @horst: https://processwire.com/talk/topic/15265-generate-new-userauthsalt-for-copied-site/?tab=comments#comment-136537

An admin page to hold a module's config itself is not new and has been done. The bit about image upload via the module's config page, that I've not seen/heard of before. I'm wondering whether it is really worth the effort since you'd have to hook into the module class (I think), to catch the upload and save it to your admin page. Maybe it is easier to let your SEO be a process module and in there, create the interface for uploading images? The images will still be saved in your hidden admin page. You wouldn't have to hook into anything in this case. Will this module be accessible to non-superusers? In that case, you don't want them to be mucking about in ProcessWire's module pages. I'd go for a process module and save all text setting as one chunk of JSON in a text field in the hidden admin page. I use a similar approach in several of my modules, including menu builder. Just my 2p.

@Robin S This. This right here is why you are a hero member. Props to you for the profile explanation. I never knew the procedure. I will put this into practice immediately. PS. Where is that damn "Buy-a-Beer" button? Somebody needs to make that happen.

Hi @rick, I can't share my custom profile because it contains pro modules. And it's set up to suit my preferences and idiosyncrasies which would surely be different for each person. But it's very easy to make your own custom profile. If you find yourself installing the same modules or creating the same kinds of page structures over and over for each project then the idea is: Create a new installation on your localhost using the "blank" profile Customise /site/config.php how you like, e.g. imageSizerOptions, useMarkupRegions, setlocale() Install your favourite modules - include the Site Profile Exporter Set up any admin tweaks with AdminOnSteroids and/or AdminCustomFiles Create the fields, templates and template files you tend to need for every new site (it doesn't hurt if there are some that aren't always used as you can always delete them in any project that doesn't need them) Create any page structures you want to have pre-existing (I have a "news" section, and a "selects" section for Page Reference options) Export your site profile Then when you are creating a new project you just copy the profile folder to the root before installing PW and select it during the install process. I keep my starting profile on localhost and update/re-export it from time to time with the latest module upgrades and any new tricks and tweaks I have learned.

DEPRECATED - USE ROCKMIGRATIONS INSTEAD I'm very happy to share my newest module called "ProcessWire Kickstart" that I developed during the holidays Maybe some of you already saw the preview thread about this... What it does: This module makes it possible to install ProcessWire in a fully automated process. You can define all necessary settings in one single php file and you can even define "recipes" that get executed after installation. This means you can install modules, adopt settings and do whatever you want with your new site using the PW API (like creating pages and so on). You could also place a kind of frontend boilerplate on your git account and grab that after installation and place it in your templates folder. I ran out of time so maybe someone could try that out and show how he did it Additional to that there is a ProcessModule to install in your ProcessWire admin which makes creating and testing recipes super easy. Note: Alpha realese until this module gets some more testing. Please be careful with this tool since it does some heavy file system manipulations (unzipping, moving and DELETING whole directories...). Use at your own risk. Usage: Just grab a copy of the kickstarter, place it on your server, visit yournewsite.com/kickstart.php, adjust settings (like username+password) as needed and hit "install". If your mysql user does not have the rights to create a new database then you have to create a database before running the installer! Download: via SSH: cd /var/www/yournewsitedirectory wget baumrock.com/kickstart.php // or using curl curl baumrock.com/kickstart.php -L --output kickstart.php Manually: Klick baumrock.com/kickstart.php and upload the file to your server Note: baumrock.com/kickstart.php returns the current master file from the gitlab repo and changes the namespace of the script so that it can install itself via recipe. If you don't need to install the kickstart processmodule via recipe you could also download the kickstart.php file from gitlab. Screenshots/Walkthrough: The initial Screen: You can either upload a file via the left panel or take my example file from the gitlab repo: This way you can create your own kickstartfiles and host it on your own accounts. When the file is loaded you can easily edit all necessary informations, like username, password and the url where to grab ProcessWire from. I just tried it with an old version as well... 2.7 worked just fine (having the old installer that recently was updated) but an ancient 2.2.4 version failed. I don't think anybody will ever need to install lots of old versions of pw with this tool but I wanted to mention it here. Hit "install" and lean back - on my VPS it takes 15 seconds to install my very own custom version of processwire with all modules that i need After logging into your admin you'll see that all modules from your recipe are installed: Recipe Editor: As recipes are executed after processwire was installed you have all your API magic available there. Running this scripts is only possible inside of a working processwire installation, so I created a module to help you with that task. See the comments of the sample recipe for more information! I hope this tool helps you to save lots of time and create lots of awesome ProcessWire websites I would be happy to see how you use this and please share useful recipes here in the thread so that everybody can profit. Maybe you just want to throw in an idea what could be done (for example I can imagine a recipe that checks file permissions on the system after installation)... Some parts of the code and maybe also part of the idea are taken from @Soma 's old and still great online installer, thx for that!

Since today, 31-01-2018, we have support for this in the PW Core. Therefore I updated this module to version 2.0.2 This version handles the detection of the core support and dismiss its installation then. If the core module is available but not installed, it get installed instead of this third party module. If you have this third party module already installed since a previous PW version and upgrade your wire folder, this module will detect the core module and install it. Its own hook isn't registered then and you get a notification about the changes.

Thanks @horst. Those are some excellent starting points.

File fields are an array (unless you set maxFiles to 1), so you need to either foreach or first(), last() or eq(n) to get a specific file. $item->allegato->first()->url; There is no "items" property, hence the NULL.

This is one of the few cases where I don't care that much since getting the new CSS selectors isn't difficult, so I just make sure to document these small UI hacks in a dedicated place in the admin area. The format and styles plugins (as well as some other basic widgets that are internally realized as plugins) are already included in the main ckeditor.js.

It does! optionsfieldname.title is what worked. I was trying that but like so: optionsfieldname|label which is obviously incorrect haha Thanks!

How are the headings different sizes in the first place? Been searching through the ckeditor code and can't find anything that seems to control it. You can change the rendered label (Heading 1, Heading 2...), use custom classes for each item, change the html tag that gets output but damned if I can find the part that controls the font in the select list itself. The format dropdown is a plugin which you can download and add to ckeditor. I can't find this plugin in my PW install so not sure how the format dropdown even exists on my body field.

I've been looking for a solution to that years ago, and it seems the answer hasn't changed What I use as a workaround is to add larger styling for the combos in question with AdminCustomFiles, applying width and height to div.cke_combopanel__format and div.cke_combopanel__styles.

Hi @SamC Your solution width JS adjustments works great. I just added in my CSS a "height: auto;" on image tag to respect image ratio. And It's OK to generate AMP tags. All is good. Hi @Macrura I don't understand your solution... Could you get me an example ?

I wonder whether a decent interim solution would be to build this into CustomUploadNames so we don't need a separate fieldtype - that way if the core ever gets support for this, it would simply be a matter of disabling the rule in CustomUploadNames, rather than reverting to the core file fieldtype. I could add a new option that retains the original filename. Perhaps I could make use of your sanitizer? Any interest in this approach, or would it just be overcomplicating things?

Ok, I ended up with the following codes in site/_init.php //get labels, title, values and descriptions in different languages if ($user->language->name != 'default') { $title = "title{$user->language}"; $value = "value{$user->language}"; $label = "label{$user->language}"; $description = "description{$user->language}"; $notes = "notes{$user->language}"; } else { $title = 'title'; $value = 'value'; $label = 'label'; $description = 'description'; $notes = 'notes'; } and on the page itself: echo $page->template->fields->getFieldContext('tab1')->$label; Pay attention to "$label" instead of "label". The same can be achived by using description, notes,....

I read somewhere (can't find it now, I think it was apeisa), who stated that the test site is pretty robust.

I know the test-site ( http://isit.pw/?url=https%3A%2F%2Fwww.integrify.com%2Fcustomers%2F ) but I don't know how the testsite works either I can't find anything indicating that it is PW other then the /site/templates/ urls and I'm just not sure if that is proof enough...

Oh, okay When i use "$user->language->id" inside of the "getTabLabel", theres an error (tracy )... You can use it without "->id": $tablabel = $page->template->getTabLabel('tab1', $user->language); i checked it, and it works

I'm not a fan of site profiles... That's why I created ProcessWire Kickstart. I created another explanation of how you can use it in szabesz' linked topic:

...or create one kickstartfile and run it: <?php return [ 'pw' =>'https://github.com/processwire/processwire/archive/dev.zip', 'profile' => 'site-default', // could also be a custom profile url from gitlab 'settings' => [ // usernames + passwords ], 'recipes' => [ function() { $this->installModule('TracyDebugger', 'https://github.com/adrianbj/TracyDebugger/archive/master.zip'); }, function() { $this->installModule('DemoModule1', 'url1'); }, function() { $this->installModule('DemoModule2', 'url2'); }, function() { $this->installModule('DemoModule3', 'url3'); }, function() { // create pages or do whatever is possible via pw api // you could also change settings in config.php here }, ], ]; Then it is literally just one click! You could create one master kickstartfile and then just comment out the recipies that you don't want. I think this is a really, really powerful and timesaving method. Also it will always download the latest versions of all the modules. I don't get why there is no almost no response at the dedicated forum thread. Seems that nobody gave it a try so far...

i think theres a missing comma $tablabel = $page->template->getTabLabel('tab1', $user->language->id);

My first PW-project was a site profile for mp3 database. There are genre, autor, album, track siblings in the tree. To show them as parent children relations, I used a jquery tree in frontend. So, it was my first contact with PW, and I doesn't know much about it. But maybe build your own tree as a process module, which has its own page(s) under admin, can be a good solution, too. http://modules.processwire.com/modules/local-audio-files/ There is a basic demo page too: http://pwlaf.biriba.de/sitemap/

I'm not aware of any module that modifys the page tree beyond hiding some pages, and never would even think of to try. I go with lister pro and its filters for stuff like this, because it is damn fast and easy to use.

After reading a bit the source code, I found that the module edit form can be altered by hooking to ProcessModule::executeEdit and append the hidden admin page fields to the output form. For saving the module, we can hook to Modules::saveModuleConfigData to save the hidden page fields there. But for the below reason, I would stick to process module instead. I may try this approach next time. I get your point. I can give process module a permission, but individual module edit page cannot (is it correct?). This is a real benefit of using process modules. Modules like SEO module should be able to let digital marketing team to edit while have them away from other module configs. I would use the native inputfields as I want the module to be multilingual. I am not sure should I output the ProcessPageEdit or use something else.

Not sure how well known, but they have some well known clients: https://www.integrify.com/customers/

I haven't tried, but does: optionsfieldname.title or optionsfieldname.label work?

You can disable the WHOIS lookup in the module's config.

Hi @Tyssen What I usually do is : 1. Edit the getModuleInfo()'s module [...] 'page' => array( 'name' => 'general_settings', 'parent' => 'setup', 'title' => 'General settings', ), 'permission' => 'global-site-settings', 'permissions' => array( 'global-site-settings' => 'Access to Global Site Settings.' ), [...] 2. Uninstall / re-install the module 3. Add a new role : site-settings 4. Add to this role the permission : global-site-settings 5. Add the site-settings role to the user 6. Logoff / login the user No extra steps required.

Similar issue in this thread, I think? I had a go at a solution for separately saving the original file name. This is for unzipped files though. If it is of interest, I can upload the module to a gist.

I've managed to get Google display our meta description correctly again today in their search results. Not sure which of the following corrected it, but the steps are took were : 1) Not to cache Robots.txt (.htaccess) <filesMatch "^robots.(txt|php)$"> Header Set Cache-Control "max-age=0, public" </filesMatch> 2) Removed other test sites from access-control-allow-origin 3) Created a sitemap-category.xml file where it listed the homepage plus important category pages and uploaded it to Google. 4) Uploaded sitemap.xml to Google again after fixing 1) & 2) I initially tried 3) but it didn't fix the problem initially (Google initially indexed 0 pages ... then 1 page today ). I tried 2) 3) 4) today and it seems to have fixed it. Process 1) I tried when I first posted this thread. It's also quite possible it "organically" fixed itself today by coincidence and none of my steps was actually effective. As for the canonical meta-name issues, I'm using MarkupSEO module so it possibly is an issue with that. I'll post any updates here. Thanks again to @dragan , @Christophe & @teppo for responding.

I actually think it would be a great addition to have a "test" option in the Console panel - something that reported the changes that will happen - trouble is I think it would be a huge amount of work to implement.

@Robin S Just an FYI. I followed your procedures to export my local dev profile and install it to my live server. Everything went without a hitch. I owe you a coffee, a beer, and a pizza!

Great - should have looked for this there in first place It's here btw, under name "Page Edit Image": /admin/module/edit?name=ProcessPageEditImageSelect

Almost. There's also an additional check to see if the returned page contains certain traces of ProcessWire. Simply checking the return code wouldn't be enough here For the record, isit.pw includes roughly a dozen methods for checking if a site is running ProcessWire. In many (most) cases it can still identify your site, even if that one check fails. I should probably mention that isit.pw (which is my project) is both a functional tool (as Antti explained earlier) and an experiment; "can you properly identify a site running ProcessWire or not?" I'm also planning to add an info section later, including details on hiding your ProcessWire-ness from humans and services like isit.pw equally

Hi all, i am new to PS and didn't have enough time to learn it. I think will be great platform for my future projects. For start I use default template and create the /site/templates/contact.php . The form shows well and submit sends the mail, but after that i got page with empty body. No "Thank you ..." message neither option to go back to home page. Please ryan, point me to the right code after sending email which says "thanks" and show button to go to home. Thanks in advance! Edited: changed $page->body with simple echo solved the problem. The working code is: <?php include("./head.inc"); echo $page->body; $sent = false; $error = ''; $emailTo = 'my@email'; // or pull from PW page field // sanitize form values or create empty $form = array( 'fullname' => $sanitizer->text($input->post->fullname), 'email' => $sanitizer->email($input->post->email), 'comments' => $sanitizer->textarea($input->post->comments), ); // check if the form was submitted if($input->post->submit) { // determine if any fields were ommitted or didn't validate foreach($form as $key => $value) { if(empty($value)) $error = "<p class='error'>Please check that you have completed all fields.</p>"; } // if no errors, email the form results if(!$error) { $msg = "Full name: $form[fullname]\n" . "Email: $form[email]\n" . "Comments: $form[comments]"; mail($emailTo, "Contact Form", $msg, "From: $form[email]"); // populate body with success message, or pull it from another PW field echo "<h2>Thank you, your message has been sent.</h2>"; $sent = true; } } if(!$sent) { // sanitize values for placement in markup foreach($form as $key => $value) { $form[$key] = htmlentities($value, ENT_QUOTES, "UTF-8"); } // append form to body copy echo <<< _OUT $error <form action="./" method="post"> <fieldset> <p> <label for="fullname">Your Name</label><br /> <input style="width:300px;" type="text" id="fullname" name="fullname" value="$form[fullname]" /> </p> <p> <label for="email">Your Email</label><br /> <input style="width:300px;" type="email" name="email" id="email" value="$form[email]" /> </p> <p> <label for="comments">Comments</label><br /> <textarea style="width:300px;" id="comments" name="comments" rows="6">$form[comments]</textarea> </p> <p><input type="submit" name="submit" value="Submit" /></p> </fieldset> </form> _OUT; } // include site's footer include("./foot.inc");

Are you gone crazy? And even with colors!