teppo

I kind of like these, though the lyrics don't make any sense to me Funny thing though; title of second song, "Kansanlaulu", is Finnish word for "folk song." Does that mean something in Czech too? Wouldn't, of course, be the first time a band took song name that sounded "cool" or "funny" from another language. Speaking of folk songs (kind of), I've recently taken a liking to the debut album of Finnish composer Antti Martikainen, labeled "Creation of the World". Works wonders when I'm trying to forget my surroundings and concentrate on one thing, such as writing code

@ryan: timepicker seems to support translation system identical to datepicker. Is there a chance that you could somehow include it's i18n files (in jQuery UI i18n directory or with the inputfield module itself) and ability to load selected one (perhaps in same way as with datepicker) at some point?

@gebeer: please take a look at my answer to your original post here. Does it solve your problem here too, or is this something different?

@gebeer: you need to translate /wire/modules/Inputfield/InputfieldDatetime/InputfieldDatetime.module file via Setup > Languages, i.e. the built-in multi-language support. Once you start translating that file, insert the datepicker translation file you wish to use into the first input titled "Datepicker translation file." You can see a list of available translation files here: https://github.com/ryancramerdesign/ProcessWire/tree/master/wire/modules/Jquery/JqueryUI/i18n. To get german translations, you'd insert "/wire/modules/Jquery/JqueryUI/i18n/jquery.ui.datepicker-de.js" etc.

@Neeks, your suggested idea sounds kind of fun, but also not very useful. [[block=myblock]] would be equal to [[myblock]], except that you'd have a lot of your "blocks" within one single Hanna Code.. which is exactly what individual Hanna Codes are meant for. About your question: in your example code you're assigning /settings/blocks/".$title to $mypage and later asking Hanna Code to render $page->body -- while you probably meant to render $mypage->body. Is this just a typo in your example code here or could this be the issue with your original Hanna Code? Anyway, even if this can be fixed, wouldn't it make more sense to have a [[block type=something' title='something else]] Hanna Code that finds a page (let's call it $block_page) and then renders it with $block_page->render(), i.e. by using ProcessWire's full template system? Is there a particular reason why you're trying to move your template level stuff into Hanna Codes? I'm afraid that's not really what Hanna Code was intended for, at least as far as I'm aware. Hanna Codes are snippets you can drop in your code -- once you find yourself building complex logic with them, you'd probably be better off by using other PW features instead

@3fingers: sorry, I had managed to miss your question. This is exactly why I added JSON view to the latest changelog version, i.e. you could use PHP or JavaScript to request same data as JSON and parse that to whatever you need. If the module is installed to default location, you can get this data from /processwire/setup/changelog/json/. Various search parameters (GET params) also work there. Ask if you need more detailed description, I'm in a bit of a hurry right now

Philipp is right -- this is roughly the logic I used a while ago: if ($input->pageNum) { $limit = 15; // whatever limit you're actually using if ($input->pageNum > 1) { echo "<link rel='prev' href='{$page->url}{$config->pageNumUrlPrefix}".($input->pageNum-1)."' />"; } if ($input->pageNum * $limit < $items->getTotal()) { echo "<link rel='next' href='{$page->url}{$config->pageNumUrlPrefix}".($input->pageNum+1)."' />"; } }

@pwired: ApiGen docs are outdated, based on 2.2.0 codebase. Method wireCopy was added six months ago and isn't even current master branch yet.

@gebeer: Have you tried if "Unpublished" (capital "U") works? Just a guess, but it could be that Edit: my guess was wrong; lowercase would work just fine. The issue is that the code Martijn posted above is from dev branch. If you're running stable (master) branch of ProcessWire, that won't work for you.

Try $page->is() with status code flags. Example: if ($page->is(Page::statusUnpublished)) if (!$page->is(Page::statusUnpublished))

.. and of course there's always GitHub. If you're really wondering "what is function x, where does it come from and what does it do", try searching

@3fingers: good plan, except that the problem is more about mobile connection than mobile devices (whatever those are these days.) In my use case, for an example, the device is laptop with pretty good screen size. Screen size has nothing to do with bandwidth, so unless you're waiting for bandwidth media queries, you're out of luck with that approach (Oh, and by the way: above syntax, perhaps because it's taken out of context, looks like it'd still load the fonts, effectively making this whole thing useless. This could be prevented by mobile first approach, for an example, but that won't remove the bigger issue, so it's really not worth it.)

@dragan: take a look at ProcessChangelogHooks.module and especially it's logPageEvent method. It does a bit more than this, but you could probably use parts of it pretty much directly.

When a client asks for "a website" with "easy management", explaining that ProcessWire is "an awesome framework for building just about anything" feels plain wrong and is unlikely to yield desired results. On the other hand, when client (or fellow developer) does mention the need for "an application", "framework" or "software platform", it's good to be able to match those needs too. Personally I really like the fact that ProcessWire has the ability to be both and would like to avoid emphasizing either *too much* over the other. If I needed a CMS, there would be a huge amount of other options available, and if I simply wanted to build an application I could (for an example) turn to Zend Framework and get the job done.. and so on. What ProcessWire brings into this equation is a well-balanced combination of features from both worlds. Each part supports the other, eventually making it more than the sum of it's parts. I especially love how easy and fast built-in admin makes mocking up data structures -- in fact it's such a smooth experience that the times I've built mock data manually for HTML wireframes etc. have been almost nonexistent lately. I find it faster to make fully functional features using ProcessWire than writing dummy directly with editor. And that, in my opinion, is why it's so damn good. Not that I really needed to explain it to anyone here, but my point is mostly that I don't see ProcessWire simply as a CMF or CMS or application framework or whatever. It's all of these combined.. and that's a good thing. I hope we don't get stuck discussing which one it is when that question can't (and shouldn't) have one single correct answer

It's a bit late to suggest this, but I'd like to seriously question if we really need Arimo. What's it's greatest benefit here? Is it more usable, readable etc. when compared to "web-safe" alternatives or is it purely a visual thing? Personally I can't see anything being so great about it, not even that visual part, but what I can see is a pile of issues. I prefer my fonts to load fast and be readable, that's all, and at the moment I feel that neither of those has improved (quite the opposite really) in this new admin theme. To summarize this, it just seems questionable to me if Arimo is really worth it. I can't see any real benefits, but then again, I'm not the typography guru here either (Note: having to rely on a very slow mobile connection for a while has definitely affected my opinion, as you can see from the attached screenshot. That's not even funny anymore and I've been seeing it a lot lately. Not saying that it's a typical situation, but it's not unheard of either.)

Agreed, currently it takes quite a few steps to delete something. As a side effect of that, cases where our clients have deleted something "by accident" have decreased to near zero. I'd like to argue that it's actually a good thing and destructive things should never be too easy. Trashing pages isn't irreversible, that's true, but as it stands recovering content from trash isn't exactly trivial either (superusers only, unless you're using Trashman module). Another thing to note is that not all content is treated that way: users and templates, for an example, are instantly (and irreversibly) removed. Definitely not something you'd want to happen by mistake. From my point of view PW has good balance regarding this subject right now and it shouldn't be disrupted without careful consideration. If I was asked if something should be changed, personally I'd prefer restoring content not requiring superuser access, but then again, Trashman already handles that part. Still, if it was my choice, it should be baked into core system somehow. Same goes for pages, templates and fields; I feel that they should be recoverable too. Especially users, as I'm seeing more and more people adding extra data for them, thus making them less trivial to recreate. Just saying.. and sorry for taking this off-topic

@Soma: I'm having issues storing 000000 (i.e. black) as default value. Any idea if this is something specific to my case or actual issue? 000000 is converted to 0 (and in page edit nothing shows up), "000000" to "00000 and black to #black. In page edit this works just fine, but default value for some reason won't work. Actually at some point (not sure if this is consistent behavior, as I haven't yet had time to debug properly) 000000 was stored in database, but when fetched in field settings it was suddenly converted to 0. Could be even core bug, but since typical (page edit) text inputs have no problems with values like this, I'm not entirely sure where to start..

@Soma: I had planned to debug this a bit further before posting, but since you've already mentioned it: I've been seeing this same issue for couple of days now. Log entries are very similar to yours. So far I'm guessing that this is somehow related to ProcessWire issue #284, which has since been fixed. At least in my case, where pages just got suddenly unpublished and I'm running dev version just before this fix, this seems to be the culprit. Taking a look at field_publish_until for one particular page for which it should be empty, it looks like this: +----------+---------------------+ | pages_id | data | +----------+---------------------+ | 9224 | 1970-01-01 02:00:00 | +----------+---------------------+ Since SchedulePages first finds pages where publish_until>0 and then checks if publish_from <= current time, this particular page getting unpublished sounds logical This might only be applicable to dev branch, but I haven't tested this a site running older release yet. Soma, what version of PW are you running? If you're using dev, could you update it and see if the issue persists? Edit: Soma, I just realized that you mentioned the issue suddenly going away. Any chance that this was because you updated your PW at some point, applying aforementioned fix?