teppo

That's quite strange. Running this through decoder suggests that this include is trying to load file from /wire/modules/System/.db9f7664.ico. Is this a path that exists on your site, and if so, what's in that file? /wire/modules/System/ is a path where SystemUpdater and SystemNotifications live, but I'm not aware of anything that should create a file like that. Combined with files suddenly being removed and this file getting modified, it doesn't sound good. The first thing to do would be to check the server, i.e. is it possible that someone has gained illegitimate access to it. Is this a shared host, a VPS, or something else entirely? Were both sites on the same host? I'm not aware of any security issues with ProcessWire itself, but ProcessWire isn't immune to problems caused by someone gaining access to the server, directly or through another application (such as a WordPress installation – which has actually happened before).

At least to some degree related, no doubt! The reason I'm asking about ways to bundle dependencies into site profiles is that I was originally a bit conflicted about how to move forward with a project I'm currently working on. Based on the description in that thread there are definitely certain similarities with my project and what Jonathan is working on, but I'm not yet quite sure if there's any real common ground (except, perhaps, the target group) ? Either way it'd definitely be interesting to hear more about Jonathan's project – and perhaps share/borrow some ideas as well ?

Thanks Benjamin! What you're saying makes sense, and I've also come to terms with the fact that the contents of the site profile itself (mainly what's within the templates directory) won't be easily updated. They are, after all, intended to be modified, and as such "updating" them doesn't make a whole lot of sense. I do also agree that we're in a bit of a strange place right now: on one hand there are native (to ProcessWire) ways to handle things like dependencies, but on the other hand we've also got certain level of built-in support for Composer. That's not necessarily a bad thing, though: just for an example, folks have been doing stuff like installing modules from within the Admin for quite some time now, while I still haven't enabled that on any of the sites I've built – and won't, unless it's for a site that someone else is going to manage. First of all I prefer not to give the site easy write access to executable code (security), and second of all I've had some trouble making that work with my version control and deployment practices. (There are other reasons too, but those have always been my "top two".) The way I see it, the tools and practices I prefer are quite likely not what the "mainstream user" prefers – and I'm OK with that. Same goes for the dependency management: in my case I'm thinking that whatever solution is used should be reliable, easy (comparatively: running a few commands from command-line is easy), automatable, and compatible with different workflows (including things like CI/CD tools). The fact that ProcessWire caters for these tools just as it does for the built-in alternatives is a strength in my books. Anyway, I guess this once again boils down to the rather well established point that there's more than one way to do it ? -- Sidenote: to my best knowledge GitHub download feature actually doesn't include submodules, so the only way to have everything as an easily downloaded package is to bundle it all together. This is part of the reason why I don't (currently) think that submodules are worth the hassle.

Exactly. And just to clarify: $page->field_name returns a value stored in the field, not a field object, so that's why you can't check the type of the field that way ?

Thanks @horst and @Robin S for the input! Those are some valuable insights right there. I do have to agree that #1 would be beneficial for the widest possible audience. As you pointed out, Robin, this is likely still the best approach for most site profiles out there, simply because it's the only solution that works right out of the box. Anything else would require either the use of somewhat developer-oriented tools (such as Git or Composer) or a totally different approach (ProcessWire Kickstart) – and as such would be a potential turn-off for some users. This is just me thinking out loud, but if site profiles were able to provide a list of dependencies that ProcessWire could then satisfy (or tell the user to handle manually if it couldn't), that could be nice. Or perhaps ProcessWire should provide some sort of built-in support for "recipes"... ? Anyway, in my case the site profile I'm working on is going to be rather developer-oriented, so if Composer is enough to scare someone away – well, that's probably for the best. Basically what Horst said above: it depends on the target group, and in this case my target group are developers, so going with a set of tools that are anyway considered essential in the business isn't necessarily a bad thing. I could also go with Kickstarter, but since I'm trying to reach for the "serious developer" territory here, I think using industry-wide best practices is actually going to be a benefit in itself ? (And yes, I'm currently leaning towards Composer approach. Though please let me know if you have better ideas – I'm all ears!)

So, I've been working on a site profile and came across something I'd like to get some input on. Like probably many other site profiles out there, this one also depends on (and thus includes) third party modules. What I'm wondering is: what would be the best way to include them with the site profile? I can think of three possible / feasible approaches: Bundle the modules into the site profile as-is, i.e. include the full module directories. Benefits: just install the site profile and the module is instantly available. No other dependencies and doesn't require any knowledge beyond "how to install a site profile". Drawbacks: updating the module requires updating the files manually, or updating via Admin (which may not be permitted, and may not be a suitable option in case the whole site is stored in a version control system). Unless the site profile is manually updated from time to time, it may initially contain very old module versions when installed. Add module repositories as Git submodules. Benefits: modules are easy to install and update with Git, just run "git submodule init" followed by "git submodule update". Drawbacks: Git and some basic understanding of its command-line use is required, and simply installing the site profile itself isn't enough to get it up and running. Add modules as Composer dependencies. Benefits: same as with the submodule approach, but perhaps a bit more flexible – possible to define minimum versions, minimum stability, etc. Also: this would be familiar approach for many PHP devs, while something like Git submodules seem to be less commonly used. Drawbacks: obviously requires Composer and command-line access, plus a basic understanding of what Composer is and how it works. Module directories won't contain .git folder, so can't be updated with Git commands (not sure if this is a real drawback, though). What would you prefer, or which approach do you currently use? Any other ideas? I'm kind of leaning towards the Composer method, mainly because I'll likely have other Composer dependencies as well, so it would actually require fewer steps than including modules as Git submodules. Still the submodule approach does have certain benefits, like easier updates (sort of, at least) ? -- Note: since there's no separate forum section for site profiles, and technically this may apply to literal modules as well, I'm posting this the Module/Plugin Development area. If any of the moderators disagrees, I'm happy to move the thread to another area instead ?

Moderator note: I'm moving this thread to the General Support area of the forum. Modules/Plugins area is only intended for dedicated support threads of existing third party modules, yet this is a general question related to a core feature ?

I believe I've just answered this question in your other thread, but please let us know if I'm wrong and this is actually unrelated. Also: I'm moving this thread to the "Module/Plugin Development" area of the forum ?

You'd definitely have to store the data somewhere. Forms API itself provides the form only, it doesn't save anything yet. Depending on your needs you have a number of options: Saving the data as config for your module. ProcessWire allows you to save config data for any given module with $modules->saveConfig(), and then retrieve it with $modules->getConfig(). This is a really simple approach, and likely what you'd want here. If you're using the latest development version of ProcessWire, there's now a brand new $page->meta() method that you can use to store any data to a specific page. In my opinion would be a great use case for that method, but again: it's only available for the very latest development version of ProcessWire (3.0.133). Saving your data in a custom database table (using $database API variable). This requires you (among other things) to create a custom database table, and if possible, I'd suggest avoiding it – usually it's better to use the API to store data as ProcessWire values. That being said, if you look at the ProcessChangelogHooks install() method, you can see an example of how to create a custom database table automatically when a module is installed. There are other ways as well, but these are the ones I think fit your needs best ? -- Just for the record, I'm moving this thread to the "Module/Plugin Development" section of the forum. The "Modules/Plugins" section is intended for dedicated support threads for existing (published) modules only, and any development-related questions should be posted to the development subforum instead.

I've just notified Ryan about the removal, thanks for letting us know!

Glad to hear that it's working ? Process modules make execute*() methods available as individual URLs. If you want everything on one page, you can either put it all within the default execute() method, OR you can split your code into multiple methods and use them within the execute() method to render the final output (just don't name them with the execute-prefix, if you don't want them to be accessible in their own URLs.) It's a bit complicated so perhaps not the best example for a beginner, but if you take a look at the ProcessChangelog module execute() method, you'll see a number of render-prefixed method calls. That's not an "official Process module thing", but rather my own convention – it's simply one approach to split otherwise unbearably long execute method into smaller, more manageable pieces ?

So, I saved your code at /site/modules/CustomAdminPage.module, installed the module, and opened /processwire/customadminketan/table/ on my site.. and it works just fine ? Are you sure that if you install the code above as a module, it definitely doesn't work for you? In that case it looks like we might need some additional info. First of all, which version of ProcessWire are you using, and what kind of a setup do you have (Apache or something else, Windows or Linux, are you developing locally or an a server, etc.) Does everything else in the admin seem to work as expected?

Hey @buster808, First you should make sure that your module class extends Process, and double check the URL you're trying to open (should probably be something like /processwire/your-module/table/). I can't really see anything wrong with the code you've pasted here. If you could provide us with a proper test case (complete module code), it would be easier to see if there's something else missing. It's OK to strip any unnecessary parts away, but it should be a version of the module that a) is complete and thus should work, but b) doesn't work when you install it and try to use it ?

Repeater items should be stored in a RepeaterPageArray, which in turn extends PageArray, so this does indeed sound strange. Would need to peek into some code to say anything more, and I'm not entirely sure what "the render method" exactly means here ?

What I meant was that it doesn't accept null value, as can be seen from your screenshot. Changing it to allow null might indeed be a valid temporary fix, though that could leave some sort of underlying issue open ?

Have you updated ProcessWire, Image Extra module, or your database software recently? This error looks like it's coming from a custom database column added by the Image Extra module, so I would recommend opening an issue on its GitHub repository (https://github.com/justb3a/processwire-imageextra), or alternatively posting a question to the Image Extra support thread. The "Credits" database column is set to require a value, and there's no default value for it; it could be just that you can't provide a value when uploading the image, which in turn results in the issue you're seeing here. I'm really not sure why this would've worked for you before, but the module was last updated a month ago, and that update included some changes to Exception handling. In theory that could be causing the error you see here, though it does seem like a kind of a long shot.

Hi there. It's hard to provide specific instructions without knowing a bit more about your site – for an example whether you've installed a publicly available site profile or developed a custom one yourself – but you can check the page number in a template file and only show the header if the user is currently viewing page 1: <?php if ($input->pageNum == 1): ?> <!-- your header goes here --> <?php endif; ?> More details here.

@Tyssen, it looks like the original examples had a small mistake – either that, or I'm missing something as well. You should either store $twig_env in $config in your _init.php file, or (more likely) call it directly with $twig_env in _main.php ?

It sounds like you may be confusing pages and tabs: the settings tab (included on each page) doesn't have a template of its own. None of the tabs do -- only pages have (or, more specifically, use) templates. This thread has ideas on how to hide the settings tab with code, and if you enable the advanced mode via site/config.php, you should find settings for hiding the tab and moving name to the Content tab. More details here:

This isn't something that I personally do, but basically it boils down to a couple of strategies: 1. Use some sort of mechanism for validating number of installations. It can be a license key or something else, but basically you'd have to add code that connects to your server to validate the installation. 2. Explain to the client what they are allowed to do and trust that they follow these instructions. Provide a contract or license and make sure that you can prove they've agreed on it, in case you want to take an action based on it later. Personally I would choose method 2. First of all it's a lot less hassle for you (method 1 is basically only worth it if you intend to sell your product to a relatively big number of clients), and second of all whatever protection you add will be easy to override or remove. ... not to mention that if your code sends data to you, you could potentially get into some trouble for that if it isn't communicated *very* clearly ?

Whoa, just got bit by this as well. Couple of my sites (on an Ubuntu server) were using SessionHandlerDB, so this happened: > select count(*) from sessions; +----------+ | count(*) | +----------+ | 1561416 | +----------+ 1.5 million rows in the sessions table – "whoops". Should probably add sensible session.gc_probability number for these sites ?

Short answer: ProcessWire differs from many other systems in that it doesn't really generate any markup, and as such there are not that many easy ways to tell that a site is running ProcessWire. This is intentional. Letting everyone know what system you're running is usually fine (and it's a nice hat tip towards that system), but potentially you might also be tipping malicious visitors off on how to best attack your site. With ProcessWire it's easy to go into "stealth mode", so that potential attackers have absolutely no idea what system they're currently targeting. As for builtwith.com, my initial guess would be that their algorithm primarily looks for the "generator" meta tag (or similar headers), or the text "Powered by ProcessWire". At least those seemed to be present on all the sites listed on their site under ProcessWire that I quickly browsed through. They may be looking for other indicators as well, but anything more than that can get a bit tedious. The site mentioned above, isit.pw, gathers a number of clues and then estimates the likelihood of a site being powered by ProcessWire. A lot of times (probably most) it gets its estimate right, but then again it is relatively easy to fool ?

... except if you're already checking with class_exists(), in which case it's just a tiny but unnecessary overhead ?

Your method seems fine to me. Something like Composer would be another option, but then you'd have to explain to your module's intended users how to use it, and expect them to have it installed, before they can get started with your module. Depending on the use case that may or may not be worth the hassle. In RedBeanPHP I've bundled the RedBean ORM into a module, and pretty much the only difference is that I'm loading the file and instantiating the class in the init() method – but even then I'm mainly doing it that way because I wanted to provide a config setting for selecting which version of the library to include.

With ProcessWire you don't generally want to perform your own SQL queries. It's possible, but generally I'd consider that a bad practice. If your content is stored as ProcessWire objects (basically Pages), you should always use the Selector engine for that sort of stuff. Not only does this provide the benefits of a great API (such as $pages->find('template=mailbox, owner=[some_user_field=whatever_value]') or $pages->get('parent=some-parent, name=page-name')->setAndSave('field', 'value')), there's also zero chance of accidentally running into nasty SQL injection vulnerabilities. Of course you can always create custom database tables and perform queries on them using the $database API variable (which is essentially a wrapper for PHP's own PDO class), but in such cases the content won't be editable within ProcessWire's admin, so you're missing a pretty important benefit there. Another alternative would be using RockFinder, which kind of provides the best of both worlds: easy to use syntax for queries combined with the performance of raw SQL and lightweight PHP arrays/objects. So, long story short: if you want a nice GUI and an easy-to-use API for managing your content, ProcessWire is a great choice. If you ultimately just want to use your custom database tables, write a few SQL clauses to update a few rows here and there, and there's no need for a web based interface for managing said items – then perhaps you should just build it from scratch (or use something like Laravel instead).