ryan

It looks like this could probably go in any JS file or any output that can produce a <script> tag, or even the admin theme. So there are lots of places you could get it in there. But I think the best place would be in your /site/templates/admin.php because this file is not overwritten during upgrades. Add this before the code that's already in there: $config->scripts->add($config->urls->templates . 'scripts/date-localization.js'); Then add your code to the file in /site/templates/scripts/date-localization.js

That could be. It doesn't look like AdminBar is yet confirmed compatible with 2.3. There's a good chance there's a JS error occurring. 2.3 uses significantly newer versions of both jQuery and jQuery UI, so JS errors are the most obvious places to look (and usually the simplest issues to resolve). Are you seeing anything in your error console? (In Chrome: View > Developer > Javascript Console).

It sounds like these are all PageArrays? If the items in it are going to be of varying types, you could make the output loop check the type to determine how it's going to render it: foreach($items as $item) { if($item->template == 'product') { // render a product } else if($item->template == 'repeater-photos') { // render a photo from a repeater } else { // ...and so on } } Another approach would be to let the items render themselves via their template files. Your product.php and repeater-photos.php templates (for example) could just be coded to render nothing but the markup for their individual item. Then your loop would be essentially this: foreach($items as $item) { echo $item->render(); }

Yes, I think that a lot of modules currently in the core should be removed from the core. But we can't just remove modules from the core because that could break someone's site during an upgrade. So it has to be part of a longer plan that involves a custom-download packager (enabling one to download PW with user-chosen modules included), and tied to a major version where users would be expecting something more to an upgrade process. I actually think CKEditor's download packager is a pretty good example of what would work well for us. You can browse their plugin directory and click "add to cart" (or something like that) to add any given plugin to your CKEditor download. Then when you "checkout", you are downloading a CKEditor ZIP with all the plugins you wanted, ready-to-go.

At least in ProcessWire, the tree is far more scalable than a linear bucket system like in EE. If it helps to conceptualize, think of ProcessWire as having a tree of buckets. This is the natural way the web works. If a single-level linear bucket system suits your needs, then you can do this in ProcessWire. But there's a good chance you can do much better. So I would argue that your statement about buckets vs. trees is backwards. In terms of scalability, a tree will take you much farther. But it does require that each branch in that tree have the ability to function as an unlimited bucket. This is exactly what ProcessWire does. Also consider that websites have hierarchy by nature, need and design. That hierarchy is extremely useful and powerful, and should be embraced. Websites lacking hierarchy would be limited, for obvious reasons. When working with a linear bucket system, you are always mapping a hierarchal system to buckets. This has always struck me as completely unnecessary, complicated and unfortunate. This mapping and conversion is ultimately a side effect of having to reduce a powerful system of tree hierarchy (upon which the web is based) to a less powerful bucket system. But if the system embraces the natural hierarchy of the web, then no mapping or conversion is necessary. You are working with the tree either way. The question is whether the system is embracing and using it (like ProcessWire), or mapping it to a more limited system of linear buckets. I don't have enough experience with MODX to know what the "resource tree shortcoming is", but am guessing it's something to do with pagination that others have mentioned before? I know that MODX has a reputation for being quite scalable, so would guess that they just have a different approach to managing that scale. But once you have worked with trees, and really experienced the benefits, it's very difficult to go back to buckets, IMO. The words "tree" and "shortcoming" simply do not go together. As for keeping more than one CMS in your toolbox, I think that's always a good idea. It sounds like MODX and ProcessWire have common ground in terms of philosophy, and these two would be good to have in your toolbox. I don't think I would bother with keeping a bucket-based system in your toolbox, except for perhaps WordPress, which can be handy in the right situations (like one-off blogs when client has very limited budget). ProcessWire is pretty much infinitely scalable, within the boundaries of a server, SQL database and file system. As scale increases, you do have to practice care in how you use the API. ProcessWire gives you a lot of power, and will fill up your memory if you tell it to. So you have to use common sense when using the API at the large scale. For example, an API call like $page->children(); might be referring to a million pages. Do you really want to load and display links to a million pages at once? (probably not). Does the server have enough RAM to keep a million pages in memory at once? (not likely). So you accommodate scale by specifying limits and using pagination, like $page->children("limit=50"); This is something you don't necessarily have to consider at the smaller scale. But I think it's a good practice to design and develop every site as if it could grow infinitely. Do you need to learn PHP? Not any more than you would need to learn the {tags} from another system, like EE. The time investment and scope of what you'd have to learn would be about the same, maybe even less with ProcessWire. In fact, you can do almost anything in ProcessWire by simply learning how to use just two API variables: $page and $pages, and knowing what a PageArray is. There are a few bonuses you get from learning PHP vs. a tag system though: Whatever you learn about PHP is something you can take with you, beyond ProcessWire. The more you learn about PHP, the more you can do, both inside and outside ProcessWire. Meaning, the environment can grow with you, when and if you want it to. Whereas, at some point, you'll start hitting your head on the ceiling in a {tag} environment. ProcessWire's API is identical regardless of context. You can be in a template file, command line script, plugin/module, etc., and everything works the same. In a {tag} environment, if you want to grow and learn plugin/module development, you'll be starting from scratch. In ProcessWire, everything you learn applies throughout the system in any context. It's only a small step to go from building templates to building modules. In {tag} systems, it's a canyon. In fairness, while you don't need to know much about PHP to effectively use ProcessWire, you may indeed need to learn more PHP to accomplish some of the things you've set out to do: paid membership and access, member signup forms, etc. ProcessWire is a tool more than a turn-key solution for these particular needs. While they aren't difficult to accomplish, you might find yourself doing more on the code side than you would with a system that has turn-key solutions for membership sites. If your project budget/timeline doesn't give you the room to learn and build these things, you would want to investigate more ready-to-use solutions for these. But I think you would do well to make friends with and use ProcessWire either way.

I'm not sure that I totally understand the entirety of what you are doing, but it is relatively simple to copy page references from one page to another: $page1 = $pages->get('/some/page/'); // page we want to copy from $page2 = $pages->get('/some/other/page/'); // page we want to copy to // optional: remove any existing categories if there are any $page2->categories->removeAll(); foreach($page1->categories as $category) { $page2->add($category); } $page2->save();

When you've got your first release version ready (if it isn't already), please post to the modules directory too.

The timepicker is not actually part of jQuery UI. It was an add-on created by Trent Richardson, as jQuery UI's datepicker does not have a timepicker. There is a tab on localization for this timepicker available here. Does this help?

Yes, I merged it to master yesterday. I just don't think there's any reason for new users (especially) to be starting with 2.2.9 at this point. The dev branch is more stable than 2.2.9. Now we can go back to letting the dev branch be a dev branch. I'll send out a 2.3 announcement later this week. While there are always more issues to resolve, there haven't been any major problems since people started testing. Nearly all issues that have come up have been related to needing a modules cache clear, or needing to start with a fresh /wire/ dir–things that people should do for any ProcessWire upgrade. I have now added these items to the upgrade instructions in the new README file included with ProcessWire. People upgrading from 2.2 to 2.3 should still follow all upgrade instructions exactly, backup, use caution and test thoroughly. Here are the upgrade instructions as they appear in that readme file: Best Practices Before Upgrading Backup your database and backup all the files in your site. When possible, test the upgrade on a development/staging site before performing the upgrade on a live/production site. If you have 3rd party modules installed, confirm that they are compatible with the ProcessWire version you are upgrading to. If you cannot confirm compatibility, uninstall the 3rd party modules before upgrading, when possible. You can attempt to re-install them after upgrading. General Upgrade Process If you are upgrading from a version of ProcessWire earlier than 2.3, see the sections below for version-specific details before completing the general upgrade process. Upgrading from one version of ProcessWire to another is a matter of replacing these files from your old version with those from the new: /wire/ /index.php /.htaccess Replacing the above directory/files is typically the only thing you need to do in order to upgrade. But please see below for more specific details about each of these: Replacing the /wire/ directory When you replace the /wire/ directory, make sure that you remove or rename the old one first. If you just copy or FTP changed files into the existing /wire/ directory, you will end up with both old and new files, which will cause an error. Note that the /wire/ directory does not contain any files specific to your site, only to ProcessWire. All the files specific to your site are stored in /site/ and you would leave that directory alone during an upgrade. Replacing the /index.php file This file doesn't change often between minor versions. As a result, you don't need to replace this file unless it has changed. Replacing the .htaccess file Like the index.php file, this doesn't always change between minor upgrades, so the same applies. This file is initially named htaccess.txt in the ProcessWire source. You will want to remove your existing .htaccess file and rename the new htaccess.txt to .htaccess. Sometimes people have made changes to the .htaccess file. If this is the case for your site, remember to migrate those changes to the new .htaccess file. Upgrading from ProcessWire 2.2 Follow the general upgrade process above. You will want to replace your /index.php and .htaccess file as well. Clear your modules cache. To do this, remove all of these files: /site/assets/cache/Modules.* Login to ProcessWire admin. You may get an error on the first web request you try, but that should only happen once, so just reload the page. Upgrading from ProcessWire 2.1 First upgrade to ProcessWire 2.2. (side note: I'm not positive this is necessary, you may be able to go straight to 2.3, but I didn't have any 2.1 sites to test). Follow the instructions above to upgrade from ProcessWire 2.2. Upgrading from ProcessWire 2.0 Download ProcessWire 2.2 and follow the upgrade instructions in that version's README file to upgrade from 2.0 to 2.2. After successfully upgrading to 2.2, follow the general upgrade process above. Troubleshooting an Upgrade If your site is not working after performing an upgrade, clear your modules cache. You can do this by removing all of these files: /site/assets/cache/Modules.* If your site still doesn't work, remove the /wire/ directory completely. Then upload a fresh copy of the /wire/ directory. If your site still doesn't work, view the latest entries in your error log file to see if it clarifies anything. The error log can be found in: /site/assets/logs/errors.txt If your site still doesn't work, please post in the ProcessWire support forums.

What admin theme is that? Since that looks like incomplete output, if I saw that screenshot you are seeing, the first thing I would do is CTRL+A (select all) to see if any error messages were present. If there weren't any, then I'd either look at the error log (/site/assets/logs/errors.txt) or enable $config->debug=true; in /site/config.php. Then I'd try again. When you say you moved it from /blog/ to /, what specifically did you move (files/directories) and how did you move it? If I were to do that here, this is what I would move: cd htdocs mv ./blog/wire ./ mv ./blog/site ./ mv ./blog/index.php ./ mv ./blog/.htaccess ./

If you are running into the same issues every time you migrate (regardless of server), look into what tool is being used to transfer files. Make sure you are using something that retains file permissions and that does some QA to make sure the files actually made it. Personally, I've always used rsync and it's always worked quite well. If the server doesn't give me shell access, then I'll use SFTP/FTPS with YummyFTP (OS X). I'm not aware of anything like this. While you could use ProcessWire from the API without functional sessions, you couldn't login to it if sessions weren't working. And you couldn't do anything if the DB wasn't functional. If sessions aren't working, just double check that your /site/assets/sessions/ directory is writable.

Not as far as I know. But this is a better question for Soma. From what I understand, LanguageLocalizedURL works very differently. LanguageSupportPageNames and LanguageLocalizedURL modules are not equivalents in functionality. But I think there is still some crossover, so individuals would probably want to evaluate both to see which meets their particular needs better.

I don't know what the threshold would be. But for me, if I was having to manage more than 10 pages separately in two languages, then I'd probably want to start using multi language fields and page names. Of course we've had multi language fields for quite awhile now. But the new LanguageSupportPageNames module really makes them worthwhile. I have to launch a site in April that uses this system, so I expect this to be production-ready in the core by then. Though it's all working in the core now (in the dev branch) and has been stable for me during development of this site.

Looks very cool Luis! I look forward to trying this one out after the weekend.

Most of the time a non-superuser wouldn't have access to template settings, so they shouldn't be able to re-enable that option.

Since your site is simple like you say, I would just make one branch in the tree per language. i.e. /en/ /about-us/ /contact/ /es/ /quienes-somos/ /contacto/ If you want to be able to translate static text in your template files, you'll want to also use code internationalization. Solutions like LanguageLocalizedURL and the new LanguageSupportPageNames become more valuable when the scope of maintaining two trees (like above) becomes too much work. But if it really is a simple/small site, then keep it simple.

ProcessWire doesn't output any 501s, so those are most likely getting sent from the web server before PW even gets a chance to boot. If you were running Apache, I'd say the first thing to look at would be mod_security meddling in requests. But since you aren't using Apache, maybe there's something like mod_security that is blocking certain patterns/combinations of requests that it thinks look suspicious? That would be my best guess anyway.

Thanks Soma, I see that too. Not sure why it's doubled up. I'll take a look and find a fix.

If PHP's garbage collector isn't working right, it'll affect DB sessions too. @joe_g, unless your site really handles that many sessions in a day, you may want to look into your PHP garbage collector settings. The relevant PHP settings are session.gc_probability, session.gc_divisor and session.gc_maxlifetime. We set the gc_maxlifetime automatically based on your $config->sessionExpireSeconds setting, but not the other two. However, you can force specific settings for those by adding lines like this to your /site/config.php file: ini_set("session.gc_probability", 1); ini_set("session.gc_divisor", 100);

You might want to also look at using the YouTube/Vimeo Textformatter module on your body field. It includes a responsive option as well in the module settings.

That should work. You could also do it this way: $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $pages->get((int) $idioma_id); if($p->id && $p->viewable()) $page->htl_idiomas->add($p); } However, something that is missing that you definitely want to add is more validation. Meaning, check to make sure that the pages you are adding to itl_idiomas are in fact the pages you intend. This prevents the possibility of someone manipulating the POST values to include page IDs outside of those you allow. So I would do this instead: $idiomas = $pages->get('/tabla/idioma/')->children(); $page->htl_idiomas->removeAll(); foreach($input->post->htl_idiomas AS $idioma_id ) { $p = $idiomas->find("id=" (int) $idioma_id)->first(); if($p && $p->viewable()) $page->htl_idiomas->add($p); }

I don't think we are changing any defaults in this area, unless Antti can think of anything? But we are using the 4.1 (dev) rather than the 4.0 (stable) version of CKEditor, so maybe that's where the difference comes from. As far as I know, CKEditor doesn't have that capability. It's possible there may be a CKEditor plugin that provides it though, but I've not seen one yet.

One thing I want to mention is that you don't want to actually have a field of your own called "status", just because that is already a built-in field for every page. That is on our reserved words list, so I don't think PW will let you create a field with that name, but just wanted to mention it.

User information is not stored with files/images at present. However, you may want to install Teppo's Changelog module and Netcarver's Field change notifier module, which may accomplish some of what you are looking for.

Marc, you may want to change your hook from "save" to "saveReady" or "saved". If you use "saveReady", then you won't have to perform your own $page->save(); since you'd be hooking in right before $pages does it's own save. This is the same as a before "save" hook, except that it's been confirmed that a save will definitely occur, so a little safer. However, you'll probably want to add something at the top of your hookSave() function like: if(!$page->id) return; so that it doesn't get involved with pages that are about to be saved for the first time. If you use the "saved" hook (available in the dev branch of PW), this is essentially the same as what you are already doing, just a little safer, since it wouldn't get called if an error occurred in save(). Though for most practical purposes it's equivalent. I would probably look into using "saveReady" just because that could reduce what's currently happening in 2 saves to just 1.