Jump to content

bmacnaughton

Members
  • Posts

    148
  • Joined

  • Last visited

Everything posted by bmacnaughton

  1. Do you have some example code that uses the API for templates and modules? I already have used the API to create users and pages (they both are created by my code in our site already). Or is there a place where creating templates is documented? It's not clear which properties must be set. For example, to create a page I do: $p = new Page(); $p->of(false); $p->template = 'template-name'; // the parent is unpublished, so "include=all" $p->parent = wire('pages')->get('path=/page-parent/, include=all'); // set fields $p->field_1 = $data['field_1']; ... $p->addStatus(Page::statusUnpublished); // make a unique name for the page - no one ever sees it $p->name = make_name(); $p->save() But I haven't seen the same thing done with templates. I also don't know what properties must be set, the syntax for creating field groups, etc. I'm hoping your migration scripts (or documentation) helps illuminate that. Ditto for modules. They are probably less of an issue - it's easy to get a list of each one and there are fewer changes there on average.
  2. Thank you again. It is possible to distinguish each - there is an end-user field I've added to the user template and all the production pages share specific templates. But that still results in IDs in production (if I add a page) that are different than the IDs that would be created in a development environment. My thought is to keep the production-users and production-pages in a separate table; that allows us to copy PW tables into a new DB without any conflicts. And it prevents us from forgetting changes done in the back-end admin tool. (Maybe I'm misunderstanding - it seems that migration files need to make the changes via API so we'd have to keep a good log of all changes made in order to create the migration files.) What do you recommend?
  3. Thanks. Let me ask a couple more questions. I have seen many approaches that create change-files of databases but all of those presume that production-time content is separated from framework content. It would be great if module/template/page adds, removes, and configurations were all captured. Would your module work if we have user-content in a production system? Does it apply changes to the target system? I've read the thread but it's not exactly clear to me what exactly it does. Is there an example to look at? Thanks. I think your observations on Migrator are correct. Nor does it keep page IDs (references) the same across DBs - the README indicates that the strategy is to rewrite them in the templates/*.php files but that seems a risky proposition (better not to embed them in the php files to begin with, but...) Agree and understand. Two points that (I think) mitigate this problem: 1) there are no client/editor changes for this particular site - we use it only ourselves because we don't have clients/editors and 2) the dump file only drops tables that PW "knows" about, so data in separate tables would not conflict in any way. It seems analogous to the way in which PW has `site/` and `wire/` directories. It can replace `wire/` without concern for issues with the site itself. I know we would have to copy current versions of templates and modules in addition to the DB but that seems to be relatively easy to script. I would appreciate your thoughts on the last quoted point in particular on whether my thinking makes sense and to what extent your module would address the issues.
  4. The situation I'm trying to arrive at a good solution for is how to store user-created data in a production environment. We're pre-production but the issue I'm running into is that storing user-data as pages creates problems when it comes time to update the production site with a new version (of our site, not PW). Because I'm adding data as pages the data will be deleted if I create a backup and restore it to the production environment. I've spent a fair amount of time writing some DB compare logic to find differences but that will require manual updating for each difference. Because pages reference other page numbers via IDs and the production environment will be creating users and meta-information pages it isn't possible to save/restore those particular pages around a backup (from development) and restore (to production) of the PW database. It seems like the most straightforward approach is to put the user-created data in separate tables so that PW information can be updated independently. That is pretty easy using $db or $database. Are there any best practices for this kind of thing? Am I thinking about it wrong? How is this problem generally solved? The user-data is 1) user accounts and 2) meta-information about uploaded files (stored in the file system).
  5. OK, my issue. The DB does have UTC time; I hadn't realized it was configured with SYSTEM time, so it's doing a conversion on output. I just need to configure MySQL appropriately. It would be nicer/easier to use if the timestamp was a Unix time value rather than a timestamp.
  6. Got it - thank you. I appreciate the fundamental knowledge.
  7. So PW (or maybe more generally PHP) starts with index.php, loads and executes that, and everything that causes to be loaded on every GET/POST? I'm just trying to get my head around what PHP/PW does when a page is fetched.
  8. I've moved the class declaration to ready.php as it depends on some specific page information. But I left function declarations in init.inc. It's not generally a problem, but is in one case - when I "throw new Wire404Exception()" it tries to redeclare the functions. Why does throwing that exception result in reloading init.inc? Shouldn't it just redirect to the 404 page?
  9. I'm sorry if this is dumb question, but I've been trying to find out what gets executed each time PHP serves a page. The specific scenario is that I'm implementing a LazyCron hook and can put it multiple places - an autoload module, init.inc, site/ready.php, etc. It has a fair amount of logic to load that I'd prefer not be in every page. The only way I can see to prevent that code from being loaded and interpreted (not necessarily executed) is to create a special page for it and use a cron job to kick it off only in that page's template. It seems like ALL autoload modules, init.inc, main.inc, site/ready.php, etc. get loaded and interpreted every page load (unless init.inc is disabled for that template, etc.) So 1. does everything get loaded and interpreted every page load or is caching of code done in some way (not just the file)? 2. is there a better way to avoid loading significant amounts of code than associating it with a specific page? Let me know if this isn't clear.
  10. Thanks; it's helpful anyway. I only had gc_probability, so maybe this will help.
  11. I'm looking at the session information in the database. The "ts" column shows my local time formatted as text. The code in the wire/core/sessions.php file shows a check against the normal PHP/Unix "time()" function, which is GMT/UTC time. Shouldn't the timestamp in the DB be GMT/UTC? And pardon the next question; I'm still trying to grasp the structure of PW. How/where does Session.php fetch the 'ts' column from the database? I was trying to track down the answer to my own questions but couldn't find where the 'ts' column gets used. Context - I'm writing a lazy cron job to delete files if the session they are associated with has expired. It seems like the sessions in the DB need to be cleaned up as well - if I explicitly logout the session is deleted. But there are leftover sessions from months ago in the DB, so it looks like old sessions that just don't come back don't get deleted because the expiration logic doesn't delete the session record when it determines the session timed out.
  12. OK, I found this https://processwire.com/talk/topic/17-functionsmethods-to-access-the-db/ and can figure it out from here.
  13. I need to write a lazy cron job that goes through a list of files and deletes those that are associated with expired sessions. Our session information is stored in the DB table sessions. Is there a Wire API call that allows me to do one of: 1) fetch all expired sessions? 2) hook the session expiration event? 3) fetch all active sessions? 4) do direct DB access to lookup sessions? (least preferred as I have to directly tie to session implmentation). My logic can either flow: Find active sessions delete files NOT in active sessions Get files if session_id associated with file NOT in sessions (or has expired) delete file.
  14. Thank you, again. I had been reading an old post that highlighted prepend/append. It's in the "How to structure your template files" tutorial. https://processwire.com/docs/tutorials/how-to-structure-your-template-files/page4. I don't believe I ever called $page->render() but did call $form->render() and $tree->render() (from MarkupSimpleNavigation).
  15. We use init.inc in our site implementation. There is a class that is used across all our pages, a global variable referring to the instantiated class, and a function that returns the global variable so it's available within other functions. Recently I've had issues with either the function or the class being redeclared. How can init.inc be included more than once? Can it be set to use require_once in some fashion?
  16. The username sanitizer (wire('sanitizer')->username("string")) is currently deprecated in favor of the using the pageName sanitizer because users are stored internally as pages. From a code readability standpoint it is more self-documenting to use a "username" sanitizer, not a "pageName" sanitizer. If, for whatever reason, the underlying implementation as pages changes there is no problem when using "username". If, for whatever reason, the allowable character set is different for usernames than page names there is no problem when using "username". The only benefit I can see that comes from removing the username sanitizer is the removal of a very small bit of code. Hence, my suggestion for keeping the username sanitizer and decoupling the API from the implementation.
  17. But given that, it sounds, for now, like PW must go through all pages in order to find those that are published.
  18. So is this dated information? In theory the DB could use the index values but apparently mysql doesn't: https://stackoverflo...se-where-clause. It specifically points out that mysql can't do bitmask operations on index values.
  19. Thanks - that makes sense to me. I was trying to understand BitPoet's comment though - if I interpret that correctly it's saying that PW itself would have to actually go through and look at the status of each page. That doesn't make sense to me - published must be an indexed column. My original post was pointing out that there is a published column in the mysql "pages" table and that it looked like that could be used to efficiently filter out unpublished pages (or to find them) but that the same was not true for hidden. Is my understanding correct?
  20. Thank you. It looks like PW has copied the file to a new name. It doesn't rename the existing file, so everything should work fine. I appreciate everyone's help with the multiple problems.
  21. Thank you. This is helpful; I hadn't realized that an image field was potentially multiple images. And now I get file names. But not the original file name I supplied. My filename was: '/serverroot/walls/tvxjmr8/png/2016-03-22-020945.eddi.png' And the output I now get has the first dot (between 020945 and eddi) replaced with an underscore. Is there some way to get back my original filename? Does it matter?
  22. $p->wd_shared_image is an image field, not an images field, so it should only hold one image, right? $p->wd_shared_image is returning a Pageimages object with count($image) === 1. But if I try $image = $image.eq(0); I get "Call to undefined function eq()".
  23. Thanks for the additional information. So you're saying that if I have 1 million pages that PW must go through them all one-by-one (as a result of mysql not using the index value in bitwise operations) in order to find which pages are published?
  24. I am not able to get the original file path from an image. I create a page (primary purpose is to hold images created by users) via code similar to this: $p = new Page(); $p->of(false); $p->template = 'wall-design-page'; $p->parent = wire('pages')->get('path=/wall-files/, include=all'); // various application specific field settings $p->addStatus(Page::statusUnpublished); $p->save(); // hardcoded for this example but dynamically generated $filepath = '/serverroot/walls/tvxjmr8/png/2016-03-22-020945.eddi.png'; $p->wd_shared_image = $filepath; $p->save(); Later I fetch these pages: $wallpages = wire('pages')->find("template=wall-design-page, include=all"); And add them to an images field on the page and output information (for debugging): foreach ($wallpages as $p) { $image = $p->wd_shared_image; $page->images->add($image); // debugging output $wall .= $p->wd_shared_image . ', ' . $image->url . ', ' . $image->path . ', ' . $image->filename . '<br/>'; } That results in the following output: 2016-03-22-020945_eddi.png, /site/assets/files/1616/, /serverroot/dist/site/assets/files/1616/, The filename is missing after the last comma. Neither the URL nor the path include the filename. What happened to it?
  25. It also looks like the published column in the pages table gets filled in with an indexed timestamp when it is published - so that allows a query to exclude unpublished pages efficiently (by selecting "and published != null". But hidden pages have to be retrieved and checked for hidden. In theory the DB could use the index values but apparently mysql doesn't: https://stackoverflow.com/questions/5352263/optimize-mysql-query-to-use-index-on-a-bitwise-where-clause.
×
×
  • Create New...