KT Walrus

Seems to me this would be easy to implement. Just do some AJAX to set the topic markers as if you actually read the topic.... If this is too difficult, you would probably do it in JS by just putting the topic link in a hidden iframe so the topic would actually be viewed (from the board point of view), but the text was never shown. This has a negative side effect of incrementing the view counts and could take longer to process than just marking the topic as read from an AJAX call. Maybe this is more complicated than it appears to be...

I'm a sucker for consistent user interfaces. Just noticed that the forum markers turn off when you click on them and mark the entire forum "as read". But, the topic markers (shown when viewing a forum) do not have a similar toggle. You must actually read the topic to mark the entire topic "as read". Seems like a UI oversight to me.

Maybe the real enhancement here should be that the section that displays a topic should be replaceable with a mod (that doesn't require source edits). Same for the code that displays the list of topics in a forum. If this feature would be implemented, then modders might produce some innovative viewers for IPB (including AJAX based viewers).

I'd like to be able to choose to attach to a new post an attachment I had made to a previous post (rather than having to re-upload the attachment). This would be useful if I wanted to attach a bunch of photos in a "gallery post" and then include one of the photos in a blog post just by using the attachment BBcode. I suggest you would have an "attach previously uploaded files" section in the post form that when clicked on pops up (or opens a hidden div) that shows a list of the previously uploaded attachments by the user ordered by most recent first and paginated with an "Add to Post" link next to each attachment in the list. This "Add to Post" link would simply paste the bbcode into the post. Then, the bbcode parser would process the attachment by looking up it's id and verifying that the id belonged to an attachment made by the same user and would display the attachment just like it would one directly attached to the post. This is a small enhancement, but it would encourage users to upload more attachments into a single "library" post and then show them off in their various posts where they can give the attachment a better context.

I'm looking for a bit more detail then this. Short descriptions about the column are not all that helpful. I want the where, what, when, and why the column exists. The information should be at least a small paragraph and might be an entire page. You really can't understand an application unless you understand the data it stores and how it operates on that data.

I like how you documented Error Codes in the Customer Resources section. Could you add similar documentation for all DB tables and columns? It would really help if there was a quick reference where I could look up a table or column in the database and see a description of what purpose the element serves, when, where, and why it is created, read, updated, and destroyed. With code like IP.Board, such schema documentation would go a long way to explaining exactly how the DB is used and help us in writing mods that do the write thing, especially if you include the methods that are public that affect the table or columns. Similarly, it would be nice to document all public methods that could be called by new code in a similar fashion. But, the DB schema documentation is the most needed. A few of the columns seem to have names that don't really fit their current usage (I suspect this is because they started out life as something else, but then as the software has evolved, their function changed but you were reluctant to rename the actual column for easy upgrades).

One more thing... If the code inside the <php> were put in a function that was called in the position of the <php>, we could use the return statement to return HTML to be embedded inline. This would be much more convenient as we could use switch statement to choose a number of different HTML strings based on some variable. This is often much cleaner than doing cascading <if>s and much more flexible. Maybe you didn't do this because you were concerned about <php> inserting malicious unsecure HTML onto the page?

I discovered this before you posted when I tried to implement an indent var surrounding a recursive parse template call. I tried incrementing the variable before the call and decrementing it after the call, but the cached skin just put the increment and decrement at the top of the function resulting in no change. It would be nice if php were evaluated in place (in an out of line function just like the foreach generates) so it would be more intuitive. I ended up adding an indent var as a parameter to the recursive function and just incrementing the indent var on the call. A better solution in this case. Why isn't <php> implemented like the <foreach> out of line functions? BTW, I was using a global in my <php> (e.g., $this->settings['my_indent']) so the scoping problems of local variables isn't affected by the out of line functions.

Thanks for that. I was thinking the id was a condition variable that could be later tested by another if statement and not have to repeat the same expression again. Boy was I wrong. I didn't even think about hooks. What are the other extra statements like <if and <foreach? Is there <while and <switch and other php control statements?

After searching the source files, I found the briefest documentation possible in the file in "admin/sources/template_plugins": {parse addtohead="{$this->settings[\'public_dir\']}js/myJS.js" type="javascript"}{parse date="now" format="long" relative="false"}{parse expression="intval($data)"}{parse format_number="123456"}{parse include="/path/to/file"}{parse js_module="name_of_module"}{parse replacement="a_post"}{parse striping="someKey" classes="row1, row2"}{parse template="myTemplate" group="global" params="$data, $moreData"}{parse url="this=that" base="public"}{parse variable="testKey" default="foo" oncondition="$data == \'new\'" value="bar"}At least I now know what can go between those braces although I could use some words as to exactly what each plugin actually does. Like, if I addtohead, where does the javascript go? Does it go above the other javascript or after? I have coded some jQuery scripts that need to go before Prototype or they won't work in IE (some sort of weird conflict). Anyway, now, I need to find a list of the extra tags like "<if" "<foreach" etc that are allowed and maybe some more documentation than one line examples. Finding documentation is a very frustrating task.

I've searched around and haven't found any help on editing skin templates. If I've missed it, please give the link. Otherwise, please make documenting skin templates a priority. I don't quite understand what all the possible control tags do or what the allowed syntax is for them. I've been making my edits by just following the existing templates. For example, I'm not quite sure what the (possibly optional?) arguments to the "<if test=" where there seems to be an optional id followed by a ':|:' followed by what appears to be a php expression. What is the significance of the optional id? I'm assuming it might hold the value of the test so it can be used later in the template, but what is the expression to test this id later (if that is the case). I also see things like "parse" that need to be inside braces. What are all these possible outside HTML commands that can be given in between the braces? I'm pretty sure this has to be documented somewhere, but you have made it very hard to find. When I enabled the Page Help, all I got was a "NEW:core_templates___ There was no page found." so that didn't help much.

I decided to risk posting my request to the Modification Requests forum here. If this was inappropriate for that forum, an IPS moderator should delete this post. I would still like to see advertisements by individual coders looking for work rather than posting to a forum in hopes that the best coders see it.

I posted this as more of a suggestion than anything else. I don't want my mods to be publicly available in any way, thus I'm looking to pay someone to code them for me. I just thought this would be an area that IPS would want to encourage as helping 3rd party coders make a living at modding IPS products can only help IPS success in the long term. I would request a quote from IPS if I thought I could get their main developers to code for me at a reasonable rate, but I'm sure it is more valuable to have their experienced coders work on code that helps more than one person and their personal board.

I'd like to find someone good to code some custom mods for me. I don't really know where to start this search. Maybe PM some coders that have done good mods to see if they are available for custom mods. So, I think it would be a good idea to have a "Looking to hire?" forum or a section in the new Customer Resources section that allows coders and buyers to post "work wanted ads". If there is already such a section or a website where IPB coders all hang out and I can post such a request, please post a link here.

I wouldn't run with anything that breaks validation. It just shows that the developer wasn't very careful in coding the mod. Making ids unique is an absolute requirement for me as there is more and more JS executing on these pages and the distinction between IDs and CLASSes really needs to be observed. It doesn't take but a minute to suffix a '2' (or other unique suffix) onto the duplicate ids to make them unique and to add styling for that id if the original id has CSS styling.

BTW, there is a link to go to the forum containing the topic at the bottom of the page in the Previous/Next links. This is probably enough for most people and these people don't really need the full breadcrumbs repeated at the bottom.

You will need to make the ids unique on the page and update the CSS for those ids if you want valid HTML on your pages.

Maybe IPS could write a Wiki app (or forums module) and let us users and IPS staff write the documentation online here. Wikis are much better than having an articles forum as everyone can edit the content.

I've had to change a few lang bits in the ACP lately, and the process isn't as easy as it should be. First, the strings aren't sorted by key when viewing a word pack. And, the Find box is not available on the search results page to narrow your search or to start a new search. And, the search doesn't search key values either (only the Text). And, finally, it would really help to enable Live Search on this search box so can quickly zoom in on the bits I want to see/change. I spent a few extra minutes to find the string I was looking for (because the Text was only a common word and the results were over 8 pages shown in an order that didn't help much - since I didn't know what word pack the one I was looking for was in).

Then, just add the "ini_set('memory_limit', '128M');" in the initdata.php file. I haven't tried this, but it should work. I'm not sure why IPB doesn't just put that call in IPB and have an Admin CP setting to specify the value. Especially, if this topic is generating a lot of support issues for people who don't know how to change PHP settings. Also, the Admin CP should have a max_execution_time setting although the default seems fine for most people. Apparently, the default for memory_limit is not high enough on some installations for IPB to work nicely. I see no reason to get your host to up this limit globally if it can be done locally.

Yes. The PHP memory limit is a "soft" limit in that PHP only checks when requesting more memory at runtime if it has reached the limit. It is the same as for the other limits like post max size, upload max size, or cpu limit. Setting these limits high have no effect on execution unless the script actually needs the extra memory. For a well written script like IPB, you are only going to be affected by a high limit if the script really needs the memory for some operation and then it only hurts if lots of people simultaneously use lots of memory. If it was a real "hard" limit that upping it would really cripple a system, they wouldn't allow you to change it locally or in your PHP script. It takes no privileges to up a memory limit.

Maybe this is old information. I got this idea by reading this article: http://carsonified.com/blog/features/webapps/serving-javascript-fast/

I think the current approach to having lots of individual JS and CSS files on a page with some loaded by the minify script isn't quite as efficient as it should be. I suggest that you spend a little development time to implement a better solution. Since browsers are required to never cache a file that uses a query string, make all JS and CSS files use FURLs (e.g., /javascript/ips.attach.js) as an option to loading the files through index.php.Don't combine any individual files into one URL. Load them in the script individually with maximum "forever" caching headers.Include a version number/last modified timestamp for a JS or CSS file in the FURL (e.g., ips.attach.v93802339.js). Don't change the underlying file name on disk. Since index.php (or another script that doesn't log in) is used to serve the files, the script will simply return the file with the version timestamp stripped out. The timestamps can be cached but recached on demand or whenever changed through the ACP.Keep a minified cache on disk of all files so the file is minified once (unless its timestamp changes and then the minified cache should be invalidated).Since all JS and CSS would be served as FURLs with forever caching headers and the filenames are timestamped, this should result in most all browsers caching the files and only requesting a file to load only once. The key is the FURLs need to look static and not dynamic to the browser. By using the timestamps, the browser will download any changed files when the timestamp it sees in the FURL is changed, but otherwise will use the browser cache. Minifying isn't very important with this approach except for the first time the files are downloaded to the browser, but since you already use a dynamic script to minify some of the files (but not all), you may as well have this as an option when you minify. And, minifying provides a little obfuscation. I believe that one of the reasons that IPB3 feels slower than IPB2 for some is that the pages have lots of JS and CSS files that are loaded individually and some by using a query string (which some browser implement the standard of never caching files that use query strings - some browsers ignore the standard and cache anyway).

I implemented a quick bbcode for showing pretty fractions, using this php code: { return preg_replace( "/\s*(\d+)\s*\/\s*(\d+)\s*/i", "<span style='font-size:80%'>^\\1& #8260;_\\2</span>", $content ); } private function _buildOutput( $content ) For [fraction]3/11[/fraction] it shows as: 3⁄11 (only the fraction height is reduced by 80% so that it looks normal) This works, but I haven't been able to figure out how to get the RTE to show the formatted fraction instead of the BBCode. What I really want is to implement a drop down menu that allows the user to just pick a formatted fraction from the drop down. Maybe all fraction up to 16th such as: 1⁄2 1⁄3 2⁄3 1⁄4 2⁄4 3⁄4 1⁄5 2⁄5 3⁄5 4⁄5 So, I've gotten half of what I want, but it occurred to me that IPS could implement this much better. I'd like to see a new dropdown in the editor to allow you to insert a fraction (from the list) and have this fraction appear formatted in the RTE editor.

I would think you could get someone to mod your board to revert this behavior back to the IPB 2 implementation. Apparently, all that is needed is to exclude some forums when computing that information. I haven't looked at it, but it might be just some extra bits in a where clause somewhere.