ryan

The above is just the start of image manipulation potential in PW. There are so many things you can do from the API side with images. Just today we added some new cropping options to the dev branch (thanks to Horst, who is one of the best in the world when it comes to image related code). Btw, your site is great and I will definitely visit a lot in the future. We're in Atlanta, but have family moving to Orlando and plan on spending a lot of time at Disney World when we can (we have two young daughters that of course love everything Disney).

I agree, I think ProcessWire would be an excellent fit for your needs. With regard to centralized media manager, there's a reason we don't have one built in and that's because we've got something better. You may have to think differently about how you manage them, but once you get it I don't think you'd want to go back to an old style media manager. If you need any help understanding how a particular situation would be accomplished in PW I'm happy to give more info. This is a potential security hole. Allowing URLs to create images on the fly has high potential as a ddos (denial of service) hole that is an easy attack target. Someone can write a quick script to formulate and call millions of those URLs, consuming your server for hours or days till eventually filling up the hard drive (or your hosting quota). Basically, it's a security problem if non-predefined resize dimensions are coming from the client (user input, like URLs) rather than from the server. I substituted some other width/height values in there and can see it will take whatever I give it (no restraints). For example, this call uses 3 megabytes on disk, takes up several seconds of server time, and consumes 3 megabytes of your bandwidth: http://wdwfans.com/files/thumb/21638/3500/3500/fit Here's how you'd approach creating 500x500 images in PW: $image = $page->image->size(500, 500); echo "<img src='$image->url' />"; Our default behavior would be the same as your "fit" method described. I'm not sure there is a legitimate use for the "fill" method as it distorts the photo, something that I can't imagine is desirable on any site. But if you wanted to duplicate that, you'd turn cropping off: $image = $page->image->size(500, 500, array('cropping' => false));

you are right, I forgot to publish. (it's Friday, end of the day, excuses and such)

This Textformatter module for ProcessWire enables you to break up a single textarea field (using either TinyMCE or CKEditor) into multiple pages. You include all of the content in a single rich text field and separate each pagination with a line of hyphens (5+). When rendered on the front-end, the user will see pagination links at the bottom of the page enabling them to move forward and backward through the content/article. Also included is the option for title pagination. That means assigning a title/headline to each pagination and giving the user a list of those titles they can click on to move to each section of the article. Example of this module in action Documentation and customization options GitHub Page Module Page Download ZIP Install class: TextformatterPagination

Relying on cookies alone is just not enough. Everything you do to trying to maintain uniqueness with anonymous requests is a compromise. I think remembering the IP for some length of time (which is configurable, btw) is a necessary and worthwhile compromise for most.

FieldtypeLikes is a module I've been working on (it's what is used here on the PW sites, as well as on CMSCritic). I've just been trying to find the time to finish it up so that others can use it, and hopefully can here soon. Tyssen I was thinking I could get you to beta test since you've got a more immediate need? Here's a section from the documentation which may answer some of the questions above: Likes Fieldtype for ProcessWire This Fieldtype enables you to have a "like" button that users can click on to like a particular page and have that be remembered. The fieldtype itself stores a single integer representing the number of likes each page has in total. As a result, the field can be used for the purpose of sorting pages, i.e. "most liked pages." FieldtypeLikes also adds a $session->getLikedPages(); that returns a PageArray of pages that the current session has clicked Like on. The liked pages are remembered with a cookie for up to 30 days. This enables you to have a separate page (or perhaps a sidebar on every page) that for example shows the user bookmarks of pages they liked. Before deciding whether this Fieldtype is suitable for your particular application, be sure to read the section on preventing duplicate likes. Preventing duplicate likes FieldtypeLikes is not connected with the user system, and may be used anonymously via any page on your site. The benefit is that anyone visiting can "like" things and generate a list of likes (for their own review), without having to login or create an account. That makes it much more likely that users will participate in liking pages and making use of what this module provides. The drawback to this approach is that it may be difficult to prevent one user from trying to manipulate the quantity of likes, perhaps trying to boost the rank of a page they have some interest in. Beyond cookies (which we use), in order to limit the potential for duplication, FieldtypeLikes connects likes IP addresses and remembers them (server side) for a week. As a result, there is a limit of 1-like, per page, per IP address, per week. While not ideal, this is a necessary compromise in order to have some protection for the data. Note that a very determined person could still use proxy servers or other methods of obtaining unique IP addresses. So we have also implemented some additional methods of protection. But ultimately you should always remember that if someone is determined enough, its impossible to prevent them from finding some way to manipulate the quantities of likes. As a result, do not use likes data for making decisions on hiring/firing, awards, grants or anything to be taken too seriously. That being said, I do feel the solutions we have implemented here are stronger than other anonymous rating systems I have come across, thus far. But always remember that any anonymous voting tool is open to manipulation and the results should always be take in that context, whether from this tool, or any other you've ever used or seen.

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.

That SetEnv line is only used by the installer to determine if mod_rewrite might be inactive. It is totally fine to remove it. Great suggestion by Craig to wrap it in the IfModule block–I will add that.

Thanks guys, I have fixed that issue by adding a new getModule($key, $options) method to the Modules class that lets you retrieve a module with $options. In this case an option called 'noPermissionCheck'. The ServicePages module has been updated to use the new method (when available). Adrian, I wasn't seeing the "it" GET variable. That is a GET variable used internally by PW, but it gets removed before the request starts. So if you are seeing an "it" variable then you probably shouldn't be. At least I'm not seeing it here. I did go ahead and add that as something for ServicePages to ignore though, per your suggestion.

Manfred62, looks like I broke it in one of this week's commits. I added translation support to uploaded filenames so that you could upload ŖýäŅ-Čřämêŕ.jpg and it would convert to ryan-cramer.jpg rather than ____-______.jpg. It basically runs files through the existing translation engine used by page names (and your settings defined with the InputfieldPageName module). So it was attempting to beautify filenames in the same way as page names, which meant converting things like doubled hyphens to a single replacement character. Obviously that's not compatible with the language JSON file name format, my mistake. I've modified it so that it now allows doubled hyphens, so it should be fixed now on dev. I was also able to duplicate the issue with the Setup and Access page titles/summaries incorrectly displaying in default language, so that should be fixed now as well. Thanks for reporting it.

I'm not sure you can directly compare modx and ProcessWire on load times unless you have them both in original state without any modules installed, except those required by the core. Even then, they may not be directly comparable unless they are accomplishing the same thing and providing the same level of tools at bootstrap. ProcessWire's boot time will be very much affected by how many "autoload" modules and running and how much activity they perform during their initialization process. It will also be affected by your overall quantity of modules, fields and templates. I would assume modx to be the same in that regard (assuming they have some equivalent of autoload modules, fields, templates, etc.). So whichever one is faster may have as much to do with how much stuff you are asking it to load as part of the bootstrap process. We do have a rather extensive API that most systems don't, so we do hand over a lot of ready-to-use tools to your template file and part of our bootstrap, and very likely most systems you'd compare PW to don't have near the scope of tools that we do. But we always want PW to have the best performance possible. In PW a "no api calls" page is not going to make any difference in the time of the bootstrap process, because execution of your code (in your template file) occurs after the bootstrap process. Again, I'd assume modx to be somewhat similar in this regard too. I did measure the time it takes for our bootstrap is a fairly blank state (with regard to modules) and found I was getting about 0.2s (200ms) bootstrap times. Admittedly, this is on a slow computer more than half a decade old, but did have APC enabled (APC is an opcode cache). Then I disabled APC and found they were at least 100ms higher. This is the time it takes ProcessWire to boot and give control to your code. As far as how long it takes after that depends entirely on you and what you are doing with the API. I would guess that in Soma's case, he's got a faster computer than me and perhaps with an opcode cache too. Even though my computer is old and doesn't have much in the way of horsepower, I thought there was some potential to speed up the bootstrap process (there is always room for optimization), so I've gone ahead and applied some optimizations to the dev branch, now available in PW 2.4.5. On the same computer as before, I've got the bootstrap down to 0.08s (80ms) with APC enabled, or 0.15 (150ms) with APC disabled (no opcode cache). This is with a logged-in user, so it's a pretty good performance boost. Is it possible to tell the difference in speed in person? No–we're talking about amounts of times that are beyond our perception (beyond my perception at least). But performance is always a priority in our core. And regardless of whether another platform might boot faster than ours or not, I think most would agree that ProcessWire's performance is always better in the areas where it really counts. In PW 2.4.5 (dev) if you want to measure boot-up times, there is now a "Timers" section in the debug info at the bottom, but debug mode must be enabled to see it. Keep in mind that debug mode takes up quite a bit of resources in its own right, so actual times would likely be less with debug mode off.

Great job Nikola! Fantastic theme! Thanks for making this. I really like how you've taken advantage of Admin Themes being modules with all the configuration options too. For anyone that wants to install this theme, you can do so easily just by logging in, click "Modules" then "New", and paste in "AdminThemeModesta" in the Module Class Name field.

Think of Lister as a powerful administrative tool, but definitely not a front-end tool. With much power comes much responsibility. You can access any piece of data in the site from ProcessWire selectors (and correspondingly, Lister), so it's not something you want coming from just any user's input. When it comes to ListerPro, that goes even further and lets you modify any piece of data in your site en masse.

The only ones I can think of that you would encounter in the core are template_id or parent_id. Those are used by Page reference fields, PageTable fields and possibly others. If you want to support things beyond that, I'm guessing you'd convert a template_id to a template name, and a parent_id to a page path? You are right that without knowing what the properties mean ahead of time, you'd probably need some interface that externalizes those values to something considered more portable. The thing is I'm not entirely sure that template name or page path would be entirely portable either? It might not always be preferable to the ID, and probably just depends on the situation. You'd instead need some kind of shared GUID that is independent of either system. That may not be realistic, so perhaps just a notice or confirmation during the migration process that certain properties would need to be double checked?

Netcarver, ProcessDiagnostics is beautiful–really enjoying it. I have one suggestion though, which is to either have ProcessDiagnostics install at least one of the diagnostic modules, or to have it display some error if none are installed when you go to Setup > Diagnostics. I tested on a new installation this morning (before I had my coffee) and couldn't figure out why I was getting a blank admin screen when viewing the Diagnostics page. After hunting around in the code trying to figure out why, I eventually slapped myself for forgetting to install any of the related Diagnose modules. But I'm guessing other people might run into the same thing.

Actually you don't need to do anything other than update your GitHub. The modules directory will pick up the new version automatically. However, it keeps a cache from GitHub so it may take up to half a day before it sees the changes. So if you don't want to wait for it you can always edit your module listing manually too.

Nico, tested out here and it works great. Thanks for making this. Just a few minor suggestions: 1. Your 'autoload' selector in getModuleInfo() works well, but might benefit from being more specific, like "template=admin, name=languages". 2. Your hooks to ProcessPageType might also benefit from being more specific, i.e. ProcessLanguages rather than ProcessPageType. 3. Rather than hard-coding the modules directory API key and base URL, you might want to pull it from the ProcessModule module, as it's possible for these things to change over time. Here's how you could grab them: $data = $this->modules->getModuleConfigData('ProcessModule'); $apikey = isset($data['serviceKey']) ? $data['serviceKey'] : 'pw231'; $baseUrl = isset($data['serviceUrl']) ? $data['serviceUrl'] : 'http://modules.processwire.com/export-json/'; Note that above is falling back to hard coded values just in case of an older PW version... not sure that's necessary (I don't remember when these configuration values were added to the core). 4. In your request to the modules directory web service, append "&category=language-pack" in the URL so that your results are limited only to language packs. Don't worry, you didn't miss this before, I just added the category filter option to the service. 5. Your module has downloadFile() and removeDir() methods that duplicate methods already available in the core. Basically, you can save yourself some code here if you want to. See /wire/core/Functions.php. 6. Your module is using ZipArchive. You might find it saves time and code to use the core's built-in wireUnzipFile($file, $destination); method, also in /wire/core/Functions.php 7. In your module's getModuleInfo() method it refers to version 010. Change that to just 10. The leading 0 will make PHP think it's an octal number or something.

MadHatter, thanks for your submission to the modules directory. This seems like a very good and useful module so thanks for making it. In reviewing the module, I had one suggestion/request: Because this is an autoload module, and because your $this->bad array gets populated from your init(), your bad passwords file gets loaded into memory on every request. That's ~73 kb worth of bad passwords that are loaded every time ProcessWire runs, which is a significant amount of memory. Because your bad password list is only needed at certain times (i.e. after InputfieldPassword::processInput), I wanted to suggest moving the population of $this->bad from your init() method to your checkPass() method. Or maybe you don't even need to bother with having a $this->bad array, and could keep it all localized to your checkPass method, as InputfieldPassword::processInput is not likely to be called more than once in a request anyway (i.e. no need to cache it).

PW isn't going to differentiate between wrong password and failed login. If it gave a different message depending on whether the error was with username or password, then the login form could be used as a tool for discovering usernames by dictionary attack (which would be undesirable from a security standpoint). Do your development subdomain and live domains use different /site/config.php files? Check if there are any differences in the $config->userAuthSalt line. Are there any differences in the PHP versions? While in your /site/config.php file check that you have a $config->httpHosts = array('domain.com', 'dev.domain.com', 'www.domain.com'); line in there (accounting for all possible hostnames). This isn't involved with passwords, but it can cause issues that might potentially have that appearance if not configured properly.

HTTP hosts, sessions, cookies don't come into play with passwords. Some other factor must be at play during that migration. Of course, a change in hostname will kill active sessions, since the session is tied to the HTTP host. But that's no different than if you just logged out. What can affect passwords is the PHP version and what capabilities it has with regards to encryption support. If you are running PHP 5.3.8 or newer (our current minimum requirement) then it won't be a factor unless you are moving to a PHP installation where the administrator has disabled some of PHP's encryption functions (which would be unusual and rather bad from a security standpoint). I kind of doubt that any of the above are it. What is more likely is a change to the $config->userAuthSalt (which appears at the bottom of your /site/config.php file). That particular value is generated randomly when you first install ProcessWire. It is forever tied to the passwords as a secondary salt. It's not technically necessary to have it, and passwords are already blowfish'd, but I've always felt better having one part of the salt disconnected from the database itself. If that salt changes or is lost, then all the passwords are forever broken. Is it possible you changed out the /site/config.php or even accidentally modified the value of userAuthSalt?

Just to clarify, all the recent messages in this thread have to do with the PageTable field, not the ProFields Table field. So the subject of this thread seems to have changed. They are completely different modules, and PageTable is part of the ProcessWire core (on the dev branch), not a commercial module. My responses below have to do with this core PageTable field since that's what all of the questions above are about. For people wondering about the ProFields Table field, please ignore this message. That behavior is intentional. It means you can have multiple PageTable fields on the same page storing their items as children of the page. You might even be using a PageTable field specifically for the purpose of managing children. Though perhaps an option to have them to default to a hidden status might be useful here. In your template page list settings (under advanced) you might also want to specify some other property from your PageTable pages to show in the page list, so that you can easily differentiate them from other children (if any) in the Page List. For instance, you might tell it to display the template name in addition to the page title. For situations where storing them as children is not what you want, then you'd want to specify your own parent. In fact, most of the time when I use PageTable, I specify my own parent where I want them to live, usually off in /tools/my-field-name/ or something like that. We don't want to prevent that because that would mean the PageTable now owns the children of that page and you couldn't use them for anything else, nor could you have multiple different PageTable fields storing their items as children. If you are in a situation where confusion is resulting from letting PageTable store items as children of the page, then that would be a situation where you'd want to specify what parent they should go to instead. In fact, I think that using PageTable with children is really for specific uses, and using PageTable with a specified parent is the more common use case. Try clearing your cache and hitting reload a couple of times in the browser. It looks like something isn't loaded. I'm honestly surprised you aren't seeing a JS error because it definitely has the appearance of that. Beyond the above, try switching your color theme back to "Classic" (just in case I missed something in the last CSS update). You can do this from Modules > Core > Admin Theme. If it's still not working right, I would try updating your core again just in case some files didn't make it through when you last updated it. Please let me know what you find.

Flavy, I wouldn't worry too much about quantity of queries. Instead, focus on the end results and how fast it performs. Quantity of queries means very little as you can have a 100 well optimized and/or simple queries that execute faster than a single complex one. So counting queries is more than often a waste of time, and trying to combine queries can even slow things down. The way that ProcessWire works is that it loads data on demand, as it is requested, using simple and well optimized and indexed queries that are very fast. That is, unless you check the box for "autojoin" in your field advanced settings. When checked, it will join that field's data with the original page query. For instance, we have the "title" field set to autojoin by default, since this is one field that is most likely to be accessed on any given page object. However, whether or not autojoin speeds up anything is debatable, so I would use it sparingly. It has potential to speed things up in some cases, but at the cost of memory, and cost of loading data unnecessarily. As a result, we only recommend it for fields that will always be accessed on every instance of a page. Beyond the obvious "title", examples might include a date or summary field used when outputting lists throughout a site. For the most part, I don't use the autojoin option at all anymore except for "title" fields because there is rarely a measurable benefit, but there is always a measurable drawback (loading stuff in memory that may or may not be used). You might also want to look at the "Cache" Fieldtype, which is included in the core. It's something that people rarely use, but it is directly applicable to your question. It caches all of your fields for a given page (or at least those you select) into one. It's more often used to combine several text fields together for searching purposes, but it can also be used to keep all your page data together in one chunk (and correspondingly, 1 query). Again, it may or may not result in faster performance in the end, but it's another tool worth knowing about and worth experimenting with. Other tools I recommend considering are MarkupCache (core module) and Template cache (a feature in any template settings). Or for the best performance, we also have ProCache, which makes your site perform as quickly as static HTML files. Most PW sites don't need much in the way of caching, but if you find you need it or want it, you've got some great options here. I agree with Antti that 100 fields will not be a problem. Many of us here regularly deal with more than that. But it also is good to think of fields as a finite resource and something that you want to conserve. While there is no technical limit on quantity of fields that you can have, it's possible for overhead to increase as the number of fields do. This isn't about page loading per se, but about overall system overhead and memory required to manage lots of fields at once. The ProFields package is specifically aimed at reducing the quantity of fields necessary to accommodate a site's data needs. Depending on what those needs are, it has the potential to drastically reduce the number of fields in your system. As a result, I think it makes a lot of sense for the needs you are talking about. You should also look into PageTable (on the dev branch) as a better option to repeaters.

Currency Conversion for ProcessWire This module is designed for performing currency conversions among ~165 world currencies. It uses OpenExchangeRates.org (or compatible) for data so that currency exchange rates are always up-to-date. It provides various API functions that you can use to convert from one currency to another. This is especially handy for generating rate tables in multiple currencies or giving users of your site the option to see prices in their currency. How to install How to use API documentation Modules directory page GitHub Page Download ZIP Live Example Requires ProcessWire 2.4.0 or newer. To use the quick-installer from your modules screen, paste in ServiceCurrencyConversion. Basic Example $cc = $modules->get('ServiceCurrencyConversion'); $dollars = 100; // amount of currency we want to convert $euros = $cc->convert('USD', 'EUR', $dollars); echo "<p>$dollars US Dollars equals $euros Euros</p>"; For a live example of a currency conversion tool built with this module see the included convert.php file and test it out here.

Individual images may not have a dedicated ID, but the page ID they belong to + the filename is always unique, so that's all you'd need. Of course, you could always manage pages-to-images on a 1-to-1 basis, but if you wanted to have a page with multiple images on it, each with their own URL, you could also enable URL segments for your template and output them like this: $filename = $input->urlSegmentStr; $image = $filename ? $page->images->get($filename) : null; if($image && $image instanceof Pageimage) { // output your image content echo "<img src='$image->url' alt='$image->description' />"; echo "<p>$image->description</p>"; } else { // output your regular content echo "<h1>$page->title</h1>$page->body"; } With regard to a likes system, is what you are looking for something similar to the likes system you see in our sites directory or the recommendations system in our modules directory (both are actually the same system). If so I can pass along a little more info on how that was done.

I still use your testing library every single day that I code PW. It covers all the most important scenarios, so isn't out of date at all. But I will plan to update the tests for the new selector options. It is feasible to support with repeaters, and if there's demand for it I'll add it. PageTable supports them already just because PageTable delegates huge amounts of its functionality to FieldtypePage, including the implementation where the @ grouping option is supported. File or Image fields. File fields can have descriptions just like image fields can.