teppo

If there really is a reason for this, I would seriously question it's sensibility. This should really be changed in the core. Care to create a pull request or feature suggestion at GitHub? Edit: I've just moved this topic to the Wishlist & Roadmap section of the forum. The Modules area is mainly intended for module release / support threads, and while this question is technically related to a module, it's a core module with no support board of it's own.

Should probably be noted that this depends a bit on whether you want to disable their entire account after the subscription is over (in which case you should follow Adrian's suggestion or take a closer look at Login Scheduler) or if you actually prefer to keep the account usable and only deny access to specific pages. In other words, is the subscription an "all-or-nothing thing" or can one user subscribe to different types of content? One solution to the latter need would be storing pairs of users + subscription lengths in a Repeater field attached to the page they are subscribed to. Instead of Repeater you could use a PageTable field – or Table, if you don't mind the commercial aspect of ProFields – and instead of the subscription target you could store said data on the user account. There are many solutions, and the best one depends on your specific needs

Hi there, I'm not entirely sure what it is that you're looking for, but if your problems really start as soon as you step into the world of object-oriented programming, I would suggest grabbing a copy of Programming PHP (most likely available from your local library) and seeing where that takes you. If you want to really understand how ProcessWire internals work, it's important to understand how object-oriented programming works, and also how PHP works Other "general programming resources" you might find useful are the Codecademy PHP course, which is a pretty good introduction to many basic PHP features, and of course PHP: The Right Way, which is more a collection of best-practices, but contains a lot of valuable information nevertheless. Others can and will no doubt chime in and suggest tutorials, articles, etc. strictly related to ProcessWire, but in my opinion you should first make sure that you get the foundations right.

Cough. We used to get a lot of spam with certain movie names on the forum. That's a feature.. kind of

Oh, but there is: It's not just for internal links, though you could probably configure it for that.

Welcome to the forum and ProcessWire! If you're trying to ask if you can replace your custom CMS with ProcessWire, well.. the answer depends a lot on what kind of features you're looking for. In most cases I'd say "yes", but it may require some changes in your development process. Every CMS has it's own way of doing things, and once you get used to the way ProcessWire works, it can indeed be extremely flexible and powerful. If you're just getting to know ProcessWire, I'd suggest visiting our docs section: tutorials are always a good place to start, but if you've already got a project you'd like to use ProcessWire for, you may find the cheatsheet and API reference more useful To answer your question: no, ProcessWire is not based on CodeIgniter. ProcessWire is a CMS and a CMF, meaning that in a it's really a framework itself. Edit: Right, @Ivan Gretsky beat me to it, and looks like I misunderstood the bit about custom CMS If the question was whether you should start building your own CMS or choose an existing one like ProcessWire, then the answer is that you should definitely go with ProcessWire. Building your own system may feel tempting, but it's a massive amount of work, and you'll more than likely run into both technical and security issues sooner or later.

Very good point, and the timing couldn't be better. Just changed a link in my previous post..

Regarding the diff tool: I've also been using diff-match-patch for automatic diffs. It's a solid library and particularly useful if you prefer to generate diffs on the fly (client side). The kind of issues you mentioned above, i.e. the library comparing column names in addition to values, may be difficult to avoid with any tool that isn't "JSON-aware". This is why, for an example, in VersionControl I ended up mocking up my own diff logic for page field comparisons. What I'm trying to say here is that simply diffing two strings may not always yield sensible results, as you have noted here too. In this case it would make more sense to iterate items one by one and generating a separate diff for each pair of old and new values. Hopefully I'm making sense here.. and sorry if I'm mixing things up and this is what you're already doing, I didn't read your code that thoroughly

Sorry for the delay -- meant to answer a while ago, but then something came up, and I forgot the whole thing. Hopefully you haven't been waiting this whole time I'm going to answer your suggestion at the Changelog support thread separately, but as a quick comment to this: I think your module looks really neat, and while listing changes to fields is definitely something I might consider for Changelog, I do also feel that these modules serve a different purpose. At least that's my first impression. When I first built the Changelog module, it was just a simple list of changes to public pages of the site. While it does display which fields were changed and now also includes system pages, I've intentionally left actual field values out of the equation. That's where VersionControl comes in: it stores field values and keeps track of changes to those. Again, the purpose is different: a relatively high-level log of changes vs. an actual versioning tool. Tracking changes to fields might fit VersionControl better than Changelog, but I'm currently not convinced that it would really be worth it. It seems to me that while there may be some common ground, these are mostly separate features. And, to be honest, VersionControl is already doing so much behind the scenes that I'm having hard time keeping up with everything that's happening. Smaller, more targeted modules do have certain benefits I'm definitely going to keep an eye out for what you do with this module, but for the time being I don't think there's much benefit in trying to combine them. --- By the way, I've been meaning to ask you about the naming of your module: what does the SVN part actually refer to? My first guess would be Subversion (SVN), but then again, I don't see any link between Subversion and your module. Hopefully I'm not being too intrusive here, but if my guess is right, I'd suggest reconsidering the naming. While Subversion is a commonly used product, in the long run this might become a bit confusing to some users

I would suggest contacting Marvin via http://www.conclurer.com/.

Another alternative would be using what you (probably) already have: it's more than likely that you've got logging enabled for Apache, and the Apache log file will no doubt include the URL of each viewed page. See where I'm going with this? The benefit of this approach would be that you reap all the benefits of ProCache: the bulk of the requests are served static files, and PHP or MySQL (or Redis or whatever) won't need to be triggered at all. The obvious downside is that parsing the logs requires a bit more work than simply fetching the data from a table.

Looks like I have made the following patch locally: - if ($page->isChanged('status') && $page->is(Page::statusUnpublished) && $page->publish_from) { + if (!$page->isNew() && $page->isChanged('status') && $page->is(Page::statusUnpublished) && $page->publish_from) { Possibly related

This appears to be an error in the translation: https://github.com/underk/pw_french/blob/9f8da2b0dff6df62f13410486a9244af5deaf71c/wire--modules--process--processmodule--processmodule-module.json#L99. There's a more up-to-date French translation available from here: http://modules.processwire.com/modules/french-language-pack/.

So, this is kind of a heads-up: I've just pushed version 1.3.2 of ProcessChangelog to GitHub, and this version includes a bunch of UI changes. Hopefully they make as much sense to you folks as they do for me. To be honest the old look of the module was a bit too ProcessWire 2.0'ish, and I've also been meaning to add clickable action/template links etc. for a while now.

Something to consider: if Redactor can be bundled and distributed with open source software, why not use it as a basis for a third party inputfield module instead? InputfieldCKEditor itself started out as a separately distributed module, and considering the way ProcessWire works, this doesn't really need to be part of the core package. While Redactor seems like a decent editor, personally I would be against bundling a closed source application with an unclear license into ProcessWire. Judging from various posts out there, no one is entirely sure how the license works (not even the Craft people), and to me that is a huge red flag.

This topic has just been moved to Module/Plugin Development subforum. Please post any questions about module development here, the main Modules/Plugins area is mainly dedicated to module support threads. Thanks!

If possible, before uploading an image open your browsers dev tools and check out the Network panel (or something similar) in there. When the upload starts, you should see an AJAX request. Still in the dev tools check what the response part of that request looks like. If you see an error message there, that's the culprit (and the error message will likely tell us what exactly went wrong).

Hi @pleini, just wanted to let you know that I'm moving this topic to the General Support area of the forum, as it doesn't seem to be related to any specific module per se. Thanks!

Hi @andy-jfd. Just wanted to mention for future reference that you should post ProCache-related questions to the ProCache VIP support area. If you don't have access there but have bought ProCache, please let Ryan know and I'm sure he'll be happy to add you. Thanks!

Moved this topic to the General Support area, as it's not strictly speaking related to a separate module but rather something bundled with the core.

Hi @benbyf, just wanted to let you know that I'm moving this topic to the Module/Plugin Development subforum. If I'm mistaken and this is indeed a module support thread, we can always move it back. Thanks!

Moved this topic the Module/Plugin Development subforum. Module development questions belong here.

Perhaps we're talking about different things here, but isn't the API key for Google Maps included when loading the maps library -- i.e. it has to be visible in the HTML source as-is?

Definition lists have been a "confirmed new feature" for 9 years now. I wouldn't hold my breath Anyway, just wanted to stress that if you need definition lists, those alternative approaches provided by @Macrura above are worth considering.

Agreed. With Options field I'd suggest adding extra 10 years or so right from the start.. and if the site is still running after a decade, you can step in and add +10 years, etc.