Leaderboard

Hello community My new website is nearly finished, I used: processwire (of course) dead simple grid modules: form Builder , XML SITEMAP

Hi all, I have been looking for a way to manage deployment of new sites, as well as versioning of the pw data model on sites already deployed, working with teams, etc. I've enjoyed the discussion on a few threads : https://processwire.com/talk/topic/6707-update-live-site-from-staging-server https://processwire.com/talk/topic/2975-team-development https://processwire.com/talk/topic/2117-continuous-integration-of-field-and-template-changes but so far, I have not found what I'm looking for, so I built two tools and have put them on my newbie github site for all to use and/or peruse. I hope they are relevant to this community. They are crude and only have been exercised in my relatively finite world of Windows/apache dev. See https://github.com/jeanrajotte/schlepwire and https://github.com/jeanrajotte/upgradewire Both "apps" are not designed to be modules, integrated into pw, but rather external simple apps serving their specific purposes, possibly usable in automated build systems via curl, for example. There's a bit of a diatribe in the upgradewire README.md about the goodness of keeping the model in version-able source files, as distinct from operating the pw admin to maintain fields and templates, even if these changes are being recorded, as mindplay.dk seems to be doing. That's really the philosophical thrust behind these efforts. It's a beginning. I hope it's of interest here. Again, thank you for this superb framework and this generous community. Jean

It's okay to start drinking beer at noon right? I have a feeling I wont have any fingernails left after watching this group play today.

Charlie Bit My Finger SUAREZ VERSION! https://www.youtube.com/watch?v=N5vREwbPbl4

Still on the Suarez bite Link below to the interview with the guy that won 2000 euro betting that Suarez would bite someone. http://www.bbc.co.uk/news/world-europe-28020605 He also bet that Costa Rica will win the world cup. Think I might go to the bookies now and place my bet.

thank you Nico it's all greek

Thanks for such a detailed writeup Ryan. I've been through almost every item on the server and it seems the problem was limited to that single php file in my case, but still a hugely helpful post that I will keep bookmarked. My initial hunch was that it wasn't PW that had been compromised, I'm now certain the problem was down to the shared hosting package the client is using.

=* should be *= Any modules installed?

upgrade.php is not a ProcessWire file. I'm guessing maybe it was a leftover from a previous WP or Joomla install? It sounds like it could be related to the exploit you experienced, but be careful not to assume it ends there. ProcessWire's core does not have very many input opportunities on the front-end of your site. Actually, the URL itself is really the only input ProcessWire deals with on the front-end, and that is validated by the htaccess before being sent to PW, and then thoroughly sanitized then validated again by the core. As a result, it's unlikely for ProcessWire itself to be exploited in the same ways that some other CMSs might be, simply because there are a lack of input opportunities to a guest visitor. What ProcessWire does instead is give you an API that lets you control all the aspects of when user input results in something output. If there were to be an exploit on a particular PW site, it would be much more likely to be the result of the code unique to that site, or a 3rd party module, rather than PW itself. If you were dealing with a site that had other software running, either presently or in the past (perhaps WP powering a blog alongside) then it'd be much more likely for that to be the source of the issue than PW. In fairness to WP, most exploits have to do with 3rd party WP plugins or themes and not WP itself. WP and Joomla are also much larger targets than PW, so they are usually broken into with automated scripts rather than actual people sitting at their computer. When you've got a site that you know has been broken into at the filesystem level (like yours might have been), it's unusual for it to be limited to just one file. There are usually backdoors built elsewhere. Even if the site is fixed for the moment, it's good to still think of everything as tainted until proven otherwise. I'm not necessarily a fan of restoring from a backup in this case, unless you know for certain that the backup itself does not contain the exploit. Sometimes a backdoor will be present for months before taken advantage of. If you had Joomla running on this server a long time ago, the exploit may have originated there and simply been hidden somewhere on the file system. The first thing you'd want to do is remove any other software installed on the server that doesn't need to be there–old copies of WP, Joomla, etc., or files leftover by them. If you aren't certain, then just move it to a non web accessible quarantine directory. For your ProcessWire site, you don't need anything in your web root directory except for: /wire/, /site/, /index.php and .htaccess. Remove your entire /wire/ directory and put in a new fresh copy, as well as your /index.php and /.htaccess file. Basically do the same thing you would do if performing an upgrade. In /site/modules/ you may have some 3rd party modules installed. Replace each of the directories in /site/modules/ with fresh copies. This is the same thing you'd do if upgrading those modules. That essentially leaves /site/ and everything in it to analyze. If the hack originated from an automated script targeting DrumlaPress, chances are it left your PW installation alone, but you never know–it might have gone after every single PHP and JS file it could find on the file system. You'll want to look for anything unusual in your /site/templates/*.php files and /site/config.php file. By unusual, I mean anything that you didn't put there. Start by looking at the beginning and ending of each file. Red flags are usually extra <script> statements, base64 function calls, exec function calls, extra JS attributes on markup elements that you didn't put there (like onclick), include or require statements with variable names in them or referencing files you don't recognize. Also consider that new directories may have been introduced anywhere. I would download a copy of your entire /site/ structure and analyze it locally, looking for any extra files or directories that you didn't put there. Also be on the lookout for extra .htaccess files, and give them a close look if you find any. Meaning, you'll need to make sure you are seeing hidden files (those preceded with a period). Compare your /site/ structure to a /site-default/ structure as included with a new copy of PW. Once you've cleaned your /site/ directory or at least verified that it's clean, make a good backup of your site so that you've got a known clean starting point (hopefully). Open a browser to your site with Chrome and go to View > Developer > Developer Tools. Click to the "Network" tab. Reload the page. Look for any offsite requests that you don't recognize. That may reveal something hidden that might still need to be cleaned, but hopefully not. Now click to the "Elements" tab. This shows the post-JS markup of your site. Look for any generated elements that you don't recognize, especially at the end or beginning. This again can reveal extras that have been added into your page by an exploit. Lastly (or maybe firstly?), take a look at your file permissions. If on a shared host, you want to be certain that your files aren't readable or writable to other users on the same server. Especially your /site/config.php file, and your /site/assets/ directory (and everything below). What permissions are ideal here depend on the web host and what type of PHP they are running, so it's best to inquire with them on how you can have files writable to your website that aren't writable by other accounts. Btw, I have never seen or heard of a compromised PW installation, regardless of what other compromised software was running on the server. I have seen plenty of compromised WP installations that had PW running alongside them. Thankfully, the PW installation has always been left alone, with the exploit limited to the WP installation. But it's best to go into these things assuming everything on the server is tainted, so always play it safe.

This module creates a blank dashboard page in your site admin and sets it as default when you login instead of the page list. It came from a need in a few projects where I was creating modules for various user roles to use and I didn't want them to see the page list at all, but needed to display various stats and quick access buttons. For example, if you have a person who is creating invoices or doing other back-office stuff in various other Process modules then as an admin you wouldn't want them to access the page tree anyway, and there are other scenarios where you might want to have a dashboard instead of launching straight into the page list. It also requires (and adds) a permission - "dashboard" - so you can create new roles and assign the dashboard permission to those roles - something you might want to do fairly commonly if you have a lot of admin modules that you want to restrict access to. Editing the template is simple - there is a dashboard.php template file in the /site/modules/ProcessDashboard/ folder (decided to leave it in there to keep it safe, but I might be tempted to move it into /site/templates/ ) as well as .js and .css files ready to add your code to. You can use the API as you usually would to create your dashboard experience. For example, display data based on user roles or even specific users using code like this: if ($user->hasRole('invoices') { echo "Hi staff member $user->name. View invoices to be processed below: ... ..."; } if ($user->name == 'pete') { // Show some super-awesome stuff here } You can also do away with the dashboard.php template file and edit the module directly, putting your code and output in the execute() function (the way most Process modules are written) but I decided to include the separate template file to make it easier for more people to use. This does touch on areas a few other modules have addressed to some degree (like diogo's Custom Admin Pages) but this is designed for one purpose - instant dashboard creation. You can download the module here: http://modules.processwire.com/modules/process-dashboard/ This module also uses code from diogo's ProcessHomeAdmin module so that the default admin page can be overridden.

One last Suarez one... http://www.bbc.co.uk/newsbeat/28014318

You could pass in the data as parameter. function dothing($thepage, $user) { echo $thepage->title; if ($user->isSuperuser()) { // do different } } dothing($page, $user); I thought so, too, but "wire('user')->title" returned me NULL in my test.

hi Manaus try this function dothing($thepage) { if (wire('user')->isSuperuser()) { echo wire('user')->name; } } dothing();

Fantastic, works perfectly! That's made my life a whole lot easier.

It might be worthwhile contacting tsohost to see if they can identify the cause or route that was taken.

Dev branch now supports this. https://processwire.com/talk/topic/5574-field-dependencies-from-a-repeater/?p=64345 There is a new setting in /site/config.php that also needs set.

GoDaddy hosting had a similar issue not too long ago with what you described. They of course never admitted fault, but coincidentally, every WP site that was affected just happened to be hosted on GoDaddy. I had a client site that was affected numerous times. I cleaned up the affected files and two days later it was there again. I moved the cleaned site to a new host and never had the issue again. *knocks on wood*

I don't understand any word but it looks great

Repeaters are actually dynamicly created pages with more or less random names. As long as you do not render the name/title of those PageTable pages, there not that much different from handling repeater pages, you could name them however you want. The biggest different would be, that the created pages show up in the pagetree.

It's not directly a workaround, but you could use the current dev version of processwire. There you could replace repeaters with PageTables. They have a quite similar functionality, but use real pages, where the dependencies should work.

This error means add() isn't working with the "documents". The output formatting turned on, most likely the problem here. "documents" is single file field?

Not sure but is that selector in a showIf dependency for one of the fields in the page's template?

I don't think I have ever needed more than a standard mysql text field. 65,000 bytes is a lot already. Jeez, that's the same as the total RAM of my first computer Type | Maximum length -----------+------------------------------------- TINYTEXT | 255 (2 8−1) bytes TEXT | 65,535 (216−1) bytes = 64 KiB MEDIUMTEXT | 16,777,215 (224−1) bytes = 16 MiB LONGTEXT | 4,294,967,295 (232−1) bytes = 4 GiB

There is a software limitation applied by the sanitizer. For textarea fields this limit is 16384 characters. https://processwire.com/api/variables/sanitizer/ http://cheatsheet.processwire.com/sanitizer/properties-and-methods/sanitizer-textarea-value-options/

There are several options: Check if the $p has a specific template (or any other field). if(count($children) > 0 && $p->is("template!=news-item|other|template")) Or exclude above the loop like: $children = $p->children->not("template=news-item|other|template"); Or filter above the loop like: $children = $p->children->filter("template!=news-item|other|template"); See the excellent cheatsheet for more options in the PageArray/WireArray. Another option might be to use to use soma's navigation module.

Don't suspend Suarez:

Brilliant; 3 days later i have full functionallity... login using ryan's script https://processwire....tor-login-form/ page edit using soma's modal trick https://processwire.com/talk/topic/2382-processwire-setup-and-front-end-editing-made-easy/ access control via http://modules.proce...-edit-per-user/ module and some cool table editing via profields table https://processwire.com/api/modules/profields/table/ 3 days with just a couple of hours a day..

Here's a draft of a simple service adding resource URIs. Just playing around, so don't take this too seriously But the idea would be to replace numeric IDs everywhere in the model with URIs instead - and then, in Fields::get() and Templates::get() etc. you would convert or "sanitize" the ID to a numeric ID using something like $key = wire('resources')->id($key) ?: $key; In addition, wire('resources')->get('...') would work for any type of resource - it uses the first portion of the URI path as the name of the resource collection, e.g. 'pages' or 'templates' etc. which can be resolved directly by just calling e.g. wire('templates')->get($id) etc. Supporting URIs in page queries might be tricky, I didn't spend much time investigating that, but it doesn't look trivial. Anyway, curious to hear what you think of the idea?

And I watched the game with my girlfriend who is German Lot's of world cup ahead still

small update: added separate inputfield for HTML signature into config page to solve an issue found by tuomassalo. https://github.com/horst-n/WireMailSmtp/issues/1 version now is 0.1.8