ryan

I see ProcessWire as a system that you build things on top of, and that's the purpose of it. You don't download ProcessWire to start publishing content in 5 minutes (even if you can), but rather to build a site or application. So ProcessWire is much more of a tool to accomplish some end means, rather than the end means itself. ProcessWire and WordPress are completely different animals in this area (opposites really), and I think it helps to explain why you can't assume that WordPress and ProcessWire would be considered in the same light via the GPL. I think the GPL is flexible enough to handle both. That's not to say we might not switch to MIT in the future, just to avoid even having to talk about it. But I prefer to stick with GPL at this time. When it comes to my own commercial modules, I still consider them open source for the users that have them, and any fees paid are for access to and support of the product. The 1-year timeline applies only to support. You can continue using the products as long as you'd like.

These are styles, not semantic elements. Most of the time, these are exactly the things you don't want your client editing. Determining these things is part of the design process and its the designers job to come up with a typographic system that maps styles to these semantic elements. It's not a limitation, but rather a great thing for the client and their content presentation. Here are the things the client should determine: paragraphs headlines and what level of headline (h2, h3, h4, etc.) bulleted lists numbered list emphasized text (strong, em) contextual links contextual images, if necessary block quotes, if necessary possibly others if called for by the content (definition lists, tables, subscript/superscript, etc.) Note these are all things that say "what" the content is, and not "how it looks". The client should know that when they input content, it will look good and consistent with the overall design system. The designer has already determined the sizes, colors, line heights, etc. for all of these things, and they are defined in the stylesheets. If the site goes through some redesign at some point in the future, all that existing content will be restyled without any edits to the content itself. If you can convince them of the benefits and to use it, then yes. It's hard to beat the long term quality and portability of content kept in markdown or textile. However, I think a well configured TinyMCE/CKEditor (configured to focus on content, not style) is preferable to most clients I've dealt with. You can change it to a plain textarea by going to Setup > Fields > body > details > Inputfiled type > select "textarea". I'm a little embarrassed to link to this because my website is so old and broken right now, but I think the content is relevant here: http://www.ryancramer.com/journal/entries/cms-design-longevity/ (keep in mind this is from 5+ years ago, and my site is a bit broken at the moment).

Your code for setting the language based on the domain looks good. It should be fast, and fine to include in every page. If you wanted to set it to the session, then you would just do something like this (though it's really probably not necessary): if($session->language) { $user->language = $languages->get($session->language); } else { // determine language from domain // ...your existing code here, then... $session->language = $user->language->name; } I don't understand the issue you've mentioned with the homepage. Since the language is being determined from the domain (rather than the path), it really shouldn't matter what page you are on. Is it possible that you've got your output code happening before your language-determination code? Reading your message again, you mentioned that you only had the language-determination code on your homepage? You should really put it in every single template, via a common include (perhaps using $config->prependTemplateFile option). Let the language be determined on every request, regardless of page. There's no guarantee that traffic will always arrive via the homepage, not to mention the potential SEO issues with assuming that.

I had experimented with text-stroke here too, but at least in OSX, it just made the text fuzzy. It didn't seem desirable at all, at least as a cross platform solution. Last I heard, Arimo was looking good on the PC at current font sizes? Is something like text-stroke needed to increase legibility on the PC? The text looks a little fuzzy in both of those examples in the screenshot (maybe from jpeg though), especially the one with the text stroke.

Teppo is correct. Fancybox has IE issues (though wasn't aware it affected IE8 too). You may want to switch to the dev branch if this issue is affecting you, though we are dropping support for IE8 in the new admin theme. In either case, you really shouldn't be using IE8, just for your own security and sanity. IE is now at version 11? Though I'd recommend going for Chrome instead if you can.

I'm assuming your entries have been converted to pages already. Try editing one of those pages and making sure that its category field is consistent with what you expect. If all looks good there, it just comes down to regular PW API selection of the pages that you want. In your case, if you wanted to list the pages in category 'mats' you'd have API code something like this: $entries = $pages->get("/submissions/")->children("category=1018"); Using the ID directly like that "1018" may be efficient, but isn't usually very readable, so you may prefer to use a selector like "category.name=mats" or "category=/categories/mats/" or whatever suits your particular case.

User creation is an administrative task, so if you need non admin/superusers to create users, you'd probably want to create your own form to do it. It would be relatively simple. Creating a user from the API is as simple as: $u = $users->add('username'); $u->pass = 'password123'; $u->addRole('example'); // optional, if role other than guest needed $u->save(); From the sounds of it, you don't want to create actual PW users, but maybe something like them using pages. You could certainly do this (perhaps mapping them all to 1 single PW user behind the scenes). However, I'd encourage you to use PW's users. There is a roles system that is designed to separate users, so the typical way to maintain this separation is by role assignment.

Regarding the page-publish permission, this is an optional one. Most PW installs simply don't need it. When there is no "page-publish" permission installed in the system (which is 99% of installations), it is assumed that if you can edit the page, you can also publish it. If clicking the "publish" button doesn't remove the unpublished state of the page, I would look to a potential database or server issue, as that particular issue has not been reported before this thread. Or as Teppo mentioned, it could be admin theme related (?), so it'd be worth testing out on the default admin theme to be sure. If the issue persists, please post your PW version, MySQL and PHP version and any 3rd party modules installed.

Make sure you have URL segments enabled on your "home" template. This is in Setup > Templates > edit: home > URLs. At the top of your home.php, you should then be able to have something like this: <?php if($input->urlSegmentStr) { $name = $sanitizer->pageName($input->urlSegmentStr); $category = $pages->get("/categories/$name/"); if($category->id) { echo $category->render(); return; } else { throw new Wire404Exception(); } } The other side of it is making sure that your category pages have their $page->path and $page->url calls represent the location you intend. You can do this with a hook. You'd want to add this in your /site/templates/blog.inc file. wire()->addHookAfter('Page::path', null, 'hookPagePath'); function hookPagePath($event) { $page = $event->object; if($page->template != 'category') return; $event->return = "/$page->name/"; } Also for these examples, don't just copy and paste them. Go through line by line to understand how they work, as you may need to modify them specific to your case.

When you say that the editor doesn't appear, can you clarify? Does that mean you see nothing but a white page? Or maybe you see a plain textarea rather than a rich text field? Or just no field where there used to be one (as if it didn't exist?) Looking at the SQL error, do you know what language ID is 1160? I'm wondering if that might be your default language. It looks like you have the LanguageSupportPageNames module installed, just wanted to confirm? How many languages are installed? Do you have any other 3rd party modules installed? Lastly, you mentioned upgrading to dev, but do you know what version of dev? If you aren't sure what version, I may be able to tell if you know approximately what date you grabbed it.

I think that the date format has to have a delimiter somewhere (hyphen, slash, period or anything). ProcessWire assumes that a string of digits is a unix timestamp, so it's probably getting confused. I don't think we have a way of supporting a purely digit based date format. If you have that as your output need, you'd probably want to keep the date output format as unix timestamp, and then just use PHP's date() function on your front-end output.

Cloning seems to work for me. I did recently commit some fixes to cloning, which I think was in 2.3.7, so it sounds like you have the current version. Any other factors that accompany the pages you are trying to clone? For example, are you using any multi-language fields or language support? Are there any 3rd party modules? Do the pages have children or no children?

It's possible for it not to work on an Apache server too, if unzip isn't installed (which would be unusual) or if exec() is disabled (more common). There's also a chance unzip just isn't in the executable path on your server. You might see if you can locate where unzip is on the server.. it would usually be /usr/bin/unzip or /usr/local/bin/unzip. If you can login via ssh, you might be able to find it by typing "which unzip". Anyway, once you know where it is, you can take this line from /site/config.php: /** * uploadUnzipCommand: shell command to unzip archives, used by WireUpload class. * * If unzip doesn't work, you may need to precede 'unzip' with a path. * */ $config->uploadUnzipCommand = 'unzip -j -qq -n /src/ -x __MACOSX .* -d /dst/'; and prepend it with the server path: $config->uploadUnzipCommand = '/usr/bin/unzip -j -qq -n /src/ -x __MACOSX .* -d /dst/';

Actually you should be able to use "children.name=tarjetas", but I tested it out here and it behaves the same as "parent.name=tarjetas", so that is a bug. Looks like this is the first instance I've seen of needing to use something other than children.count. I've now fixed it, but am doing a little more testing locally before committing to dev.

asmSelect doesn't support keyboard input. How are you typing in numbers?

There are limits on field options no matter what route you take. Even a plain Select inputfield has limitations, in that it can't scale to thousands of items. The best bet is to find the solution that can select the pages you need to be selectable, then determine which of the available inputfields to use. There are lots of inputfield options in part because they aren't always interchangeable... each has their strengths and weaknesses.

Part of the goal with rich text editors (and LMLs even more) is to place limitations upon the input in order to maintain quality and consistency. ProcessWire's TinyMCE and CKEditor come configured to focus purely on portable and semantic markup. Once you start introducing non-semantic things in the markup like inline styles, colors, arbitrary font sizes, etc., then your content is no longer semantic or portable. It becomes essentially anchored to your current site design (if you are even that lucky with the client). You'd likely have to go back and make edits to all those fields the next time the site is redesigned. An even bigger problem is that when you give clients the tools to do these kinds of things, they start to get creative and think of it as an art project. But they blame you 1-2 years later when their site no longer looks professional. CMS control of style in text output ensures degradation of consistency and quality of output over time. For these reasons, you usually want to keep your content management tools (and especially rich text editors) focused purely on semantics of content, and as far from style as possible. This is one reason why I think front-end inline editors are a bad practice, as they keep the focus off the semantics of the content and on the subjective aspects of how it fits the area. Let all the style aspects be handled the site designers, in your front-end CSS stylesheets that accompany the site's design. If you still want to inject style, Hanna code is not a bad way to go because it does at least introduce some separation of concerns. It still leaves the content semantic, even if the underlying Hanna code isn't. If the site is for your own use and you are okay with the compromises, then both TinyMCE and CKEditor can be configured to let you do nearly anything you want. I'm not an expert on how to configure them that way, but if you look at the demos at either site, they have "all options enabled" configurations you can see and these configuration options can be duplicated in PW. Lastly, a plain textarea field (no rich text editor) on it's own also works well for just regular HTML input. This is what I use when I do need something that lets me copy and paste HTML directly, though it's something I'd only do on a site where I'm the only admin/editor (at least for that particular field).

No, it's also more efficient (technically faster) on the front-end. It's possible, but you'd have to go in and add them directly in MySQL using PhpMyAdmin or the like, and update the module's code to recognize your new field. Probably not. While the database could handle millions of rows, the admin side won't be able to handle displaying millions of rows in the same page editor. It would be the same issue as with using a repeater, at least from the admin display aspect. Though this solution could technically serve a lot more rows than a repeater could. It would not be as scalable as using pages, simply because everything around pages is already designed in consideration of scale (limits, pagination, selective loading of fields, etc.). Pages are certainly more resource intensive, but those resources go towards making them scalable.

When the need is there for separate DB configurations and something more than config-dev.php, I've done it like this in my /site/config.php file: switch($_SERVER['SERVER_NAME']) { case 'localhost': // set database settings for localhost break; case 'dev.domain.com': // set database settings for staging server break; default: // set database settings for production server } You should give preference to SERVER_NAME in this case (over HTTP_HOST) just because HTTP_HOST is coming from the client rather than the server (open to tampering). Though it doesn't really matter as long as your last "default" condition assumes the production server.

If you don't need the page to be saved when the button is clicked, then I think the route you are taking is fine. If you did need the page to be saved, then you'd want your button to be a submit button, and a second (save) hook to be called after the ProcessPageEdit::processInput and to silently do its thing (no redirect). Another route you could take is to setup a separate page with a template that does what you want, and then have your button link to that instead. But the way you've done it is already more compartmentalized (less parts to consider) so I wouldn't change it unless it creates issues with other modules hooking into ProcessPageEdit at some point down the road (which is possible). One issue you probably want to fix here though is the potential for XSS: $href = $this->config->urls->admin.'page/edit/?id='.$this->input->get->id.'&e=1'; Taking a variable directly from $_GET or $input->get and putting it in output (unsanitized) is always dangerous. You'd want to do this: $id = (int) $this->input->get->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1"; or better, yet this: $id = (int) $event->object->getPage()->id; $href = $this->config->urls->admin."page/edit/?id=$id&e=1";

To match a partial word in the middle of it, you'd need to use a non-fulltext-indexed search. That's because fulltext indexing indexes full words, not parts of words... it can only match full words or words beginning with some text. To use a non-fulltext-indexed search, use the %= operator rather than the *= operator. This highlights a core difference between *= and ~=. The *= operator is matching an exact word or phrase that begins with your term. The ~= operator is matching full words, but they can be matched no matter where they appear in the text / in any order. The %= operator behaves very much like the *= operator except that %= can match in anywhere in-between words too, not just words/phrases that begin with something. So long as the $user->language is set to the language you intend to search in, it will give preference to that language in performing the search.

This is a good way to go, and exactly what I do for predefined settings like required image dimensions and such. What you set in _init.php is for runtime use of your site's template files, and probably nothing beyond that. These variables are good for initializing placeholders that you'll be outputting in your _main.php (or whatever your appendTemplateFIle is called). This sounds like overkill to me, though of course use what works best for you. But you have a couple more options to consider: Use session variables, especially when you want the value to still be present and available on not just the current request, but subsequent ones (from the same user) too: // do this $session->set('my_variable', 'my_value'); // then retrieve it from anywhere (and at any later request) like this: $my_value = $session->get('my_variable'); Set an API variable: // do this wire('my_variable', 'my_value'); // then retrieve it from anywhere like this: $my_value = wire('my_variable'); Whichever route you take there, if you've got a lot of related values to set you might want to bundle them all into an array, so that you only need to set 1 session, API or config variable.

"id!=$config->adminRootPageID|$config->trashPageID|$config->http404PageID", That part above probably isn't necessary in the selector. The "template!=admin" and "has_parent!=$config->adminRootPageID" will probably cover everything you need (assuming you want admin pages excluded from last modified listings). While you could exclude the 404 page, I'm guessing that's one that probably rarely if ever ends up in a modified list anyway.

Beautiful work!

The export profile module is 2.3 compatible, but not when it comes to multi-language sites using the core LanguageSupport modules. That's something that's been on my to-do list for awhile. I just don't use the Profile Export module often enough, but hope to update that a little after 2.4 is released.