ryan

Were you able to complete the install before the 500 started occurring? If so, did you get any error messages, particularly during the compatibility check? I'm assuming this is an Apache 500 error, and not a ProcessWire 500 "Unable to complete this request due to an error" message. To me it sounds like something specified in the .htaccess is disallowed by the host. The best way to troubleshoot is probably start commenting stuff out in there by placing a '#' in front of each line, testing one at a time.

Here are all of my experiments, which are a little larger (after you click on them), but not much. There was also another thread here that had some nice examples from Diogo, Mademyday and others, but I can't seem to find it.

Thanks for this module Adam! What most people don't know is that Adam doesn't just write in Markdown, but also speaks in Markdown.

Great work niutech! Thanks for putting this together. This seems like a really nice implementation you've put together here that plugs in effortlessly. In addition to being a great solution for those that want to use Smarty, it's also a great example of how one can implement a template engine with ProcessWire. Excellent readme too. One suggestion, related to what Soma said. Though this is minor. Your repo has a /wire/modules/ directory, and you might want to move /modules/ to your /site-default/ directory. Ultimately you can run a module from /wire/modules/ but it'll get wiped out every time you upgrade. So it's just a lot safer to keep them in /site/modules/, which gets retained through upgrades. Since people often skim through a readme, they might use your /wire/ dir as a guide rather than the readme. While less important, it might also be better to use /site/ rather than /site-default/, since /site-default/ is just a dir that would be present on an uninstalled copy of PW. Please add this to the modules directory at your convenience: http://modules.processwire.com/add/

Also check to see if there is any error message in /site/assets/logs/errors.txt

Also make sure that you've got a /site/install/files/ dir in your profile, even if it's empty. I'll remove this dependency from install.php soon though.

There isn't. But that's not really an official logo either. It was just a photoshop experiment. I liked it, but nobody else did, so you don't see it on the main site.

How much data are you talking about? What kind of queries would you be performing on the data? The vast majority of things you can do from ProcessWire's API, but we also don't try to cover the entire scope of MySQL either. So I'd be curious to know what kind of statistics you are pulling out of the database currently, before recommending whether you should use pages for the purpose. You could absolutely do this. Creating a custom admin section is as simple as: a) creating a new template, then creating a new page in admin that uses that template; or b) creating a new Process module, then assigning it to a new page in admin (that uses template 'admin'). The admin itself is nothing more than a web app created in ProcessWire… you can extend it in the same way you would your own site.

You can do this. Whether you choose to go the direction of user accounts and admin access is another question. For modules.processwire.com people can submit modules to the directory. When they submit a module, they also enter their email and password. That info gets saved with the module, so that anytime they want to come back and make edits, they can. I'm not using user accounts for this because my needs here were pretty simple. This method also requires using the API to code it to do exactly what you need... but it's not difficult. You can also use user accounts (and even admin access) if you want to. Though I recommend limiting admin access (even limited admin access) to trusted users. With trusted users, the Page Edit Per User module opens up many possibilities here.

Currently there isn't a way (that I know of) to have different user types. Meaning, whatever fields you add to your 'user' template are going to be present for all users. However, you could always create other templates with whatever fields you need, and then relate them to the users via Page references. You could also use tabs or collapsed fieldsets to hide sections that aren't applicable to all users. In terms of navigating in the admin: ProcessWire admin is nothing more than a website written in ProcessWire. If you think of it that way, you can swap out of any of it's components (Process modules) or make your own templates that display exactly what you need. You can add a new page in the admin just as easily as you can add a new page on the front-end of your site.

Nice update, thanks Nik. This module puts a smile on my face every time I use it.

Soma, that's a good find. I'm pretty sure I know why this is the case. Right now when it executes a match on other pages, it doesn't specify an "include" setting, meaning pages can be excluded. It probably should not be that way. I know where to make the change to fix it (it will be easy), but the question I'm struggling with is whether it should be "include=all" always for subfields? After all, we're not technically matching the pages the subfields live on, just the page that references them. It seems to me like it should always be include=all, but I also worry if I'm not thinking through all possible side effects.

I'm still totally confused about exactly what you are doing but it definitely sounds challenging and interesting. Please let us know what solution you ultimately find. A screenshot might ultimately help to clarify too.

Good points in your notes. I wrote a somewhat related article several years ago, some of which might still be relevant (and some not). I think HTML is totally fine for an editor as long as it's used as just markup, and not style. I mean basic things like, this is a headline, this is a list item, this is a blockquote, etc. That means essentially using it within the same limitations as an LML, but with the Word-like interface that clients refuse to do without. This is how we've got TinyMCE configured by default ... not so impressive to look at, but also not too dangerous. It's when you start getting into "this should be this size" and "that should be this color", and so on (style), that it becomes a problem… at least for anything scalable. And the issue with wysiwygs like TinyMCE and CKEditor is that they do both. So you have to put a lot of restraints upon it. But the temptation of eye candy, impressing the client, and giving in to their demands can make the broad capabilities of these editors a curse. Companies even win project contracts by these capabilities because they are such eye candy… "You'll be able to edit your web site just like you edit your Word docs" is an unfortunate selling point. The fact that you can do some fancy (but ultimately not so good) things with it means that the danger is always there. Joomla has obviously crossed the line here. But you are right, the big picture is that it's the nature of wysiwyg and not Joomla. I would prefer an editor that had less grey area.

The configuration options are a little different between checkboxes and autocomplete. I don't think they are as directly replaceable as select-multiple, checkboxes and asmSelect (for example). So may take some re-configuring of the field when you change the type. It sounds like you may be talking about something more though, so I'll experiment here.

I was originally thinking it would be something fairly simple where you could just swap out the files from the default profile with new files, and have it ready to go. And that would be plenty useful. But it would probably be better to go further and try to account for most of the elements. At least, I think this would be more useful to people that want to literally use it to build a site from. So it would be nice to have more than what's currently with the default profile... like a template that uses the slideshow (or ability for any template to use it), a contact form, ability to use the various list styles and menus/button bars, tables, captions with images, icons, etc. (we'll need Soma's expertise with configuring TinyMCE for some of this). All the while keeping the layout and look simple and generic enough that someone could also easily build from it as a base. How about you handle the front end and I'll handle the back end? Let me know if that's of interest, or if you have other ideas? Perhaps some of this overlaps with your plans for HTML KickStart too? If we were to collaborate on this, it seems like it would be not just another profile but more likely one to replace the default profile included with ProcessWire (which is in need of replacement). Though I do think it's important that the next default profile be a little more mobile-friendly than the current one is. Anything that takes the default profile further also means we should include a second "blank" profile with PW (which we don't currently do, but I think we should). I was also excited to hear about your plans for HTML KickStart. Thanks for the shoutout too.

Making that change should be fine. I can't think of any potential side effects.

Any news on this? Wondering if you guys found out what was causing it?

Sorry jacmaes, I didn't catch that earlier. But yes, ProCache will be able to cache m.domain.com and domain.com separately, so would work well in that type of setup. Support for that is not yet there, but likely will be over the next week.

Thanks guys, I will check these tools out. Lightweight text editor is what I've already got. And XML files are usually pretty good at self describing themselves. But this XML file is definitely not setup for human readability. So I need something that will parse it and make it human readable. It sounds like there are some good options here. Thanks again!

If that's all there was to it, I wouldn't have bothered spending weeks developing ProCache. Likewise, if all a CMS needed to do was save and display the contents of a textarea, then I wouldn't have bothered making ProcessWire. While we use an entirely different method, capturing output from a PHP script and caching it is relatively painless. It's knowing when to save a cache and when to expire, how to maintain and freshen the cache, how to handle the security, URL segments, page numbers, configuration, etc., that's the hard part. There's a reason why this is a commercial module.

Does anyone know of any good tools for analyzing giant XML files? I'm dealing with a pre-web services era feed, which is just a giant XML file (20+ mb). I need to write something that imports it to ProcessWire pages every hour. The trouble is that it's a rather complex feed with thousands of tagged elements. The size of the feed is such that it makes it particularly difficult to analyze. For instance, it's a bit too large to navigate with browser-based XML tree plugins (at least, with those I've tried so far). I'm trying to find a way to break this into smaller chunks so that I can make some sense of it. Does anyone know of any software tools or services that can help with navigating through a giant XML file?

What do you guys think of Unsemantic? I've only read about it, but thought it sounded appealing in a Skeleton-framework kind of way.

Rather than an external service, it could probably be accomplished most easily with just a local cron job that does something like this: curl --data "procache=force-save" http://domain.com/path/to/page/ > /dev/null The "procache=force-save" would be some user defined variable that we update ProCache to look for and then force saving the cache when present. You'd need to do this for every page you wanted to ensure was always cached, so maybe not that practical. But might be if you just need the homepage or a small set of pages to never display non-cached versions.

Well that's what processwire.com is for. de.processwire.com is for those that want to read about ProcessWire in German. I'm guessing people would still find out about PW from processwire.com first, and go to de.processwire.com to read about it in German. So it probably does make sense for the DE site to at least be a little more copy oriented than the main site, simply because that's the underlying purpose (native language). But my comment was really more just humor, brevity is an asset regardless of language.