Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1426 [In-Portal CMS] Admin Interfaces feature request N/A 2012-11-05 09:45 2013-01-18 14:35
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs feedback Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/fnMTQh7JuGw/discussion
Change Log Message: Adds tags functionality to all units
Estimate Points: 2
Summary: Tags functionality
Description: Tags are useful way to organize data besides categories. We @intechnic implemented tag solution is a different ways in a different projects.
Here are sets of ideas, that might be common to all tag solution and can be a nice module at the end:

1. any unit can have tags (no need to be a category or category item for that)
2. tags can be managed (add/edit/delete) in central place
3. tag name always lowercase (as a setting)
4. tag validations:
 - minimal/maximal tag count per item
 - minimal/maximal length of a tag
5. setting: deleting a tag (from tag list) cause
 - tag being deleted in all used units
 - warning shown, that such tag can't be deleted
6. automatic total weight calculation for tag (usage count across all units)
7. automatic unit weight calculation for tag (usage count from each unit)
8. tag filter: see all unit items (e.g. in current category) that have given tag
9. tag colud (links in tag cloud have size based on their weight)
10. custom tag link:
 - to page with all item list, that have this tag
 - to page with tag description and possibly link to previous page (with usage)
11. recalculate weight button - in case if weight is incorrectly calculated recalculate all weights
12. tag type - project-specific tag types, that allow to divide tags into groups by their type
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1448 [In-Portal CMS] Front End bug report always 2013-01-10 05:20 2013-01-10 05:22
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/k7akVFZ2W3g/discussion
Change Log Message: Fixes user object right after login
Estimate Points: 1
Summary: User object not available right after login
Description: During a login procedure In-Portal replaces current user_id (-2 = Guest) to one, that was discovered from given username and password. After that redirect happens to show user new content.

However if no redirect happens, that whoever tries to access user object in template, e.g. <inp2:u_Field name="FirstName"/> will fail to do so resulting empty string returned in all cases.
Steps To Reproduce:
Additional Information:
Attached Files: reset_user_object_after_login.patch (620) 2013-01-10 05:20
http://tracker.in-portal.org/file_download.php?file_id=1901&type=bug
(0005349)
alex   
2013-01-10 05:22   
Will test all together later.
(0005350)
alex   
2013-01-10 05:22   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001448: User object not available right after login





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1440 [In-Portal CMS] Admin Interfaces bug report always 2012-11-11 23:37 2013-01-08 08:07
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.1-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/1v5hcsRsbKo/discussion
Change Log Message: Hidden "System Log" section for "Simple" preset
Estimate Points: 0
Summary: Hide "System Log" section for "Simple" preset
Description: Section "System Log", that was added under "System Logs" is visible in "simple" interface preset, but we have a rule, that all new sections are hidden by "simple" interface preset by default.
Steps To Reproduce:
Additional Information:
Attached Files: hide_system_log_1440.patch (1,447) 2012-12-03 10:10
http://tracker.in-portal.org/file_download.php?file_id=1873&type=bug
hide_system_log_v2.patch (2,324) 2012-12-04 03:13
http://tracker.in-portal.org/file_download.php?file_id=1875&type=bug
(0005304)
erik   
2012-12-03 10:11   
Patch attached. Needs testing
(0005308)
alex   
2012-12-04 03:12   
Several problems found and fixed (in added site config): 1. list of fields was incomplete (only 4 of 25 fields were added) 2. toolbar button list (in title preset) was incorrect (e.g. no "refresh" or "export" buttons in this list) 3. required fields were not listed resulting ALL fields became non-required once site config was used
(0005309)
alex   
2012-12-04 03:15   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001440: Hide "System Log" section for "Simple" preset





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1447 [In-Commerce] Payment Gateways bug report always 2013-01-08 05:12 2013-01-08 05:14
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/wLeispoJ3pA/discussion
Change Log Message: Fixes product price update in reoccurring orders
Estimate Points: 1
Summary: Product price change in Catalog breaks down all associated Reoccurring Orders
Description: In-Portal has own implementation of reoccurring orders, that doesn't use one (if any), provided by payment gateway.

Each order in In-Commerce has 2 extra fields, located on "Billing" tab on order editing page, that allow to do that:
"Recurring Billing" - checkbox, that determines if next charge should happen automatically
"Next Charge Date" - date, when next change should happen if "Recurring Billing" is checked

Then cron looks for Processed/Archived orders with both fields set (and next change date in past) and does following to them:
clones them (order with same contents, but "-001" sub-number and in Incomplete status is created)
updates prices in order to match current product prices in catalog
approves order, which triggers charging
removes "Recurring Billing" checkbox from order that was cloned
sets "Recurring Billing" checkbox and "Next Charge Date" checkbox to newly created order

This all might seem right, but problem lies in 2nd step where prices in cloned order are updated from catalog. I personally think, that if customer brought a product for $10, then he should be automatically charged next time (by cron) for same $10 no matter if greedy website administrator set that product price to $15 in catalog.


Looks like 1 part of In-Commerce was thinking this way and prevented these unfair order from ever being charged and kept them in Incomplete status.
Steps To Reproduce:
Additional Information:
Attached Files: product_price_change_breaks_reoccurring_orders.patch (772) 2013-01-08 05:12
http://tracker.in-portal.org/file_download.php?file_id=1900&type=bug
(0005347)
alex   
2013-01-08 05:14   
Will test all together later.
(0005348)
alex   
2013-01-08 05:14   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001447: Product price change in Catalog breaks down all associated Reoccurring Orders





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1446 [In-Portal CMS] Data Management bug report always 2013-01-07 07:54 2013-01-07 07:58
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/cFKvBgpJ52c/discussion
Change Log Message: Fixes no permission error on CSV file upload
Estimate Points: 1
Summary: Unable to upload CSV file on Grid import page
Description: Each grid can optionally have export/import buttons to export all data, that is matching a filter into a CSV file and later import it back.

This can be used for mass record editing in easy spreadsheet format.


However it turns out, that non-root users, who don't have access to "Tools -> System Tools" section can't upload any previously exported CSV file because of "No Permission" error.
Steps To Reproduce:
Additional Information:
Attached Files: no_permission_at_csv_upload.patch (683) 2013-01-07 07:54
http://tracker.in-portal.org/file_download.php?file_id=1899&type=bug
(0005346)
alex   
2013-01-07 07:58   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001446: Unable to upload CSV file on Grid import page





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1445 [In-Portal CMS] Install / Upgrages feature request always 2013-01-05 12:32 2013-01-05 12:33
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.1-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/Sl03Ta5Zv70/discussion
Change Log Message: Automates language pack export for deployment script
Estimate Points: 1
Summary: Automate language pack export for deployment script
Description: Deployment script is a real time saver when it comes to deploying an update to dev/live servers.

However it still requires user actions in terms of exporting latest language pack and comparing it to one we have right now.

Right now I'm doing this (see below) to export language pack for each task:
click on "Regional" section in Admin Console
select English language
click on Export toolbar button
enter language pack filename
click on "Select None" to uncheck all modules
click on "Custom" to select module which I want to export
click on Export button on toolbar
These are horrible 7 clicks I need to make just to have "Custom" module's language pack being exported.

I'm proposing to perform an export of all language packs from modules, that have "project_upgrades.sql" file when "Synchronize" button is pressed in "System Tools" section.

As a result we'll have a separate language pack for every module, that is used by deployment script.
Steps To Reproduce:
Additional Information:
Attached Files: langpack_deployment_automation.patch (2,733) 2013-01-05 12:32
http://tracker.in-portal.org/file_download.php?file_id=1898&type=bug
(0005345)
alex   
2013-01-05 12:33   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001445: Automate language pack export for deployment script





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1399 [In-Portal CMS] Data Management bug report always 2012-09-16 06:42 2013-01-02 11:25
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/6VnUdTJLhV0/discussion
Change Log Message: Removes redundant ItemSQLs settings from unit configs
Estimate Points: 1
Summary: Remove "ItemSQLs" from unit configs
Description: There are 2 (among many) settings in unit config called:

* ListSQLs
* ItemSQLs

These are respectively database queries to select a list of items (on grid template) and one item from a list (on editing template).
Both database queries are usually the same and that's why there is a fallback, which tells that when ItemSQLs setting is missing, then ListSQLs setting is used instead.

This is very good, but since we still have both ItemSQLs and ListSQLs present in most of unit configs, then replacing one database query will required twice same amount of PHP code because we need to change both settings.
Steps To Reproduce:
Additional Information:
Attached Files: itemsqls_removed_core.patch (642,644) 2013-01-02 11:21
http://tracker.in-portal.org/file_download.php?file_id=1896&type=bug
itemsqls_removed_modules.patch (942,323) 2013-01-02 11:22
http://tracker.in-portal.org/file_download.php?file_id=1897&type=bug
(0005343)
alex   
2013-01-02 11:23   
Done. I've also performed automated "Find & Replace" in all unit config files to make all of them look similar (code formatting mostly).
(0005344)
alex   
2013-01-02 11:25   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001399: Remove "ItemSQLs" from unit configs





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1314 [In-Portal CMS] Install / Upgrages refactoring N/A 2012-06-11 07:04 2012-12-24 00:13
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.3  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/2cr5xkoEzWs/discussion
Change Log Message: Upgrade file storage refactoring
Estimate Points: 1
Summary: Change module upgrade script storage system
Description: Right now In-Portal has upgrades.php and upgrades.sql files in each module, that can be upgraded.
Over time we got a lot of code there that is only executed once, but distracts attention from actual last upgrade script code that needs to be written.

I'm proposing, that we return to upgrade script storage system, like it was in 4.2.0 and earlier versions of In-Portal:

one file per version:
* upgrade_5.2.0-B3.sql and upgrade_5.2.0-B3.php and so on

Using php build-in function "version_compare" we can easily sort these files. But this time let's place these files in install folder sub-folder and not in install folder itself, like it was done in 4.2.0 and before.

All PHP upgrade scripts will derive from kUpgradeHelper (as right now) so there will be ability to use common code between modules as before.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1433 [In-Portal CMS] Front End task always 2012-11-05 11:09 2012-12-13 02:57
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-bugs/_PqTRECoiHk/discussion
Change Log Message: Fixes multiple urls pointing to a single page problem
Estimate Points: 1
Summary: Possibility of having 2 urls to a single page
Description: In https://groups.google.com/d/topic/in-portal-bugs/xwFIs71lt38/discussion discussion I've talked about physical and virtual sections and fact, that 2 urls exists to a single physical section.

At first this might not seem a big problem, especially if across a theme "use_section" parameter of m_Link tag is used, which forces url from "Structure & Data" section to be used.
However if user manually guesses url to a TPL file, which is behind "Structure & Data" section url, then page will be shown too.

If google spider guess that url, then website could be banned because 2 different urls result in showing same page at all times.

I propose to automatically redirect (with 301 Moved Permanently http code) visitor to page url equivalent from "Structure & Data" section and put a notice into "System Log".
This way developers would know that somebody still accesses old page url. And using HTTP_REFERER header they would know exactly who that might be.
Steps To Reproduce:
Additional Information: Enable proposed functionality with a setting, that is turned off by default.
Attached Files: 2_urls_to_single_page_1433.patch (5,438) 2012-12-05 10:44
http://tracker.in-portal.org/file_download.php?file_id=1879&type=bug
2_urls_to_single_page_1433_v2.patch (5,409) 2012-12-06 12:43
http://tracker.in-portal.org/file_download.php?file_id=1885&type=bug
2_urls_to_single_page_1433_v3.patch (6,035) 2012-12-11 04:06
http://tracker.in-portal.org/file_download.php?file_id=1889&type=bug
2_urls_to_single_page_1433_v4.patch (7,498) 2012-12-13 02:54
http://tracker.in-portal.org/file_download.php?file_id=1895&type=bug
(0005313)
alex   
2012-12-05 03:11   
Plan: 1. add new system setting "ForceCanonicalUrls" ("Force Canonical Urls") into "Configuration -> Website -> Advanced" section after "Force Redirect to Selected URL Ending" setting 1a. try using new "Add" button to ease system setting adding and then dump INSERT statement into install_data.sql/upgrades.sql file 2. create getSeoTemplate method in kUrlManager class (+ create facade method in kApplication class, like it's one with getPhysicalTemplate method), that will use "structureTemplateMapping" array (see getPhysicalTemplate method for example) to figure out given template's underlying TPL file (be careful, because that array has info about multiple themes in them; only match current theme). 3. add new check to the end of kHTTPQuery::AfterInit method code where parsed template will be given to kApplication::getSeoTemplate method and it turns out that real TPL path is present in url + setting enabled + has seo url do redirect to that seo url. 4. test with both mod-rewrite enabled and disabled 5. try putting TPL path into url, that is listed in ".smsignore" file - no redirect loop should happen 6. use trigger_error method to create notice about redirects performed this way; System Log will catch them automatically, when it's present.
(0005317)
erik   
2012-12-05 10:44   
Patch attached. Needs testing
(0005319)
alex   
2012-12-06 04:10   
1. method getSeoTemplate accepts physical templates as input and that's why it's parameter should be called $physical_template and not a $parsed_template 2. this is no need for preg_match('|' . BASE_PATH check in kHTTPQuery::AfterInit method, because method getSeoTemplate will return empty string in case when we're on right seo template and not on physical one (should be done as I written in plan if this won't break anything) 3. no point in giving both "use_section" redirect parameter & seo_template to kApplication::Redirect method call, because: - with seo template given url will be to seo template - with empty string given + use_section parameter url will also be to seo template - with seo template given + use_section parameter the use_section parameter will have no effect Choose any of 3 proposed solutions in item 3. 4. getRedirectParams method not used (as in code before added code) and it will result in any extra url parameters passed to wrong url (from where we're doing a redirect) will be lost (e.g. "next_template" and so on) resulting in non working page displayed to user
(0005325)
erik   
2012-12-06 12:44   
Patch version 2 attached. Needs testing
(0005332)
alex   
2012-12-11 03:06   
1. no upgrade script
(0005333)
erik   
2012-12-11 04:07   
Added insert-sql for new SystemSettings in upgrades.sql New patch attached. Needs testing.
(0005341)
alex   
2012-12-13 02:56   
Works in general, but some minor issues fixed: 1. code was working in Admin Console but wasn't actually doing anything useful because admin template isn't listed
(0005342)
alex   
2012-12-13 02:57   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001433: Possibility of having 2 urls to a single page 1. Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1436 [In-Portal CMS] Security feature request N/A 2012-11-05 11:24 2012-12-13 02:46
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/qenm_MavpZc/discussion
Change Log Message: Add cookie encryption
Estimate Points: 1
Summary: Encrypt cookie stored at client
Description: I've found an interesting article about mistrusting cookie values submitted by browser to web server - http://phpadvent.org/2011/bake-cookies-like-a-chef-by-michael-nitschinger.

That article explains in details how we can encode/hash cookie values to make sure that In-Portal did set these cookies and they were not faked by user, who wants to hack website.
We can use random string as password used to hash/encode cookies.
Steps To Reproduce:
Additional Information:
Attached Files: encrypt_cookie_1436.patch (4,936) 2012-12-07 12:26
http://tracker.in-portal.org/file_download.php?file_id=1887&type=bug
encrypt_cookie_1436_v2.patch (9,487) 2012-12-10 10:31
http://tracker.in-portal.org/file_download.php?file_id=1888&type=bug
encrypt_cookie_1436_v3.patch (10,159) 2012-12-11 07:42
http://tracker.in-portal.org/file_download.php?file_id=1891&type=bug
encrypt_cookie_1436_v4.patch (13,880) 2012-12-12 05:30
http://tracker.in-portal.org/file_download.php?file_id=1893&type=bug
warning_on_cookie_decrypting.patch (1,183) 2012-12-13 02:44
http://tracker.in-portal.org/file_download.php?file_id=1894&type=bug
(0005315)
alex   
2012-12-05 03:33   
1. create kCookieHasher class (from article, which link is given in task) in "core/kernel/utility/cookie_hasher.php" file and register it in kApplication::RegisterDefaultClasses method 2. make $secret parameter in constructor optional and when it's not given use RandomString system setting value in it's place (see #0001435 task) 3. in Session::SetCookie method create instance of kCookieHasher class (via kApplication::makeClass - non static method !!!) and use it to hash actual cookie value that will be given to "setcookie" function 4. in kHTTPQuery::AddAllVars method before actual cookie values will be added into the class pre-process $_COOKIE array (in local variable) and undo hashing for cookies, that have it 5. cookies, written via JavaScript won't be affected by this change in any way
(0005327)
erik   
2012-12-07 12:27   
Patch attached. Needs testing
(0005328)
alex   
2012-12-07 12:41   
1. I don't see code, that checks if cookie isn't actually encrypted and passes it through. Instead I see code that gives even unencrypted cookies to kCookieHasher class which might even result in php error. 2. Only cookie value is hashed (not cookie name), that results in same hash for 2 cookies with identical values but different names. This way attacker can get 1 cookie value and place it in another cookie value. 3. What about upgrade, does it work normally when RandomString is generated during upgrade and suddenly cookies becomes encrypted. 4. I see potential problem with passing through cookies, that are not encrypted. This way attacker could make hacked cookie look like JS made cookie and pass it through without a problem. I don't know about a solution yet, any ideas?
(0005329)
erik   
2012-12-10 10:36   
New patch version attached. Needs testing. 1. Added code to prevent PHP warnings in cookies decoding process. 2. Added cookie name to hashable string 3,4. Made empty cookie values if after RandomString these becomes undecryptable.
(0005331)
alex   
2012-12-11 03:05   
1. Class kCookieHasher does all encryption/decryption of cookies and it also need to store cookies names, that doesn't need to be decrypted 2. No upgrade script 3. Usage of "var" is deprecated, please use corresponding visibility operator (e.g. private/public/protected) 4. Plain text cookie list contains cookie names, that In-Portal: - don't write itself (e.g. "__ut*", "debug_*", "send_*", "use_*"), but keep "debug_session_id" and add "debug_off" cookie - are written through PHP and must be encrypted (e.g. "cookies_on", "save_username") 4a. exclude all cookie names, that are written through PHP (e.g. Session::SetCookie call) 'catalog_active_prefix', 'cookies_on', 'debug_fastfile', 'debug_host', 'debug_port', 'debug_jit', 'debug_session_id', 'debug_stop', 'original_url', 'save_username', 'send_debug_header', 'send_sess_end', 'start_debug', 'TreeExpandStatus', 'use_remote', '__utma', '__utmz', '__unam'
(0005335)
erik   
2012-12-11 07:43   
1. Fixed 2. Fixed 3. Fixed 4. Fixed New patch attached. Needs testing
(0005338)
alex   
2012-12-12 05:29   
Worked in general, but some minor things (related to code readability and disposition) were adjusted. Fixes: ====== 1. fixed spelling errors 2. added comments to all class properties/methods 3. added more checks on user entered plain text cookie names 4. fixed used ecryption key size to match used cipher (only first 32 symbols of 64 symbol random string are used) 5. a warning was produced during old cookie decryption after random string change Failed expectations: ==================== 1. any of encrypted cookies (even empty one) is 132 symbols long (too much, isn't it? but maybe serialized string with a signature would have similar length) 2. ecrypted cookies are completely unreadable (was expected), so readinging them without working In-Portal installation isn't possible
(0005339)
alex   
2012-12-12 05:34   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001436: Encrypt cookie stored at client
(0005340)
alex   
2012-12-13 02:46   
Patch "warning_on_cookie_decrypting.patch" solves problem, when cookie with "53741477" value being decrypted instead of being skipped because it isn't actually encrypted.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1435 [In-Portal CMS] Security bug report always 2012-11-05 11:22 2012-12-12 03:40
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/qenm_MavpZc/discussion
Change Log Message: Adds random string for each In-Portal installation
Estimate Points: 1
Summary: Generate random string at install
Description: I propose to generate random string (like WordPress does) during In-Portal installation and then potentially use it in various security-related places, like password hashing (along with existing hashing system of course) and such.

This would ensure that even 2 In-Portal installations having same users (with same passwords) registered would still have different hashed passwords. Maybe we can find other interesting uses of this new random string in time.
Steps To Reproduce:
Additional Information:
Attached Files: random_string_configuration_1435.patch (5,245) 2012-12-06 05:28
http://tracker.in-portal.org/file_download.php?file_id=1880&type=bug
random_string_configuration_1435_v2.patch (4,614) 2012-12-07 07:10
http://tracker.in-portal.org/file_download.php?file_id=1886&type=bug
random_string_configuration_1435_v3.patch (7,042) 2012-12-11 05:53
http://tracker.in-portal.org/file_download.php?file_id=1890&type=bug
random_string_configuration_1435_v4.patch (8,170) 2012-12-12 03:38
http://tracker.in-portal.org/file_download.php?file_id=1892&type=bug
(0005314)
alex   
2012-12-05 03:18   
Plan: 1. add new system setting called "RandomString" ("Random String") and place it under "Use non-blocking socket mode" setting in "Configuration -> Website -> Advanced" section 2. during clean install + during upgrade to 5.3.0-B1 version use code from WordPress to generate similar random string 3. verify that for each clean install / upgrade made different string is generated each time
(0005320)
erik   
2012-12-06 05:28   
Patch attached. Needs testing
(0005321)
alex   
2012-12-06 06:22   
(edited on: 2012-12-06 06:24)
1. must use $this->Application->SetConfigValue method instead of doing direct SQLs to SystemSettings table ($this->Application is available during upgrade and during clean install it's available after root password is entered) 2. why current random string value (which is 100% empty during install/upgrade) is being used to generate new random string value?
(0005323)
erik   
2012-12-06 11:31   
1. Impossible - No application object at used execution point. 2. In the task was told - "use code from WordPress to generate similar random string". In wordpress old value is used on new value generation.
(0005324)
alex   
2012-12-06 12:00   
1 - then move random string generation to one of next steps, where application is available Also don't forget, that cookies used during installation also needs to be hashed (see related task about hashing) using generated string
(0005326)
erik   
2012-12-07 07:11   
New patch version attached. Needs testing.
(0005330)
alex   
2012-12-11 02:54   
1. missing upgrade script, that inserts RandomString system setting 2. root password hash is used as initial seed, which introduces always the same (if password is the same) component in string generation 3. generated string doesn't look like these random strings (take from wp-config.php file): define('AUTH_KEY', 'B9Gb>TN!3{onYA(4&PW>K8>@@KD|G8V1/|J-|}m;=_5O2||Vp/tg_6_[Nv]f5E-S'); define('SECURE_AUTH_KEY', '&jFdwDy_Nz^7/0=}ZSZF-iNQ5w^rpCswV}S&8/O+@Z%Jzk{q[OtW8Q4z8k+a|1Gx_=t{sdkjEfyRO&6+JnF__'); 3a. Probably wp_generate_password function should be used. 4. Random string(+seed) generation (+password generation) code looks promising, let's move both functions to UserHelper. Please also preserve behavior when generated random seed (set_transient) is stored somewhere (e.g. cache table) and is reset after N uses.
(0005334)
erik   
2012-12-11 05:55   
1. Fixed 2. Fixed 3. Fixed 4. Fixed New patch version attached. Needs testing
(0005336)
alex   
2012-12-12 03:39   
Looks about right. I've only did following in V4 version: 1. changed global $rnd_value variable into static variable 2. method generateRandomNumber made protected
(0005337)
alex   
2012-12-12 03:40   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001435: Generate random string at install 1. Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1420 [In-Portal CMS] Admin Interfaces feature request always 2012-10-22 18:02 2012-12-06 11:26
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs testing Product Version: 5.1.3  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ckjKdgkBZbk/discussion
Change Log Message: Added CodeMirror to SQL Query page in Admin
Estimate Points: 0
Summary: Using CodeMirror on SQL Query page in Admin
Description: Using CodeMirror (from http://codemirror.net/) on SQL Query page in Admin for better syntax highlighting.

Perhaps we can use the same formatting as PMA does.
Steps To Reproduce:
Additional Information: Implement this as "inp_edit_codemirror" block with "language" parameter, that would allow easily create multiple editors for needed languages on a page.
Attached Files: code_mirror_1420.patch (156,018) 2012-12-05 06:49
http://tracker.in-portal.org/file_download.php?file_id=1878&type=bug
v1_screenshot.png (14,239) 2012-12-06 06:15
http://tracker.in-portal.org/file_download.php?file_id=1881&type=bug
png

textarea_before_codemirror.png (67,645) 2012-12-06 06:16
http://tracker.in-portal.org/file_download.php?file_id=1882&type=bug
png

code_mirror_1420_v2.patch (381,496) 2012-12-06 11:23
http://tracker.in-portal.org/file_download.php?file_id=1883&type=bug
codemirror.zip (485,071) 2012-12-06 11:23
http://tracker.in-portal.org/file_download.php?file_id=1884&type=bug
(0005312)
alex   
2012-12-05 02:42   
Plan: 1. create "core/admin_templates/incs/code_mirror" folder 2. place extracted code from downloaded CodeMirror version into folder created above 3. create block "inp_edit_codemirror" in "form_blocks.tpl" file and connect CodeMirror into it (similar to "inp_edit_codepress" block) 4. carefully test new block at least using following scenarios: - 1/2 blocks on a page and attempt to save form OR go to next tab + is validation error = content is saved - 1/2 blocks on a page and attempt to save form OR go to next tab + no validation error = content is saved
(0005316)
erik   
2012-12-05 06:50   
Patch attached. Needs testing
(0005318)
alex   
2012-12-06 03:56   
1. edit should be of same size as textarea, that were before him (e.g. all paddings, borders, position stays same), but only internals of textarea needs to be replaced by editor 2. new block "inp_edit_codemirror" is specially called this way to allow developer to use any language he pleases, that's why we need to: - remove default language (will force developer to choose a language) - add all supported languages (js/css files) - add support for specifying codemirror options via tag parameters, like it's done with "control_options" parameter in "inp_edit_textarea" block 3. enable line numbers
(0005322)
erik   
2012-12-06 11:26   
Fixes done. New patch version attached. Codemirror full sources attached.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1441 [In-Portal CMS] Optimization bug report always 2012-11-11 23:42 2012-12-04 03:53
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/e3BqcErYvfw/discussion
Change Log Message: Separated Module Installation with Class Constants in Unit Config
Estimate Points: 1
Summary: Separate Module Installation with Class Constants in Unit Config
Description: When doing separate module installation, then it's "constants.php" file isn't included during Application initialization because module isn't installed yet.

This creates Fatal Error in case if classes defined in "constants.php" are used inside unit configs of this not yet installed module.

As a solution I'm proposing to add these lines:
$constants_file = FULL_PATH . '/' . $module_folder . '/constants.php';

if ( file_exists($constants_file) ) {
    require_once $constants_file;
}

after these lines:
include_once(FULL_PATH . '/core/kernel/startup.php');
require_once FULL_PATH . '/core/install/install_toolkit.php';

in each module's install.php file.
Steps To Reproduce:
Additional Information:
Attached Files: installation_constants_1441_modules.patch (3,214) 2012-12-03 09:40
http://tracker.in-portal.org/file_download.php?file_id=1872&type=bug
installation_constants_modules_v2.patch (19,214) 2012-12-04 03:48
http://tracker.in-portal.org/file_download.php?file_id=1876&type=bug
(0005303)
erik   
2012-12-03 09:41   
Patch attached. Needs testing
(0005310)
alex   
2012-12-04 03:50   
File "installation_constants_modules_v2.patch" just has reformatted code.
(0005311)
alex   
2012-12-04 03:53   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001441: Separate Module Installation with Class Constants in Unit Config





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1438 [In-Portal CMS] Admin Interfaces bug report always 2012-11-11 23:33 2012-12-04 02:45
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.1-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/1v5hcsRsbKo/discussion
Change Log Message: Fixed Window Title when Adding "Administrator" user in Admin
Estimate Points: 1
Summary: Wrong Window Title when Adding "Administrator" user in Admin
Description: When adding administrator in "Users Management -> Administrators" section window title shows "Add User" instead of "Add Administrator". Suspect that "User" word is all over that section phrases instead of "Administrator" word.
Steps To Reproduce:
Additional Information:
Attached Files: add_edit_administrator_title_1438.patch (2,193) 2012-12-03 10:45
http://tracker.in-portal.org/file_download.php?file_id=1874&type=bug
(0005305)
erik   
2012-12-03 10:46   
Patch attached. Needs testing
(0005306)
alex   
2012-12-04 02:45   
OK
(0005307)
alex   
2012-12-04 02:45   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001438: Wrong Window Title when Adding "Administrator" user in Admin Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1442 [In-Portal CMS] Optimization task always 2012-11-12 00:10 2012-12-03 09:24
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-bugs/4a-oJAJ264w/discussion
Change Log Message: Removed "Compress Compiled PHP Templates" functionality
Estimate Points: 1
Summary: Remove "Compress Compiled PHP Templates" functionality
Description: In recent years we have added a new feature (enabled via Admin setting) that allows Admin user to "Compress Compiled PHP Templates" thinking to secure the compiled PHP code and greatly benefit from it.

However as time went by we have notice that this feature actually created multiple issues that we have recently came across. Below is a list of discussion where we talked about this issues cased by this particular feature:

Getting out of memory error, when "Compress Compiled PHP Templates" setting enabled - details in additional info field

Fatal Error when using Tags with <? in Templates - details in additional info field
Steps To Reproduce:
Additional Information: Discussion "Getting out of memory error, when "Compress Compiled PHP Templates" setting enabled:

At some point of In-Portal life (can't really find when) we've added functionality that allows to compress PHP files in /system/cache folder.
Doesn't really give any performance benefit and it's only used to prevent attackers on a shared hosting to easily edit these PHP files (since they are located in publicly writable folder) and make it's data to be shown instead actual website.

Functionality described above is enabled by "Compress Compiled PHP Templates" configuration variable (in database "UseTemplateCompression"), which is disabled by default by the way.


Fatal Error when using Tags with <? in Templates:

Looks like we have quite an interesting bug when we get Fatal Error from Parse when trying to using put custom tags that start <?.

Here is an example:

<?xml-stylesheet type="text/css" media="screen" href="http://feeds.feedburner.com/~d/styles/itemcontent.css"?>

Error, that I get is:

Parse error: syntax error, unexpected T_STRING in [path to template.php] on line 12
Attached Files: remove_compiled_template_compression.patch (17,605) 2012-12-03 09:21
http://tracker.in-portal.org/file_download.php?file_id=1871&type=bug
(0005301)
alex   
2012-12-03 09:23   
Will test all together later.
(0005302)
alex   
2012-12-03 09:24   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001442: Remove "Compress Compiled PHP Templates" functionality





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1439 [In-Portal CMS] Install / Upgrages bug report always 2012-11-11 23:35 2012-12-03 02:15
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.1-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/1v5hcsRsbKo/discussion
Change Log Message: Fixed missing "Category Permission Cache" after Installation
Estimate Points: 1
Summary: Missing "Category Permission Cache" after Installation
Description: After clean install category permission cache missing that results in all theme-related sections missing from "Structure & Data" section. That's why I need to use "Rebuild Section Cache" menu in that section to start working with "Structure & Data" section.
Steps To Reproduce:
Additional Information:
Attached Files:
(0005295)
alex   
2012-11-12 03:30   
I've found a place in "c:OnAfterRebuildThemes" event. Before we did complete category cache rebuild after theme rescan. When you have many thousands of categories this would surely slow down whole rebuild process. Right now we do this only, when category cache rebuild setting is set to "silent". Pros: theme file rebuild on each deploy isn't slow on large projects (with lots of categories) Cons: no automatic category permission rebuild on theme rebuild Right now user must go to "Structure & Data" and manually trigger category permission cache rebuild with progress bar.
(0005296)
alex   
2012-11-12 03:31   
Reminder sent to: Dmitry
Read my previous comment.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1444 [In-Portal CMS] Admin Interfaces bug report always 2012-11-27 04:20 2012-11-27 04:22
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.3  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/vnikGXTuVL0/discussion
Change Log Message: Fixes multiple user selector problem
Estimate Points: 1
Summary: Only one of multiple user selectors work
Description: In-Portal has form element called "inp_edit_user", which allows to pick user from a user list shown in popup.

When this element is used more then once on same form, then any user selected always is displayed in last field, where "inp_edit_user" element was used.
Steps To Reproduce:
Additional Information:
Attached Files: multiple_user_selector_fix.patch (771) 2012-11-27 04:20
http://tracker.in-portal.org/file_download.php?file_id=1868&type=bug
(0005299)
alex   
2012-11-27 04:22   
Will test all together later.
(0005300)
alex   
2012-11-27 04:22   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001444: Only one of multiple user selectors work





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1443 [In-Portal CMS] Data Management bug report always 2012-11-20 08:59 2012-11-20 09:03
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B2  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/KBpqVoQcOso/discussion
Change Log Message: Fixing CKEditor e-mail link problem
Estimate Points: 1
Summary: Unable to create link to e-mail in CKEditor
Description: When attempting to create a link to an e-mail (mailto: link) in CKEditor I'm getting an error, that "emailProtection" function isn't defined.
Steps To Reproduce:
Additional Information:
Attached Files: ckeditor_email_link_fix.patch (887) 2012-11-20 08:59
http://tracker.in-portal.org/file_download.php?file_id=1867&type=bug
(0005297)
alex   
2012-11-20 09:02   
Will test all together later.
(0005298)
alex   
2012-11-20 09:03   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001443: Unable to create link to e-mail in CKEditor





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1253 [In-Portal CMS] Localization task always 2012-04-06 10:18 2012-11-18 15:27
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/fQXi69DT_hU/discussion
Change Log Message:
Estimate Points: 0
Summary: English Language pack for 5.2.0
Description: Fixes and changes to be done in English Language pack for 5.2.0 release.
Steps To Reproduce:
Additional Information:
Attached Files:
(0005294)
Dmitry   
2012-11-12 00:14   
Missing "la_fld_ButtonText" phrase on Promo Block add/edit page on 5.2.0





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1432 [In-Portal CMS] Front End bug report always 2012-11-05 11:02 2012-11-08 07:54
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/JfZfDA0uuko/discussion
Change Log Message: Fixes redirect with language negotiation
Estimate Points: 1
Summary: Change first visit detection with language negotiation enabled
Description: In-Portal has a feature (disabled by default), which allows automatically change website language to one, that matches language from "Accept-Language" header, sent by user's browser on first visit.

This way, when user opens http://www.website.tld/ (website on primary language, since no language in url) he is automatically redirected to http://www.website.tld/user-language/index.html.

There is only one major problem: first visit detection. We presume, that first visit is when no page has been specified = home page.

Since home page url is / instead of /index.html user is redirected to http://www.website.tld/user-language/index.html each time he wants to change language back to primary website language while staying on Home Page.

Solution:
Instead of redirect on empty url perform redirect only if referer isn't our website (using kHTTPQuery::refererIsOurSite method) in LanguagesItem::Load method (where redirect is made).
Steps To Reproduce:
Additional Information:
Attached Files: first_visit_language_1432.patch (1,532) 2012-11-07 09:29
http://tracker.in-portal.org/file_download.php?file_id=1860&type=bug
first_visit_language_1432_v3.patch (1,551) 2012-11-07 11:25
http://tracker.in-portal.org/file_download.php?file_id=1865&type=bug
first_visit_language_1432_v4.patch (913) 2012-11-08 07:51
http://tracker.in-portal.org/file_download.php?file_id=1866&type=bug
(0005265)
erik   
2012-11-07 06:21   
Done. Patch attached. Needs testing
(0005268)
alex   
2012-11-07 07:28   
1. Proposed solution in task advised to REPLACE current check for empty url with referrer check. Please re-read task and fix.
(0005275)
erik   
2012-11-07 09:31   
1. Removed current check for empty url 2. Improved code formatting in work area (by use automatic formatting of IDE).
(0005286)
alex   
2012-11-07 10:59   
1. Used method "kHTTPQuery::refererIsOurSite" isn't declared as static and notice is issued on each call. Please look at other code, that uses kHTTPQuery class and how it's been actually used. 2. Don't delete old patch version, but add "_vN" (e.g. "_v2", "_v3", etc.) to patch number and upload it. This way later on comments can be matched to uploaded patches.
(0005287)
erik   
2012-11-07 11:26   
Fixed usage of non-static method. New patch attached. Needs testing.
(0005291)
alex   
2012-11-08 07:53   
In "first_visit_language_1432_v4.patch" patch some changes that were not related to fixing were reverted and code rearranged to easily see what actually was changed.
(0005292)
alex   
2012-11-08 07:53   
OK
(0005293)
alex   
2012-11-08 07:54   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001432: Change first visit detection with language negotiation enabled





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1374 [In-Portal CMS] Admin Interfaces bug report always 2012-08-15 08:07 2012-11-07 14:33
Reporter: alex Platform:  
Assigned To: Dmitry OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/0JOTWLsl6B4/discussion
Change Log Message: Fixes JavaScript error in "Change Log" section
Estimate Points: 1
Summary: JavaScript error in Change Logs section
Description: With "Change Log" section enabled try putting Google Analytics tracking code into corresponding system setting.
As a result new "updated" record would be created in "Change Log" section that would cause major error in JavaScript and a broken grid.

Also detailed information about record isn't revealed on double-click.
Steps To Reproduce:
Additional Information:
Attached Files: change_log_js_error_fix.patch (977) 2012-08-15 08:07
http://tracker.in-portal.org/file_download.php?file_id=1778&type=bug
(0005135)
alex   
2012-08-15 08:13   
Will test all together later.
(0005136)
alex   
2012-08-15 08:17   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001374: JavaScript error in Change Logs section
(0005288)
erik   
2012-11-07 12:16   
Not working. Nothing is written to change log. // save changes to database $sesion_log_id = $this->Application->RecallVar('_SessionLogId_'); if (!$save || !$sesion_log_id) { // saving changes to database disabled OR related session log missing return ; } In this place $sesion_log_id = false, and method returns before writing data to DB.
(0005289)
alex   
2012-11-07 12:19   
That's because: 1. changes logging needs to be enabled first in configuration 2. re-login required to enable logging for currently logged-in user
(0005290)
erik   
2012-11-07 13:02   
Ok, relogin was missed. Works fine.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1427 [In-Portal CMS] Install / Upgrages bug report always 2012-11-05 10:28 2012-11-07 10:48
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Xw33wdGc3nI/discussion
Change Log Message: Fixes mod-rewrite module detecting during installation/upgrade
Estimate Points: 1
Summary: Mod-rewrite detection doesn't work when PHP is installed as CGI
Description: When PHP is installed as CGI and not as "mod_php" into Apache, then system requirements step tells, that mod rewrite is not available.
But in fact mod rewrite works absolutely normally.

I propose to improve detection as advised by http://christian.roy.name/blog/detecting-modrewrite-using-php article by setting custom environment variable in .htaccess file, like this:

<IfModule mod_rewrite.c>
    // Tell PHP that the mod_rewrite module is ENABLED.
    SetEnv HTTP_MOD_REWRITE On
</IfModule>

and checking it later inside PHP:

if ( function_exists('apache_get_modules') ) {
    $modules = apache_get_modules();
    $mod_rewrite = in_array('mod_rewrite', $modules);
} else {
    $mod_rewrite = getenv('HTTP_MOD_REWRITE')=='On' ? true : false;
}


I also recommend wrapping whole rewrite-related code inside that IfModule statement since if mod-rewrite is really unavailable, then any directive from it (e.g. RewriteEngine) could cause "500 Internal Server Error" for whole website.
Steps To Reproduce:
Additional Information:
Attached Files: mod_rewrite_detection_1427.patch (5,045) 2012-11-07 09:19
http://tracker.in-portal.org/file_download.php?file_id=1859&type=bug
mod_rewrite_detection_1427_v2.patch (4,999) 2012-11-07 10:47
http://tracker.in-portal.org/file_download.php?file_id=1864&type=bug
(0005266)
erik   
2012-11-07 06:41   
Done. Patch attached. Needs testing
(0005267)
alex   
2012-11-07 07:26   
1. Mod-rewrite Apache module related directives in .htaccess file were not wrapped with IF statement as advised. 2. Code isn't properly formatted (use automatic formatting of IDE to prevent this error in future).
(0005274)
erik   
2012-11-07 09:20   
1. Changed to wrap directives 2. Changed code formatting Patch replaced with new version. Needs testing
(0005283)
alex   
2012-11-07 10:48   
Patch "mod_rewrite_detection_1427_v2.patch" has simplified code version and few empty lines removed.
(0005284)
alex   
2012-11-07 10:48   
OK
(0005285)
alex   
2012-11-07 10:48   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001427: Mod-rewrite detection doesn't work when PHP is installed as CGI Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1428 [Advanced] General bug report always 2012-11-05 10:33 2012-11-07 10:34
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 1.2.1-B1  
    Target Version: 1.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/nRbQl113Ft4/discussion
Change Log Message: Fixes product name being displayed from wrong database table
Estimate Points: 1
Summary: Displaying wrong product name in shopping cart
Description: On shopping cart template in "advanced" theme product name is retrieved from Name field of "p" unit, however on all other checkout steps "ProductName" field of "orditems" unit is used.

I think, that on shopping cart we also should use ProductName field, which initially is populate from Name field of "p" unit mentioned previously.
Steps To Reproduce:
Additional Information:
Attached Files: product_name_in_shopping_cart_1428.patch (924) 2012-11-07 10:20
http://tracker.in-portal.org/file_download.php?file_id=1862&type=bug
(0005277)
erik   
2012-11-07 10:21   
Made necessary changes in shopping cart. Patch attached. Needs testing
(0005281)
alex   
2012-11-07 10:33   
OK
(0005282)
alex   
2012-11-07 10:34   
Fix committed to [b]1.2.x branch[/b]. Commit Message: Fixes #0001428: Displaying wrong product name in shopping cart Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1417 [In-Portal CMS] Database bug report always 2012-10-20 06:44 2012-11-07 10:27
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ckjKdgkBZbk/discussion
Change Log Message: Fixes data not being escaped in "Query Database" section
Estimate Points: 1
Summary: Data not escaped in "Query Database" section
Description: n-Portal "Tools -> Query Database" section where administrator can perform simple database queries and see result right away.

I've noticed that this text from database "test_& amp;_test" (space between "&" and "amp;" add because Mantis breaks it otherwise) is displayed as "test_&_test" on that page. This means, that data isn't escaped before being displayed on a page.
Steps To Reproduce:
Additional Information:
Attached Files: query_database_escape_1417.patch (509) 2012-11-07 09:58
http://tracker.in-portal.org/file_download.php?file_id=1861&type=bug
query_database_escape_1417_v2.patch (4,642) 2012-11-07 10:26
http://tracker.in-portal.org/file_download.php?file_id=1863&type=bug
(0005260)
erik   
2012-11-07 05:51   
Done. Needs testing
(0005262)
erik   
2012-11-07 05:51   
Patch attached
(0005269)
alex   
2012-11-07 07:30   
1. Doesn't work. See function "array_map" ([url]http://php.net/manual/en/function.array-map.php[/url]) documentation for more info.
(0005276)
erik   
2012-11-07 10:00   
Fixed array_map usage. Patch replaced with new version. Needs testing
(0005278)
alex   
2012-11-07 10:26   
Patch "query_database_escape_1417_v2.patch" adds some code formatting plus moves escaping from data gathering place to data output place.
(0005279)
alex   
2012-11-07 10:27   
OK
(0005280)
alex   
2012-11-07 10:27   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001417: Data not escaped in "Query Database" section Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1415 [Advanced] General bug report always 2012-10-18 23:03 2012-11-07 07:55
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 1.2.1-B1  
    Target Version: 1.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/0gWH5Acm9-s/discussion
Change Log Message: Fixed typo in Templates Navigation Bar
Estimate Points: 0
Summary: Typo Error in Link Enhancement Templates Navigation Bar
Description: There is a typo error in Link Enhancement Templates Navigation Bar

Templates in in-link/links/enhancements/
cancel_enhancement_confirm
enhance_link
extend_enhancement_confirm
extend_enhancement

Error
<inp2:m_include template="platform/elements/navigation_bar.elm" titles="lu_title_MyAccount,lu_title_MyLinks,__item__,lu_title_ExtendCancelEnhancement" templates="platform/my_account/my_account,in-link/my_account/my_links,__default__,inlinks/links/enhancements/{template_name}"/>

last template link start with inlinks/ , should be in-link/
Steps To Reproduce:
Additional Information:
Attached Files: Typo-Error-in-Link-Enhancement-Templates.patch (4,276) 2012-10-18 23:03
http://tracker.in-portal.org/file_download.php?file_id=1835&type=bug
(0005272)
alex   
2012-11-07 07:55   
ОК
(0005273)
alex   
2012-11-07 07:55   
Fix committed to [b]1.2.x branch[/b]. Commit Message: Fixes #0001415: Typo Error in Link Enhancement Templates Navigation Bar Commit on behalf of Dmitry





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1431 [In-Portal CMS] Data Management bug report always 2012-11-05 10:56 2012-11-07 07:50
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/sUl43axkZdQ/discussion
Change Log Message: Fixes timezone setting problem in PHP 5.4
Estimate Points: 1
Summary: Change timezone changing code (PHP 5.4 compatibility)
Description: We should use date_default_timezone_set($timezone) function instead of putenv('TZ=' . $timezone); because this no longer works in PHP 5.4.
Steps To Reproduce:
Additional Information: See http://lv.php.net/manual/en/migration54.incompatible.php for more information.
Attached Files: timezone_sending_code_1431.patch (629) 2012-11-07 04:54
http://tracker.in-portal.org/file_download.php?file_id=1850&type=bug
(0005258)
erik   
2012-11-07 04:56   
Done, needs testing
(0005270)
alex   
2012-11-07 07:49   
OK
(0005271)
alex   
2012-11-07 07:50   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001431: Change timezone changing code (PHP 5.4 compatibility) Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1429 [In-Portal CMS] Template System bug report always 2012-11-05 10:43 2012-11-07 06:10
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/kf-oMaCAmL8/discussion
Change Log Message: Fixes misleading path being used by ModuleInclude tag
Estimate Points: 1
Summary: Incorrectly included templates via <inp2:m_ModuleInclude tag
Description: In-Portal has 2 tags, that allow to use same template multiple times on other different templates:

* <inp2:m_Include - includes 1 given template
* <inp2:m_ModuleInclude - includes given template from each module

There is a problem with m_ModuleInclude tag in Admin Console, where he uses "core/" prefix to include templates from core module (see attached image). This works of course (otherwise whole "Structure & Data" section would be dead), but when you need to replace template, that is included (e.g. "catalog_tab" from core module), then you need to write "core/" before replaced template name.

What I've described might not be a bug, but because of "Sections" tab in "Structure & Data" page is loaded via ajax and is accessing "catalog_tab" (and not "core/catalog_tab", that was replaced) resulting page uses original non-replaced template.

Solution:
Inside m_ModuleInclude tag when we have "core/" as module path, then strip it.

This way template replacement will work.
Steps To Reproduce:
Additional Information: We might try to risk and actually remove "core/" from Modules table and see how it will work afterwards.
Attached Files: inportal_module_include_admin.png (12,100) 2012-11-07 05:54
http://tracker.in-portal.org/file_download.php?file_id=1855&type=bug
png

moduleinclude_and_core_fix.patch (3,064) 2012-11-07 06:08
http://tracker.in-portal.org/file_download.php?file_id=1856&type=bug
(0005263)
alex   
2012-11-07 06:09   
Will test all together later.
(0005264)
alex   
2012-11-07 06:10   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001429: Incorrectly included templates via





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1434 [In-Portal CMS] Admin Interfaces task N/A 2012-11-05 11:12 2012-11-07 05:51
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/1FTmsSOLoU4/discussion
Change Log Message: Disabled HTML editor for "inp_edit_textarea" block by default
Estimate Points: 1
Summary: Disable html editor for "inp_edit_textarea" block by default
Description: In-Portal has a set of blocks used to create nice forms with just a few lines of code in template.

All of them are ok, but I think, that "inp_edit_textarea" block shouldn't display "edit with ckeditor" icon by default under field name.
Steps To Reproduce:
Additional Information: Review all current usages of "inp_edit_textarea" block and where HTML is really needed add allow_html="1" parameter.
Attached Files: disable_html_in_textareas_core.patch (28,302) 2012-11-07 05:48
http://tracker.in-portal.org/file_download.php?file_id=1852&type=bug
disable_html_in_textareas_modules.patch (17,024) 2012-11-07 05:48
http://tracker.in-portal.org/file_download.php?file_id=1853&type=bug
(0005259)
alex   
2012-11-07 05:49   
Will test all together later.
(0005261)
alex   
2012-11-07 05:51   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001434: Disable html editor for "inp_edit_textarea" block by default





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1425 [In-Portal CMS] Admin Interfaces bug report always 2012-11-05 08:12 2012-11-07 05:38
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/c5YflR7pID8/discussion
Change Log Message: Fixes incorrect queued e-mail count in mailing list
Estimate Points: 1
Summary: Incorrect queued e-mail count in "Mailing List" section
Description: We have 3 counters in "Mailing List" section for each created mailing:

- Queued
- Sent
- Total

Currently sent e-mails count isn't subtracted from queued e-mails count. Because of that after mailing is completely processed there are same numbers in echo of these columns.
Steps To Reproduce:
Additional Information:
Attached Files: In-Portal--Emails.png (13,713) 2012-11-05 08:13
http://tracker.in-portal.org/file_download.php?file_id=1847&type=bug
png

mailing_list_queue_counter_fix.patch (6,896) 2012-11-07 05:38
http://tracker.in-portal.org/file_download.php?file_id=1851&type=bug
(0005252)
alex   
2012-11-05 08:15   
Additionally fixed: 1. toolbar buttons "cancel" and "view item" were not visible in the list 2. used toolbar button icon "view_item" was missing and was replaced by "edit" icon
(0005253)
alex   
2012-11-05 08:19   
Will test all together later.
(0005254)
alex   
2012-11-05 08:21   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001425: Incorrect queued e-mail count in "Mailing List" section





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1424 [In-Portal CMS] Admin Interfaces task always 2012-11-05 03:38 2012-11-06 11:21
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.3  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/9q4Z2BZsW_o/discussion
Change Log Message: Renames e-mail events into e-mail templates
Estimate Points: 1
Summary: Inconsistent naming in "E-mail Templates" section
Description: 1. In-Portal has "E-mail Templates" section, where all e-mail templates are defined.
Later via special function call developer can render each of templates and send result to e-mail address given.

But internally we call them as "e-mail events". I think we should do some renaming to have "e-mail templates" term across the system.

2. We also validate, during e-mail sending, that supplied e-mail event name has only upper case letters and dots, but we don't validate the same upon e-mail event adding/editing.

This way it's possible to enter e-mail event name, that won't be sent just because it's named incorrectly.
Steps To Reproduce:
Additional Information:
Attached Files: email_template_rename_core.patch (275,414) 2012-11-06 11:11
http://tracker.in-portal.org/file_download.php?file_id=1848&type=bug
email_template_rename_modules.patch (80,396) 2012-11-06 11:11
http://tracker.in-portal.org/file_download.php?file_id=1849&type=bug
(0005256)
alex   
2012-11-06 11:13   
Will test all together later.
(0005257)
alex   
2012-11-06 11:21   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001424: Inconsistent naming in "E-mail Templates" section





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1369 [In-Portal CMS] Admin Interfaces bug report always 2012-07-23 08:48 2012-11-05 13:04
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0-RC1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/yzlo09tGZ7k/discussion
Change Log Message: Fixes catalog item (uploaded via flash uploader) images deleted on approve
Estimate Points: 1
Summary: Images are deleted during link approval process (flash uploader fix)
Description: 1. I've stumbled upon a problem during link approval (from Admin Console).

There are 2 category permissions:
LINK.OWNER.MODIFY - changes, user makes to it's link are immediately seen on Front-End
LINK.OWNER.MODIFY.PENDING - changes, user makes to it's link are stored in another link record for admin to approve/decline
When user has LINK.OWNER.MODIFY permission it works, like a charm. However, there are a problems in creating a link, that contains all changes made by user.

All files are copied normally. Images are also copied on disk (e.g. image_one.jpg will be copied to image_one_1.jpg), but original image filename stays in link record.

This way approving a link will delete all it's images from disk keeping broken records in Images table.


Since images are copied at least, then I suppose it's working partially. Then we need to ensure, that copied image filenames are put back into Images table record associated with the link, that will hold all modifications.


2. Another small problem here - such links (that needed to be approved) have broken icon in catalog. They should have Pending icon I suppose.
Steps To Reproduce:
Additional Information:
Attached Files: link_approve_removes_wrong_images.patch (2,687) 2012-07-23 08:52
http://tracker.in-portal.org/file_download.php?file_id=1769&type=bug
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
835 [In-Portal CMS] Front End feature request N/A 2010-08-24 13:53 2012-11-05 13:03
Reporter: phil Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/8744e16303365799
Change Log Message:
Estimate Points: 2
Summary: New 5.1.0 style flash uploader porting to Front-End
Description: We have new flash uploader with image preview before form submit capabilities. Seems, that this could be very useful on Front-End.
Steps To Reproduce:
Additional Information:
Attached Files: flash_uploader_on_frontend_advanced.rar (33,387) 2010-08-24 13:53
http://tracker.in-portal.org/file_download.php?file_id=725&type=bug
flash_uploader_on_frontend_core.patch (14,685) 2010-08-24 13:53
http://tracker.in-portal.org/file_download.php?file_id=726&type=bug
flash_uploader_on_frontend_themes.patch (10,059) 2010-08-24 13:53
http://tracker.in-portal.org/file_download.php?file_id=727&type=bug
(0002660)
alex   
2010-08-24 13:54   
You must apply #0000834 task before testing.
(0002670)
Dmitry   
2010-08-26 17:36   
Tested good.
(0002671)
Dmitry   
2010-08-26 17:37   
Reminder sent to: alex
There is a problem with leaving this code for next 5.2.0 feature release - it's planned to be PHP 5, or I am missing something?
(0002681)
alex   
2010-08-27 01:14   
Reminder sent to: Dmitry
This task isn't related to PHP5, since functionality for flash uploader is working fine under PHP4 in administrative console and I only made it available on Front-End too.
(0003905)
Dmitry   
2011-09-24 22:38   
Check if new patch for 5.2.x needed (PHP 5 format)
(0004814)
alex   
2012-07-23 06:39   
Next thing to do there: 1. ensure, that it still works after changes, made in #000043 task 2. apply to "advanced" theme





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1437 [In-Portal CMS] Front End bug report always 2012-11-05 11:31 2012-11-05 11:31
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Xp1w4_As7hw/discussion
Change Log Message: Fixes forced-escaping of front-end input
Estimate Points: 2
Summary: Prevent force-escaping of data on Front-End
Description: Preface:
In-Portal apply "htmlspecialchars" function on all input that comes from Front-End user.

This is good, but when submitted link name is "good & bad", then it will become "good & bad" in database and produce "/category/good-amp-bad.html" url. Both "&" and ";" are restricted symbols and are stripped from url, but "amp" stays.


Solution:
1. kHTTPQuery class - don't automatically encode all input that comes from Front-End
2. Front-End template - find every use of inp2: tag, that is glued into HTML markup (e.g. <input value="_INP_TAG_HERE_"/>) and add html_escape="1" to prevent " or ' from breaking down HTML tag
3. Scan all text fields in database and do htmlspecialchars_decode function on them no matter what's inside. I suppose that function is clever enough to keep existing field value if nothing needs to be replaced.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1430 [In-Portal CMS] Admin Interfaces feature request N/A 2012-11-05 10:50 2012-11-05 10:50
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/M-CRWY81IEs/discussion
Change Log Message: Automates scheduled task configuration
Estimate Points: 2
Summary: Scheduled task execution method detection
Description: In-Portal has scheduled tasks section, where all actions that are performed automatically are specified.

There are 2 ways to invoke these actions:

* when somebody visits a page (default) - no way to ensure that scheduled task will be executed on time
* via cron - complete control and scheduled task protection

Setting for changing to cron invocation mode is located somewhere in "Configuration -> Website -> Advanced" page and I bet nobody goes specially and checks it.


I see several problems with it now:

* scheduled task invocation method selected by default isn't optimal
* if user enabled "Run Scheduled Tasks from Cron" setting and don't add proper line (we don't show exact line anywhere) to crontab, then nothing would work (but user could think it works)


I propose, that we:

1. write last time, when cron.php script was executed and it's execution method: web/cli;
2. on scheduled task page:
- ask user to enable scheduled task execution via cron (quick link, like with Change Logs section) if we know what cron is running;
- if cron isn't running, then show exact crontab line, that user must add to it;
- if cron is running, but it's interval is larger, then 1 minute (compare last recorded date with current execution date), then show warning, that it must be changed;
- show last cron execution date (right now I need to look at all scheduled tasks and find out which one was executed last);
- show relative scheduled task last/next run dates, e.g "5 min ago" or "in 10 hours", since it's easier to understand then comparing all scheduled task dates with current date (which even isn't shown on that page).
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1423 [In-Portal CMS] Data Management bug report always 2012-11-02 06:50 2012-11-02 09:18
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/U6jKZhLplbQ/discussion
Change Log Message: Fixes charset encoding problem from htmlspecialchars function
Estimate Points: 1
Summary: Function "htmlspecialchars" breaks down UTF-8 encoding
Description: I didn't new before, but function "htmlspecialchars" not only escapes text to be safe for usage inside a HTML/XML, but also converts it's encoding to ISO-8859-1 (PHP 5.3.x and below).
As a result any UTF-8 encoded string will be encoded into ISO-8859-1 (after escaping) and all special symbols (e.g. resulted from pasting text from Microsoft Word) would have incorrect encoding, when presented back to user who has UTF-8 encoding on a page.

In PHP 5.4 and up default charset for this function is UTF-8.


As a fix I propose to pass CHARSET constant's value explicitly in each call of htmlspecialchars function across all In-Portal and it's modules.
Steps To Reproduce:
Additional Information:
Attached Files: htmlspecialchars_encoding_core_fix.patch (15,383) 2012-11-02 09:13
http://tracker.in-portal.org/file_download.php?file_id=1845&type=bug
htmlspecialchars_encoding_modules_fix.patch (7,207) 2012-11-02 09:13
http://tracker.in-portal.org/file_download.php?file_id=1846&type=bug
(0005250)
alex   
2012-11-02 09:15   
Will test all together later.
(0005251)
alex   
2012-11-02 09:18   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001423: Function "htmlspecialchars" breaks down UTF-8 encoding





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1422 [In-Commerce] Data Management bug report always 2012-11-02 04:36 2012-11-02 05:20
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/gTlrAd6nU6Q/discussion
Change Log Message: Fixes checkout blocking issue
Estimate Points: 1
Summary: Cart Quantity Change Prevent Checkout
Description: 1. Add a tangible product to cart.
2a. Add the same product again > quantity change to 2.
2b. OR instead of adding another product, when in cart, change quantity and update cart.
3. Click on "proceed to checkout", you are redirected back to cart instead of billing/shipping step, with "Warning: Items quantites and/or order types in you cart have been updated. Please review the changes below before proceeding." message.
Steps To Reproduce:
Additional Information: Reported by Phil.
Attached Files: checkout_blocker_fix.patch (522) 2012-11-02 05:16
http://tracker.in-portal.org/file_download.php?file_id=1844&type=bug
(0005248)
alex   
2012-11-02 05:18   
Will test all together later.
(0005249)
alex   
2012-11-02 05:20   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001422: Cart Quantity Change Prevent Checkout





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1421 [In-Portal CMS] Data Management refactoring always 2012-10-26 10:29 2012-10-26 11:09
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/c0CFc4BjZQE/discussion
Change Log Message: Removes usage of $_REQUEST variable
Estimate Points: 1
Summary: Don't use $_REQUEST in Debugger
Description: There is $_REQUEST super-global variable in PHP, that used to contain Get/Post/Cookie variables all together. However since PHP 5.3.0 actual contents of this variable can be altered using "request_order" ini setting.
Unfortunately by default it no longer contains Cookie values. This is not big issue for In-Portal because it uses it's own $_REQUEST-alike variable maintenance system.

However it's a problem for Debugger, which thinks that there are always all variables inside a $_REQUEST and some of them are Get, some Post and some Cookies.
I'm proposing merge $_GET, $_POST, $_COOKIE arrays manually in the debugger and not rely on $_REQUEST variable's content.
Steps To Reproduce:
Additional Information:
Attached Files: dont_use_request_core.patch (2,074) 2012-10-26 11:08
http://tracker.in-portal.org/file_download.php?file_id=1842&type=bug
dont_use_request_modules.patch (593) 2012-10-26 11:08
http://tracker.in-portal.org/file_download.php?file_id=1843&type=bug
(0005247)
alex   
2012-10-26 11:09   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001421: Don't use $_REQUEST in Debugger





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1419 [In-Portal CMS] Install / Upgrages bug report always 2012-10-22 11:14 2012-10-23 10:59
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/76onMfoitwA/discussion
Change Log Message: Changes some checks on system requirements installation step
Estimate Points: 1
Summary: Incorrect check for "variables_order" setting during installation
Description: We recently 0000413 introduced system setting step where PHP settings are checked to ensure that In-Portal can work on a given server.

1. I've noticed that we are checking if "variables_order" setting contains "GPC" string. But what we should be checking if each of "G", "P" and "C" letters are present in that variable no matter of their order.
Also "S" letter (for $_SERVER) presence should be checked as well.

2. Then additional check must be added for "request_order" setting. If it's value not empty, then check for "GP" presence in it. If it's value is empty, then check for "GP" presence in "variables_order" instead.
Steps To Reproduce:
Additional Information: More info here: http://www.php.net/manual/en/ini.core.php#ini.variables-order
Attached Files: sys_requirement_desc_fix.patch (10,449) 2012-10-23 10:51
http://tracker.in-portal.org/file_download.php?file_id=1840&type=bug
sys_requirements_step_w_description.png (248,818) 2012-10-23 10:59
http://tracker.in-portal.org/file_download.php?file_id=1841&type=bug
png
(0005244)
alex   
2012-10-23 10:52   
Additionally I've created initial draft of "System Requirements" step descriptions and renamed most of check names to be user friendly.
(0005245)
alex   
2012-10-23 10:53   
Will test all together later.
(0005246)
alex   
2012-10-23 10:54   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001419: Incorrect check for "variables_order" setting during installation





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1409 [In-Portal CMS] Install / Upgrages bug report always 2012-09-27 09:30 2012-10-22 11:13
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/td2uriNu9fY/discussion
Change Log Message: Fixes output buffering check during installation
Estimate Points: 1
Summary: Incorrect output buffering check on system requirements installation step
Description: I've noticed, that on system requirements step introduced in 5.2.0 check for output_buffering setting is made incorrectly.
Right now it's only check to be a positive number, but we also should check for "On" value, which means that buffering is enabled and no memory limit set to it.
Steps To Reproduce:
Additional Information:
Attached Files: sys_requirements_output_buffering_fix.patch (1,360) 2012-09-27 09:30
http://tracker.in-portal.org/file_download.php?file_id=1809&type=bug
(0005192)
alex   
2012-09-27 10:33   
Will test all together later.
(0005193)
alex   
2012-09-27 10:35   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001409: Incorrect output buffering check on system requirements installation step





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1418 [In-Portal CMS] Database bug report always 2012-10-22 03:57 2012-10-22 03:59
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ZWaVq_BVXsc/discussion
Change Log Message: Fixes inability to load category item before it's been added to a category
Estimate Points: 1
Summary: Unable to load category item in some cases
Description: In-Portal 2 major kinds of items:

* regular items
* category items

Regular item is an item, that are used a lot across In-Portal, like "user", "affiliate", "manufacturer", etc.
Category item is regular item with extra features for handling it's location inside multiple categories.

Category item can be loaded from database on demand using this code: $object->Load($link_id);
However this implies, that this item has a primary category bound to it. When it doesn't whole loading fails.

This creates a problems when developer trying to act on category item before it has been added to at least one category.
Steps To Reproduce:
Additional Information:
Attached Files: category_item_loading_fix.patch (1,314) 2012-10-22 03:57
http://tracker.in-portal.org/file_download.php?file_id=1839&type=bug
(0005241)
alex   
2012-10-22 03:58   
Will test all together later.
(0005242)
alex   
2012-10-22 03:59   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001418: Unable to load category item in some cases





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1315 [In-Portal CMS] Front End refactoring N/A 2012-06-11 08:05 2012-10-20 06:23
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.3  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/SRxO2pZSqJE/discussion
Change Log Message: Simplifies way how to work with rewrite-urls
Estimate Points: 2
Summary: Routing Ideas
Description: Routing is a way for application decide what content to show based on provided request data:
* url
* headers
* form data

It is implemented in one or another form in all major frameworks, like: Symphony, Zend Framework.


Right now in 5.1.x and 5.2.0-B3 we have rewrite listeners concept. It's a method inside event handler class, that knows how to build/parse urls.

There are several problems that needs to be solved in current implementation:
* small build/parse methods are located in usually big class (event handler) and just to build/parse url you create that class instance and eat lot of memory
* no way to create custom url caching key, since rewrite listeners don't put custom data into caching key
* rewrite listeners always create kModRewriteHelper class instance to use common function for url processing
* if you need to pass some custom parameter to rewrite builder to build a valid link (e.g. filename), then you need to create 2 copies of code
** in event handler: to ensure correct link after executing event on item detail page
** in tag processor: to ensure correct link when printing a list of items

I'm proposing to create base class kRouter with these methods:
1. build(...) - builds an url
2. parse(...) - parses an url
3. getLinkParams($object) - returns extra url parameters, extracted from object, that are required to successfully build a link
4. processParams(&$params) - get parameters, associated with given unit and remove it from global scope (like 5. kModRewriteHelper::getProcessedParams method now)
5. patchCachingKey($caching_key) - get caching key as input and return patched version (allows to put header values into caching key, used to cache parsed url)

Then in unit config you can register router using this code:

'RouterClass' => Array ('class' => 'WidgetRouter', 'file' => 'widget_router.php', 'build_event' => 'OnBuild'),


And class, who right now processes all that stuff called kRewriteProcessor would be renamed to kRoutingManager (maybe not a first) to make it all sound good.
Steps To Reproduce:
Additional Information:
Attached Files:
(0005240)
alex   
2012-10-20 06:23   
Moving to 5.3.0 as proposed in associated discussion.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1416 [In-Commerce] Data Management feature request always 2012-10-20 06:11 2012-10-20 06:11
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ME1hGA8R_ks/discussion
Change Log Message: Allow usage of coupons as order markers
Estimate Points: 1
Summary: Allow usage of coupons as order markers
Description: Add "Remove When Not Effective" checkbox (ON by default) to coupons. This way we keep backwards compatibility and allow users to create coupons that will stay applied even if they don't provide any real discount just to group order by having same coupon. This way store owner can do some additional logic on his side.

Source of discount in this case (when we keep coupon even if it isn't effective) will be the same as before: discount OR none if no discount is in effect.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1401 [In-Portal CMS] Front End feature request N/A 2012-09-16 06:55 2012-10-19 09:16
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/jBAfg7_i7p0/discussion
Change Log Message: Adds support for TypeKit library in CKEditor
Estimate Points: 1
Summary: Using Typekit font library
Description: There is an Adobe website called Typekit - https://typekit.com/, which allows you to use custom nice looking fonts on your website.

To use it you need first to generate a typekit and then it it's ID in following JavaScript code that should be present on all pages:

<script type="text/javascript" src="//use.typekit.com/TYPEKIT_ID_HERE.js"></script>
<script type="text/javascript">try{Typekit.load();}catch(e){}</script>


However, when you try to edit content blocks of website, these nice fonts won't be working inside CKEditor. To make them work we need some extra JavaScript code to be added into Admin Console:

CKEDITOR.on(
    'instanceReady',
    function(ev) {
        var $script = document.createElement('script'),
            $editor_instance = CKEDITOR.instances[ev.editor.name];

        $script.src = '//use.typekit.com/ TYPEKIT_ID_HERE.js';
        $script.onload = function() {
            try{$editor_instance.window.$.Typekit.load();}catch(e){}
        };

        $editor_instance.document.getHead().$.appendChild($script);
    }
);

As you can see both code fragments share TYPEKIT_ID_HERE, which we can move out into a new system setting. When preset we can make CKEditor use it automatically.
Steps To Reproduce:
Additional Information:
Attached Files: typekit_core_feat.patch (7,762) 2012-10-19 09:12
http://tracker.in-portal.org/file_download.php?file_id=1837&type=bug
typekit_themes_feat.patch (886) 2012-10-19 09:12
http://tracker.in-portal.org/file_download.php?file_id=1838&type=bug
(0005238)
alex   
2012-10-19 09:14   
Will test all together later.
(0005239)
alex   
2012-10-19 09:16   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001401: Using Typekit font library





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1398 [In-Commerce] Email Templates bug report always 2012-09-16 06:38 2012-10-19 07:28
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/eFiueLftlTQ/discussion
Change Log Message: Fixes duplicate e-mail sent during checkout
Estimate Points: 1
Summary: Email Sent Twice When Ordering
Description: Hi guys,

I've just discovered that, beginning with 5.2.x, when you place an order, email confirmation is sent twice: once to account email, once to billing email.
It doesn't seems to be a bug, because these 2 address could be different, and I suggest that billing email (and all other billing fields) could be pre-populated with user account details, by default.
Steps To Reproduce:
Additional Information: It can happen, because in code we seem to specify both User ID who did a checkout and billing e-mail from order.

However in versions before 5.2.x only 1 e-mail to billing e-mail was sent.
In 5.2.x we improved mailing system, but haven't changed the code, that uses it. This way 2 e-mail are sent out instead of 1.

Since billing e-mail is required field (not sure, but could be so), then I propose to:
populate it with user's e-mail used during registration
send e-mail only to billing address
Attached Files: duplicate_order_email_modules_fix.patch (7,166) 2012-10-19 07:26
http://tracker.in-portal.org/file_download.php?file_id=1836&type=bug
(0005236)
alex   
2012-10-19 07:27   
Will test all together later.
(0005237)
alex   
2012-10-19 07:28   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001398: Email Sent Twice When Ordering





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1362 [In-Portal CMS] Security feature request N/A 2012-07-22 06:26 2012-10-18 10:37
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/5Hm6xr5K188/discussion
Change Log Message: Improving password hashing algorithm
Estimate Points: 2
Summary: Use even more secure password hashing algorithm
Description: I recommend doing 2 things:

* use adaptive hashing algorithm to hash user's password
* use random salt for each of hashed password (this will ensure different hash even if 2 users use same password for their accounts).


Here how I see it's implemented:

1. add following column to Users (PortalUser) database table after Password field:
- PasswordHashingMethod (1 - md5; 2 - md5+phppass; 3 - phppass)

2. during an upgrade we:
- apply "phppass" hashing over md5 password we have in db
- write down "md5+phppass" as currently used hashing logic

3. at user login (only password isn't hashed via "phppass") we:
- take plain-text password user submits in login form
- hash it using "phppass"
- update Password, PasswordHashingMethod columns of that user

4. at user login (every time) we:
- look at value in PasswordHashingMethod column to determine hashing algorithm
- generate hash using that algorithm and user provided plain-text password
- compare hash to one, that is selected based on Username/Email provided by user from login form

5. when checking password from SystemSettings table (e.g. on "root" user login) we:
- first checking using phppass hashing algorithm
- if that failed, then check using salted md5 algorithm
- if that succeeded, then convert stored password using phppass hashing algorithm and store it to database
Steps To Reproduce:
Additional Information: More reading about this subject:
* http://www.openwall.com/phpass/
* http://www.troyhunt.com/2012/06/our-password-hashing-has-no-clothes.html
Attached Files: improved_password_hashing_core.patch (42,404) 2012-10-18 10:33
http://tracker.in-portal.org/file_download.php?file_id=1833&type=bug
improved_password_hashing_modules.patch (1,456) 2012-10-18 10:33
http://tracker.in-portal.org/file_download.php?file_id=1834&type=bug
(0005234)
alex   
2012-10-18 10:34   
Will test all together later.
(0005235)
alex   
2012-10-18 10:37   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001362: Use even more secure password hashing algorithm





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1414 [In-Portal CMS] Data Management refactoring always 2012-10-18 10:27 2012-10-18 10:30
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/52BfiUOrlPw/discussion
Change Log Message: Adds new function for centralized resource limit setting
Estimate Points: 1
Summary: Centralize code for resource limit setting
Description: Right now following code is copy-pasted in multiple places in In-Portal:

set_time_limit(0);
ini_set('memory_limit', -1);

I propose, that we can move it into a new function and use it instead in all places. Here are the benefits:

* it's auto-completed, so less chances to make typo error in setting name
* we can add parameters to it allowing setting custom memory & time limits
* we can easily track all code, that uses it to determine code, which heavily uses system resources
Steps To Reproduce:
Additional Information:
Attached Files: resource_limit_core.patch (3,899) 2012-10-18 10:27
http://tracker.in-portal.org/file_download.php?file_id=1831&type=bug
resource_limit_modules.patch (1,160) 2012-10-18 10:28
http://tracker.in-portal.org/file_download.php?file_id=1832&type=bug
(0005232)
alex   
2012-10-18 10:29   
Will test all together later.
(0005233)
alex   
2012-10-18 10:30   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001414: Centralize code for resource limit setting





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1364 [In-Portal CMS] Front End bug report always 2012-07-22 07:31 2012-10-17 08:15
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/nUJpXcDa_xs/discussion
Change Log Message: Improvements to forgot password form (part 2)
Estimate Points: 1
Summary: Forgot password improvements (part 2)
Description: In-Portal has forgot password form with 2 fields:

* username
* e-mail

User must enter one or other field's value. I think that having single field called "E-mail or Username" will be more intuitive. When user has entered @ then it's e-mail. If not, then it's username.

Less controls on a form = less thinking for user = more intuitive website.
Steps To Reproduce:
Additional Information:
Attached Files: one_field_forgot_password_core_feat.patch (4,226) 2012-10-17 08:12
http://tracker.in-portal.org/file_download.php?file_id=1829&type=bug
one_field_forgot_password_themes_feat.patch (1,707) 2012-10-17 08:12
http://tracker.in-portal.org/file_download.php?file_id=1830&type=bug
(0005230)
alex   
2012-10-17 08:14   
Will test all together later.
(0005231)
alex   
2012-10-17 08:15   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001364: Forgot password improvements (part 2)





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1023 [In-Portal CMS] Localization feature request N/A 2011-03-13 08:14 2012-10-17 05:53
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-local/Y44XAWlz0AU/discussion
Change Log Message: Added functionality to Keep Language Packs in Sync
Estimate Points: 2
Summary: Ability to Keep Language Packs in Sync
Description: 1. Tracking Changes

I've imagined that such (or alike) translation system would also be useful for In-Portal websites, who are translated into multiple languages to keep all phrases/e-mails in sync between languages.


a. Add "TranslateFrom" ML column into LanguageLabels (former "Phrases") and EmailEvents (former "Events") database tables
b. Add "Use as Primary" button on phrase/e-mail event edit page (with hint "Use this translation as primary for other languages")
Initially all TranslateFrom columns have 0 in them, that means - "I'm in sync".
c. As you probably noticed user then can press either "Save" or "Use as Primary" button after changing a translation on a specific language he is assigned to translate.


Pressing "Use as Primary" would save phrase/e-mail event translation and set this language ID to TranslateFrom field for all other languages except current one:
l1_TranslateFrom = 3
l2_TranslateFrom = 3
l3_TranslateFrom = 0
l4_TranslateFrom = 3
l5_TranslateFrom = 3
In example above you can easily see, that translation was changed on 3rd language and all other languages needs to be updated to be in sync.


Pressing "Save" would set 0 to TranslateFrom column at current language only, like in example below:
l1_TranslateFrom = 3
l2_TranslateFrom = 3
l3_TranslateFrom = 0
l4_TranslateFrom = 3
l5_TranslateFrom = 0
Here 5th language translation was fixed to be in sync and 0 was set in corresponding field.


Then in phrase/e-mail event list we create column "Translation in Sync" (Yes/No), where we would just compare TranslateFrom column from current language with 0. If it's 0, then all is translated.

On phrase editing page we'll show translation form language indicated in TranslateFrom column and not from primary language. Of course if TranslateFrom = 0, then we can fallback to translation from primary language.

Also I've noticed that we're not showing translation from primary language on e-mail event editing, which makes it harder to translate them.


2. Sync Status in %

Propose another grid column in Regional Configuration menu, called "sync status", where we could display % of
synced labels, for reporting purposes.

SUM(IF(l5_TranslateFrom = 0, 0, 1)) / COUNT(l5_TranslateFrom).

SUM(IF(l5_TranslateFrom = 0, 1, 0)) - phrase count, that doesn't require to be synced
COUNT(l5_TranslateFrom) - total phrase count

In total we'll have following Sync columns:
- "Front-End / Both Labels"
- "Admin Labels"
- "Front-End E-mail Events"
- "Admin E-mail Events"


3. Percentages of Content Block Translation

Create a "Scheduled Task" (former "Agent"), that would count % of translated content blocks for each page, which has them. It of course won't allow to track outdated translations as with phrases, but it at least would tell what content blocks aren't translated at all on other languages.

Add multilingual (one column per language) TranslatedContentBlocks column to Categories database table. For each language execute this SQL to fill it:

SELECT SUM( IF(COALESCE(l1_Content, '') = '', 0, 1) ), PageId
FROM PageContent
GROUP BY PageId
Steps To Reproduce:
Additional Information: ORIGINAL IDEA (replaced with new in May-2012)


Here is some ideas how we can keep language packs from multiple languages synchronized with primary language pack for English language.

We invent such term as translatable unit. Units could consist of one or more fields (textareas) that could be translated. Also translatable unit will feature a Description field, that will tell translator, where exactly given text will be used, so translation could be more accurate and appropriate. Each translatable unit have unique identifier (phrase name for phrases and email event name + email event type for email events). Each translatable unit have version number (integer). Once primary language translation is updated or new translation unit is added, then it's version number is incremented.

When we perform translation of set of the translatable units (language pack) to other language, then each unit will keep it's version, version used to make initial translation). When primary unit translation (on English language) will be changed, then it's version number will changed and will differ from all other translated units in other language packs. This way we can detect translation units, that need to be updated to be in sync.

I suppose, that this will be some script on http://www.in-portal.com website. Each website user can register as "translator" for any count of languages so he'll get notified when his expertise is need to keep associated language pack in sync. Page with language packs will be automatically constructed based on finished translation for each language pack and translation progress bar will available for each language pack.

I'll try to look if something, that I've described is already available on the Internet, if not will write something myself.

Here is how Drupal does that: http://localize.drupal.org/translate?no_cache=1265705125.

We can expand this idea to site upgrade so we will track what phrases, email events user have changed and what of there were changed on original language pack in new version of In-Portal and overwrite only not touched by the user.
Attached Files: improved_translation_interface_part1_core.patch (112,884) 2012-10-17 05:48
http://tracker.in-portal.org/file_download.php?file_id=1827&type=bug
improved_translation_interface_part1_modules.patch (1,626) 2012-10-17 05:48
http://tracker.in-portal.org/file_download.php?file_id=1828&type=bug
(0004628)
Dmitry   
2012-05-15 17:35   
Moved task to In-Portal CMS project from Infrastructure.
(0004709)
Dmitry   
2012-06-05 12:42   
Moving to Icebox for now.
(0005218)
alex   
2012-10-11 08:43   
(edited on: 2012-10-16 04:28)
What can happen and I don't know yet how to overcome this: ========================================================== 1. Website has 3 languages and 1 user per each language who does translation. User1 changed translation on 1st language and made it (translation) primary. How likely User2 and User3 would come into Admin Console at same time and edit same label? Who saves last (due temporary table usage) will overwrite user translation change who saved before him. 2. Same website with English/Russian/Latvian languages. Each of translators only speak 2 languages: language he will translate and English. Russian translator clicked "Use as Primary" button on Russian translation and now all other translators see it instead of primary (English) translation because it's most current. However they can't read Russian to know how to translate it into their language. 3. Toolbar button "Use as Primary" shown on phrase/e-mail event saving page would only work for phrase/e-mail event that user sees right now and won't affect other phrases/e-mail events that user is editing together with this one. 4. Manual language pack import. 5. Deployment script language pack import.
(0005227)
alex   
2012-10-16 04:28   
Solutions to above problems =========================== 1. show simultaneous edit message to warn 2nd user, who is trying to edit phrase/e-mail event that is already being edited. 2. presume that translator can use "Google Translate" or similar website to translate source language phrase/e-mail event translation into his native language. 3. update all phrases/e-mail events that are being edited right now. 4. add checkbox that would make all imported phrases in sync OR not in sync. 5. make all new phrases/e-mail events unsynced.
(0005228)
alex   
2012-10-17 05:37   
(edited on: 2012-10-17 05:48)
What was done besides main task: ================================ 1. CSS that was used to highlight code pieces in "System Log" and "E-mail Log" was moved away into Admin Skin 2. Show fields with translation from source language (for given phrase/e-mail event) instead of always translation from primary language 3. Don't show source translation when editing phrase/e-mail event on source language 4. Show "Source Hint Translation" and "Source Column Translation" for phrases 5. Show "Source Subject", "Source HTML Version" and "Source Text Version" for e-mail events 6. Show source translation fields after current translation fields 7. If "Custom" module installed & enabled then use it as default module for newly created e-mail events. 8. Don't show "Set as Primary" toolbar button on phrase/e-mail event editing pages, when there is only 1 language pack imported on website. 9. "%4$s" inside custom fields will be replaced with primary language id (before only "%2$s" was replaced with current language id) 10. LanguageImportHelper now accepts multiple options via bit-system (e.g. 1, 2, 4, 8 ...)
(0005229)
alex   
2012-10-17 05:53   
Patches "improved_translation_interface_part1_core.patch" and "improved_translation_interface_part1_modules.patch" contains all translation functionality without translation statistics calculations.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1413 [In-Portal CMS] Admin Interfaces bug report always 2012-10-15 10:53 2012-10-15 10:56
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.2-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version:  
Reference: https://groups.google.com/d/topic/in-portal-bugs/byxglgLuVdo/discussion
Change Log Message: Fixes missing simultaneous editing message
Estimate Points: 1
Summary: Simultaneous editing message not shown
Description: When admin_b is trying to edit a record, which is already being edited by admin_a, then special message is shown to admin_b.
This message explains, that record is already being edited by admin_a and some data loss might occur if both admins will save that record.

This functionality is disabled by default and can be individually enabled by specifying "CheckSimulatniousEdit" setting in unit config.

I've recently tried to use it on In-Portal 5.2.0 and found that it's no longer working.
Steps To Reproduce:
Additional Information:
Attached Files: simultaneous_editing_message_fix.patch (735) 2012-10-15 10:53
http://tracker.in-portal.org/file_download.php?file_id=1826&type=bug
(0005225)
alex   
2012-10-15 10:55   
Will test all together later.
(0005226)
alex   
2012-10-15 10:56   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001413: Simultaneous editing message not shown





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1351 [In-Portal CMS] Front End feature request N/A 2012-07-10 14:03 2012-10-15 05:05
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.3.0-B1  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/JYv4_FtFFog/discussion
Change Log Message: Adds image pre-resize ability to speed up page loading
Estimate Points: 1
Summary: Pre-resize image to speed up page loading
Description: It's obvious, that users upload images in a higher resolution, then actually is needed on a website and they needs to be resized.

Right now to speed up uploading process In-Portal don't resize image right after uploading, but only at time, when it's displayed in a different resolution on a website.
This seems to be very good solution when:

* small amount of users tries to view a page with image thumbnails displayed;
* images were originally uploaded in low resolution (smaller then 1MB on size).

But in case when a lot of users tries to see page with resized images at a same time and original images are ~4MB+ in size, then it will take a lot of memory and will attempt to resize same image multiple times.

In-Portal don't pre-resize images in background, because it can't guess what image dimensions would be requested in actual theme, user set's as primary.

But I have an idea, how to overcome that:

Create new column in Theme table, called ImageResizeRules, where per-path image resize rules will be written in following format:

* /system/path/one/:format1
* /system/path/two/:format2

Usually each line would look something like this:

/system/images/manufacturers/:resize:100x75;default:img/no_picture.gif


Actual data to place in ImageResizeRules field of the theme database table will be retrieved from <image_resize_rules> node in /_install/theme.xml file of individual theme.

Then CRON script would scan all rules from each theme and pre-resize images according to them.


Even more, if we would consider using Message Queuing servers, like ZeroMQ, then we could schedule resize jobs right after image was uploaded.
Steps To Reproduce:
Additional Information: Also need to create "Settings" field (textarea) in each Agents/Scheduled Task. In context of this discussion this field can be used for specification of image resize settings described in original post.
Attached Files: pre_resize_images_core.patch (17,038) 2012-10-15 05:02
http://tracker.in-portal.org/file_download.php?file_id=1824&type=bug
pre_resize_images_themes.patch (3,193) 2012-10-15 05:02
http://tracker.in-portal.org/file_download.php?file_id=1825&type=bug
(0005221)
alex   
2012-10-12 07:46   
Problems found during implementation: ===================================== 1. because of "storage_engine" option usage in field declaration in unit config actual images to resize could be distributed across different sub-folders and only knowing exact field declaration can help finding them 2. because of same problem only image filename stored in database can be used to do all of above Solution to both problems is obvious: ===================================== 1. specify unit config & field instead of just path on disk (e.g. 'unit-config-prefix:FieldName:') instead of originally proposed '/path/on/disk:' format. 2. get values from given field in database table specified in unit config and for each discovered image filename do proposed resize operation. Pros: unit can change location of actual image store and this won't break anything. Cons: original specs changed on the go.
(0005222)
alex   
2012-10-12 10:11   
While I was updated theme.xml files in theme I realized, that following rule "l-img:ThumbPath:resize:450x" will: 1. resize images event not related to In-Link, since all modules share same Images table 2. contains system setting value (450), which must not be hardcoded 3. resize in-link module images by in-news module image sizes
(0005223)
alex   
2012-10-15 05:03   
Based on all above it's pretty hard to use this system to pre-resize category item images without big overhead. That's why we haven't filled in any resize rules but only implemented plain system which in future can be used by developers.
(0005224)
alex   
2012-10-15 05:05   
Fix committed to [b]5.3.x branch[/b]. Commit Message: Fixes #0001351: Pre-resize image to speed up page loading





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1403 [Custom (Dev. Kit)] Admin Interfaces feature request N/A 2012-09-17 15:59 2012-10-11 08:55
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 1.2.1-B1  
    Target Version: 1.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/3A7SC0FsYZo/discussion
Change Log Message: Added empty configuration section
Estimate Points: 1
Summary: Include configuration section in default installation
Description: Right now every In-Portal module has configuration section, but Development Kit doesn't have one by default and on on each project we need to copy paste if from other project and so on.

Section location: "Configuration -> Custom -> Output"
Steps To Reproduce:
Additional Information:
Attached Files: custom_module_config_section.patch (1,086) 2012-10-11 08:48
http://tracker.in-portal.org/file_download.php?file_id=1823&type=bug
(0005219)
alex   
2012-10-11 08:49   
Will test all together later.
(0005220)
alex   
2012-10-11 08:55   
Fix committed to [b]1.2.x branch[/b]. Commit Message: Fixes #0001403: Include configuration section in default installation





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1317 [In-Portal CMS] Front End bug report always 2012-06-11 08:15 2012-10-10 23:58
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.3  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/70sQKBByKY8/discussion
Change Log Message: Improving IP address detection
Estimate Points: 1
Summary: Allow to specify what IP address source to use
Description: Right now In-Portal always relies on $_SERVER['REMOTE_ADDR'] variable to determine client's IP address.

This works not in all cases. For example, when behind Amazon Web Services load balancer the actual IP address is located in $_SERVER['X_HTTP_FORWARDED_FOR'] variable.

Always relying on X_HTTP_FORWARDED_FOR and then on REMOTE_ADDR is bad idea because attacker could forge fake ip to pass ip-based check. To solve this I'm proposing to add new configuration setting, where user can select preferred IP address sources with possible options:
* $_SERVER['X_HTTP_FORWARDED_FOR']
* getenv('X_HTTP_FORWARDED_FOR')
* $_SERVER['REMOTE_ADDR']
* getenv('REMOTE_ADDR')

Based on server configuration some of these option might return empty string instead of IP address and it's up to use to choose what to use. By default we will use $_SERVER['REMOTE_ADDR'] for backward compatibility.
Steps To Reproduce:
Additional Information: At the end method $this->Application->getIP() would return correct value based on configuration setting.

Since IP address check can be performed before application initialization this new setting must be added to /system/config.php file instead of SystemSettings database table. Of course install/upgrade wizard steps needs to be updated to reflect that.
Attached Files: improved_client_ip_detection_core.patch (16,764) 2012-10-10 08:22
http://tracker.in-portal.org/file_download.php?file_id=1821&type=bug
improved_client_ip_detection_modules.patch (11,065) 2012-10-10 08:23
http://tracker.in-portal.org/file_download.php?file_id=1822&type=bug
(0005215)
alex   
2012-10-10 08:25   
Will test all together later.
(0005216)
alex   
2012-10-10 08:29   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001317: Allow to specify what IP address source to use
(0005217)
alex   
2012-10-10 08:31   
Reminder sent to: Dmitry
Please check text added on "System Configuration" step for "Trust Proxy" setting.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1361 [In-Portal CMS] Admin Interfaces task N/A 2012-07-22 05:20 2012-10-10 05:21
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/A_UAGo4npOA/discussion
Change Log Message: Changing scheduled task runtime recording from minutes to seconds
Estimate Points: 1
Summary: Scheduled task run time calculation change
Description: Right now scheduled task (or agent) execution time is calculated in minutes. This way all scheduled tasks that took less a minute to execute are displayed as running 0 minutes.

I think we should record seconds, which too each scheduled agent execution time and then display them in following format "hh:mm:ss". For example 12 seconds would look "00:00:12".
Steps To Reproduce:
Additional Information:
Attached Files: scheduled_task_runtime_in_seconds.patch (5,134) 2012-10-10 05:12
http://tracker.in-portal.org/file_download.php?file_id=1820&type=bug
(0005212)
alex   
2012-10-10 05:13   
I've also display "< 1 sec." instead of "00:00:00" in scheduled task list and edit pages.
(0005213)
alex   
2012-10-10 05:20   
Will test all together later.
(0005214)
alex   
2012-10-10 05:21   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001361: Scheduled task run time calculation change





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1344 [In-Portal CMS] Front End bug report always 2012-07-09 11:29 2012-10-10 04:53
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ULS519l-OcQ/discussion
Change Log Message: Fixes temporary images not deleted after upload
Estimate Points: 1
Summary: Deleting of temporary files during upload
Description: Here is how flash uploader works in In-Portal:
1. image is uploaded in /system/tmp/ folder
2. images, older then 1 day are deleted from /system/tmp/ folder (if user uploaded image, but never submitted a form)
3. image thumbnail is generated in /system/tmp/resized/ folder
4. image is moved from /system/tmp to /system/images/final_location_folder

There is clearly 1 item missing where images older then 1 day are deleted from /system/tmp/resized/ folder as well.
Steps To Reproduce:
Additional Information:
Attached Files: delete_temp_resized_files_fix.patch (472) 2012-10-10 04:50
http://tracker.in-portal.org/file_download.php?file_id=1819&type=bug
(0005210)
alex   
2012-10-10 04:52   
Will test all together later.
(0005211)
alex   
2012-10-10 04:53   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001344: Deleting of temporary files during upload





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1363 [In-Portal CMS] Data Management bug report always 2012-07-22 07:27 2012-10-09 11:05
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/_zXDBTcrRiw/discussion
Change Log Message: Fixes user selector problem with missing Username field problem
Estimate Points: 1
Summary: User selector not working
Description: 1. Make registration by e-mail default option for new In-Portal installation (set RegistrationUsernameRequired system setting to 0 by default).

2. Since e-mail field is required all the time, then use it in user selector, but when not available fallback to Username field.

3. Since we store UserID in database, then no upgrade script is required.
Steps To Reproduce:
Additional Information:
Attached Files: user_selector_missing_username_core_fix.patch (24,597) 2012-10-09 10:38
http://tracker.in-portal.org/file_download.php?file_id=1817&type=bug
user_selector_missing_username_modules_fix.patch (32,860) 2012-10-09 10:38
http://tracker.in-portal.org/file_download.php?file_id=1818&type=bug
(0005207)
alex   
2012-10-09 10:32   
Database query mask, that is used in 'left_sql' option by kLEFTFormatter class has changed from: SELECT %s FROM TableName WHERE `%s` = '%s' to: SELECT %s FROM TableName WHERE %s
(0005208)
alex   
2012-10-09 11:03   
Will test all together later.
(0005209)
alex   
2012-10-09 11:05   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001363: User selector not working





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1396 [In-Portal CMS] Data Management task N/A 2012-09-16 06:32 2012-10-04 10:49
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/W3V9cRomE1M/discussion
Change Log Message: Adds support for bmp/jpeg file uploads
Estimate Points: 1
Summary: Add "jpeg" and "bmp" to allowed image file extensions
Description: Currently on most upload fields, where images are uploaded only files with following extensions are allowed for upload:

* jpg
* png
* gif

I'm proposing also to allow following extensions:

* jpeg
* bmp
Steps To Reproduce:
Additional Information:
Attached Files: allow_jpeg_and_bmp_uploads_core.patch (3,698) 2012-10-04 10:47
http://tracker.in-portal.org/file_download.php?file_id=1815&type=bug
allow_jpeg_and_bmp_uploads_modules.patch (3,265) 2012-10-04 10:47
http://tracker.in-portal.org/file_download.php?file_id=1816&type=bug
(0005205)
alex   
2012-10-04 10:48   
Will test all together later.
(0005206)
alex   
2012-10-04 10:49   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001396: Add "jpeg" and "bmp" to allowed image file extensions





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1412 [In-Portal CMS] Data Management bug report always 2012-10-04 10:35 2012-10-04 10:37
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/bI2zPOQz3to/discussion
Change Log Message: Fixes missing parent event in temp handler thriggered events
Estimate Points: 1
Summary: Parent event not available in Temp Handler triggered events
Description: In-Portal uses kTempTablesHandler class to manage whole process of safe record editing within temporary tables.
During whole process several events, like "OnBeforeCopyToLive", "OnAfterCopyToTemp" and such are triggered.

However $event object available in them doesn't have $event->MasterEvent attribute populated with original event with caused temp handler processed action to happen.
Steps To Reproduce:
Additional Information:
Attached Files: temp_handler_masterevent_missing_fix.patch (490) 2012-10-04 10:35
http://tracker.in-portal.org/file_download.php?file_id=1814&type=bug
(0005203)
alex   
2012-10-04 10:36   
Will test all together later.
(0005204)
alex   
2012-10-04 10:37   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001412: Parent event not available in Temp Handler triggered events





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1003 [In-Portal CMS] Database feature request N/A 2011-02-14 13:20 2012-10-04 10:30
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: minor OS Version:  
Status: resolved Product Version: 5.1.2-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/-YLc3RLkEtc/discussion
Change Log Message: Added powerful Event Logging engine
Estimate Points: 3
Summary: Logging engine
Description: In-Portal has very powerful logging system when debug mode is on, but if developer won't look at errors reported there in time (e.g. before he closes the page with debugger), then most probably he won't get same error next time.

Also In-Portal has nice "Silent Log" feature, when all errors got written to file, but it is turned off by default and that log (since it's a text file) can't be easily analysed.

So this is good error reporting code, but it's results are not being recorded for future analysis and what's is recorded is not enough to properly pinpoint problematic place in code after error already happened and there is no more place to retrieve data from.


To solve above mentioned issues I'm proposing to create kLogger class (and associated SystemLog table), that would:
* handle sql error processing
* handle php error/notice/warning processing
* handle exception processing
* handle user-defined messages

What should be recorded along with each event being logged:
* $_SERVER['HTTP_HOST'] - address of page's webserver (useful in multi-user development environment)
* $_SERVER['REMOTE_ADDR'] - ip address of page visitor
* current user id (guest or not)
* SessionData/UserSession table - session data
* SessionID - session id (when available)
* $_GET, $_POST, $_COOKIE - user input on page, where event happened
* $_SERVER['REQUEST_URI'] - url that was used to access the page
* $this->Application->isAdmi - is user an admin or not
* complete trace to the php method, that raised that event
[TODO] * occurrences count: today/yesterday/last week/last month
[TODO] * last occurrence on - date/time when event was raised


Automatic system log cleanup:
* none
* automatic (weekly)
* automatic (monthly)

In Admin Console there will be a new section under "Summary & Logs" called "System Log" with list of all logged events, that happened.
Steps To Reproduce:
Additional Information: === Info moved from 0000268 ===
1. create kLogger class, that would:
- handle sql error processing
- handle php error processing
- handle exception processing
- ability to handle user defined events
- put data to silent log, when not in debug mode
- also record $_SERVER['HTTP_HOST'] to store host, where problem was found in multi-user development environment
- also record current user id (guest or not) and it's session data
- optionally use database to store all errors, that are happening
- report errors to in-portal website for analysis
Attached Files: system_log_feature_core.patch (124,059) 2012-10-02 12:09
http://tracker.in-portal.org/file_download.php?file_id=1812&type=bug
fatal_error_with_disabled_syslog_fix.patch (479) 2012-10-04 10:29
http://tracker.in-portal.org/file_download.php?file_id=1813&type=bug
(0005145)
alex   
2012-08-20 08:40   
All remote logging functionality has been moved to #0001379 task.
(0005198)
alex   
2012-10-02 11:07   
What was actually done: ======================= 1. methods log/logDelete was added to kApplication class to allow developer to put/delete user-defined message into "System Log" 2. fatal errors, that cause "white screen" effect (e.g. parse error, out of memory) are handled 3. added e-mail event, that sends selected user-defined messages from System Log to e-mail, specified in configuration 4. System Log can work in 3 modes: always enabled (system errors/exception and user-defined message), only user-defined messages, always disabled 5. level of logging (decision to allow message to be written into System Log) can be controlled via configuration 6. following info can be stored with each logged message: - unique id - log level - emergency/alert/critical/error/warning/notice/info/debug - type - php/database/other - code - for errors it's error code (e.g. MySQL error code) - message - text of logged message (for errors it's error text) - timestamp - when message was logged - event name - even, which caused this message to be logged (directly or indirectly), e.g. "p:OnCreate" - ip address - ip address of website visitor - hostname - domain where In-Portal is installed (useful to know if site domain feature is used) - interface - front/admin/cron front/cron admin/api - request source - web/cli - request uri - request data - complete set of GET/POST/COOKIE variables at moment of message logging - logged-in username - session key - session data - complete trace (with function arguments) to place where message was sent (useful for error messages) - file and line inside that file, where message was sent (for errors indicates place where error happened) - process id - allows easily to identify set of message during single In-Portal run - amount of used memory at time of message sending (not at the end of script) - allows to see memory eating progress - custom data - any data, that can be stored in database and contains extra info about the message What was done additionally: =========================== 1. all php error/exception and sql error handling code was moved away from kApplication class into new kLogger class 2. added kDBConnection::connectionOpened and kDBLoadBalancer::connectionOpened methods for checking current database connection state 3. removed SILENT_LOG functionality, since "System Log" already does silent logging and much more 4. functionality for throwing messages, longer then "log_errors_max_len" setting from php.ini was improved (to look at "log_errors_max_len" setting value) and moved from Debugger to kLogger class and because of that debugger now is dependant on kLogger class presence 5. Debugger now can handle fatal errors, that caused "white screen" effect (e.g. parse error, out of memory) 6. removed E_STRICT errors, displayed inside AJAX responses (PHP 5.4+ only) 7. debugger setting DBG_IGNORE_STRICT_ERRORS removed, since in In-Portal 5.2.0+ we mixed all major strict errors 8. debugger now can handle all existing error types including E_CORE_* errors 9. debugger now doesn't use special kApplication methods to register it's own error/exception handlers when user together with kApplication class 10. method "__toString" added to kBase class allowing to get string representation of every kBase class descended (used during backtrace printing in System Log) 11. fixed notice caused by session printing inside debugger right after session creation (e.g. user successful login)
(0005199)
alex   
2012-10-02 12:08   
Found issues when upgrading from 5.1.0 to 5.2.0 after module selection step (if system log was enabled): 1. lots of errors about missing SystemLog table are displayed right on the screen. 2. running scheduled tasks during upgrade results in strange errors, when RunSchedule field having integer value is treated as interval. Possible solution could lay in a way to do real class (which does what we don't want it to do during install/upgrade) replace with it's descendant class with all problematic methods overwritten with stubs. This would be better, then doing IS_INSTALL constant check on every corner.
(0005200)
alex   
2012-10-02 12:12   
Tested install/upgrade. Install caused no errors. Some errors during upgrade when user enabled system log during upgrade. Will fix them later.
(0005201)
alex   
2012-10-02 12:13   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001003: Logging engine
(0005202)
alex   
2012-10-04 10:30   
Patch "fatal_error_with_disabled_syslog_fix.patch" fixes fatal error, that was always happening when system log is disabled and attempt is made to catch last error happened on a page.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1411 [In-Portal CMS] Admin Interfaces bug report always 2012-09-30 07:06 2012-09-30 07:10
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/eXby2qoKk6g/discussion
Change Log Message: Fixes incorrect label escaping in error messages
Estimate Points: 1
Summary: Excessive escaping of error messages on configuration section
Description: Recently I've added custom error message for one of system settings. Of course phrase of that error message wasn't translated and I planned to translate it as usual with inline translation links.
However I was redirected to front-end instead of phrase translation window opening. This happened because javascript translation link contained \= instead of = resulting HTML markup error.
Steps To Reproduce:
Additional Information:
Attached Files: error_message_double_escaping_on_configuration_fix.patch (639) 2012-09-30 07:06
http://tracker.in-portal.org/file_download.php?file_id=1811&type=bug
(0005196)
alex   
2012-09-30 07:09   
Will test all together later.
(0005197)
alex   
2012-09-30 07:10   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001411: Excessive escaping of error messages on configuration section





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1410 [In-Portal CMS] Email Templates bug report always 2012-09-28 07:46 2012-09-28 08:00
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/5aUJeCu5-CM/discussion
Change Log Message: Adds missing e-mail events after upgrade
Estimate Points: 1
Summary: Missing e-mail events after upgrade
Description: In 0000778 task we've added ability to e-mail password to users added/changed through Admin Console.

However these new e-mail events were not added to upgrade script resulting in this functionality not working at all for in-portal websites, where upgrade to 5.2.0 was done.
Steps To Reproduce:
Additional Information:
Attached Files: missing_email_events_fix.patch (805) 2012-09-28 07:57
http://tracker.in-portal.org/file_download.php?file_id=1810&type=bug
(0005194)
alex   
2012-09-28 07:59   
Will test all together later.
(0005195)
alex   
2012-09-28 08:00   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001410: Missing e-mail events after upgrade





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1408 [In-Portal CMS] Data Management bug report always 2012-09-27 07:26 2012-09-27 08:19
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/dkzeBBEyl14/discussion
Change Log Message: Fixes warning from incorrect mktime() usage
Estimate Points: 1
Summary: Usage of mktime() function with no arguments
Description: I've found 2 places, where mktime() function was used without any argument passed. Since PHP 5.1 this triggers E_STRICT warning.
Steps To Reproduce:
Additional Information:
Attached Files: mktime_usage_fix_core.patch (641) 2012-09-27 07:26
http://tracker.in-portal.org/file_download.php?file_id=1807&type=bug
mktime_usage_fix_modules.patch (605) 2012-09-27 07:26
http://tracker.in-portal.org/file_download.php?file_id=1808&type=bug
(0005190)
alex   
2012-09-27 08:13   
Will test all together later.
(0005191)
alex   
2012-09-27 08:19   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001408: Usage of mktime() function with no arguments





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1407 [In-Portal CMS] Front End bug report always 2012-09-27 06:06 2012-09-27 06:08
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/YYFvNtFaFWE/discussion
Change Log Message: Fixes &amp in url after redirect from FormManager
Estimate Points: 1
Summary: Additional parameters lost during FormManager redirect
Description: In In-Portal 5.2.0 JavaScript class FormManager was introduced. It allows to process any form on a page using ajax instead whole page submit.

To use it you must:

* register form on a page
* handle it's submit and pass it to FormManager instead
* wrap form processing event in AjaxFormHelper::transitEvent method call

If wrapped event requested a redirect to other, then current, page then instead of doing that redirect AjaxFormHelper::transitEvent method grabs redirect url and returns is to as 'redirect_to' parameter to FormManager class.
This gives a lots of space, since FormManager class can:

* redirect url to that url
* show page from that url in div/popup

Because of FormManager is JavaScript class and AjaxFormHelper is PHP class an url in 'redirect_to' parameter must not have "&" in it.
But it does and this results in all extra url parameters lost on the page, where redirect is made.
Steps To Reproduce:
Additional Information:
Attached Files: amp_problem_in_ajaxformhelper_fix.patch (879) 2012-09-27 06:06
http://tracker.in-portal.org/file_download.php?file_id=1806&type=bug
(0005188)
alex   
2012-09-27 06:07   
Will test all together later.
(0005189)
alex   
2012-09-27 06:08   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001407: Additional parameters lost during FormManager redirect





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1406 [In-Portal CMS] Front End bug report always 2012-09-27 05:48 2012-09-27 05:54
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.1.1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ynLYg8DMW9I/discussion
Change Log Message: Fixes page reload problem after login on Chrome
Estimate Points: 1
Summary: Violation of one url = one resource seo rule on login/logout
Description: There is a SEO rule, where 1 page content must have exactly 1 (and not more) url to it. If page content changes you:

* either must send proper caching headers (which In-Portal doesn't do at all)
* or change page url

But if we show user-specific content (content that is one for logged-in users and other for non logged-in users) on a page, then, because we have same url to that page, browser can agressively cache it resulting after logout user being presented with logged-in only page version.


This wasn't a problem before, but now once Google Chrome v21 (with MacBook Pro Retina support) is out it actually used it. I saw this on Vista (not Windows 7):

1. visit website (you're not logged in)
2. see "please login" sidebox on the left (while on home page)
3. login
4. browse through website
5. press logout link
6. see logged-in side box on the left instead of "please login" side box

Despite long story problem is quite easy to fix:
- add "?login=1 parameter to page url where user is redirected after login
- add "?logout=1 parameter to page url where user is redirected after logout
Steps To Reproduce:
Additional Information: Also content language negotiation redirect might not pass login state (login/logout parameter) to url where it redirects user.
Attached Files: track_login_state_in_url_fix.patch (9,286) 2012-09-27 05:48
http://tracker.in-portal.org/file_download.php?file_id=1805&type=bug
(0005185)
alex   
2012-09-27 05:52   
As a bonus I've also changed logout code to allow optional redirect to page in "next_template" url parameter. Login code has this option all the time.
(0005186)
alex   
2012-09-27 05:53   
Will test all together later.
(0005187)
alex   
2012-09-27 05:54   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001406: Violation of one url = one resource seo rule on login/logout





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1405 [In-Portal CMS] Front End bug report always 2012-09-26 05:30 2012-09-27 04:23
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-RC1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/GCI_WtQuf50/discussion
Change Log Message: Fixes incorrect parsing of urls with & amp;
Estimate Points: 1
Summary: Urls with "&" are incorrectly parsed
Description: In In-Portal 5.2.0-RC1 release function kRewriteUrlProcessor::parse behaviour was changed to allow detection of url parameters (see http://tracker.in-portal.org/view.php?id=1279 task).

However it still fails to properly parse url if it:

* has ?env=... in it
* has & instead of & as parameter separator
Steps To Reproduce:
Additional Information:
Attached Files: encoded_url_parameter_parse_fix.patch (1,561) 2012-09-26 05:30
http://tracker.in-portal.org/file_download.php?file_id=1804&type=bug
(0005183)
alex   
2012-09-27 04:22   
Will test all together later.
(0005184)
alex   
2012-09-27 04:23   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001405: Urls with "&" are incorrectly parsed





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1404 [In-Portal CMS] Front End bug report always 2012-09-21 10:27 2012-09-21 10:37
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/UI943cjknsw/discussion
Change Log Message: Adds kApplication::getSectionTemplate method
Estimate Points: 1
Summary: Method for getting section template
Description: In In-Portal 5.2.0 "use_section" parameter of m_Link tag was introduced.
It allows to pass template filename into m_Link tag and get back nice url from "Structure & Data" section. For example:

* without: <inp2:m_Link template="in-link/my_account/my_favourites"/>; result: http://www.website.tld/in-link/my_account/my_favourites.html
* with: <inp2:m_Link template="in-link/my_account/my_favourites" use_section="1"/>; result: http://www.website.tld/in-link/my-account/my-favourites.html

I've extracted code used to process "use_section" parameter in new kApplication::getSectionTemplate method.
Steps To Reproduce:
Additional Information:
Attached Files: section_template_from_physical_template.patch (2,752) 2012-09-21 10:27
http://tracker.in-portal.org/file_download.php?file_id=1803&type=bug
(0005181)
alex   
2012-09-21 10:35   
Will test all together later.
(0005182)
alex   
2012-09-21 10:37   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001404: Method for getting section template





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1402 [In-Portal CMS] Data Management refactoring N/A 2012-09-16 13:03 2012-09-16 13:03
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/UJwlLFoq7WU/discussion
Change Log Message: Unites /system/config.php file processing/usage code
Estimate Points: 1
Summary: Create intermediate class to access /system/config.php file
Description: File /system/config.php is created during In-Portal installation and contains all core settings that are needed to be able to run In-Portal.
For example it contains database connection information. Then once connected to database In-Portal can get other settings from there.

This file very powerful, however code that uses it is scattered across the system. For example there is:

* kUtil::parseVars method, that returns contents of that file as array (used each time)
* some pieces of code in /core/kernel/startup.php file, that ensures default values for some settings, that might be missing (used each time)
* some pieces of code in /core/install.php file, that ensures default values for some other settings, that might be missing (used during install)

I'm proposing to create kSystemConfig class, that can be accessed from everywhere (due his static nature) and will ensure that all settings have their default values and can be accessed properly.
Steps To Reproduce:
Additional Information: Constants, that are defined based on /system/config.php file contents, like SQL_DB, ADMIN_DIRECTORY can stay of course.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1400 [In-Portal CMS] Front End feature request N/A 2012-09-16 06:47 2012-09-16 06:47
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.3  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/RZZdi1nXX0k/discussion
Change Log Message: Adds ability to display any fields inside a menu elements
Estimate Points: 1
Summary: MenuHelper improvements
Description: Right now we have nice <inp2:st_CachedMenu .../> tag, that prints every menu on website without doing a database query.
This works good, however in some projects I came across situations where a new database field (e.g. extra css class name) was added to a page (category) and this field needs to be used during menu printing.

This requires to override 2 methods in MenuHelper class.

I'm proposing to create an array (as a property of MenuHelper class), where mapping is created between Categories database table fields and parameter names, used to retrieve their values from template.

Here is an example array:

Array (
    'parent_path' => 'ParentPath',
    'icon' => Array ('Icon', 'resize:100x100'),
);

Then these parameters would be used with GetField method.
Steps To Reproduce:
Additional Information: Also need to reset menu cache, when either of these new fields will be changed in a category record.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1397 [In-Portal CMS] Front End feature request N/A 2012-09-16 06:36 2012-09-16 06:36
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: Adds parser-assisted javascript code movement across template
Change Log Message: https://groups.google.com/d/topic/in-portal-dev/4nQ1CyIGFy8/discussion
Estimate Points: 1
Summary: Delayed execution of JavaScript code
Description: To optimize page load times on website Google recommends to postpone JavaScript code execution until it's really needed on a page and to move most (all if possible) of JavaScript code at footer of webpage.
This way loading of external javascript files won't affect page load speed.

Usually, in In-Portal, we put JavaScript code, that is used to process given piece of HTML right after it. This way we keep all in one place, but it's against modern Google approach I've described above.


I'm proposing to create a means to allow placing JavaScript right after relevant HTML piece in TPL file, but at the end make that JavaScript available at the end of a page, where it really belongs.
Usually I would use $(document).ready(...) construct to do this, but since even jQuery itself is loaded at page bottom this becomes impossible.

For example we can use existing tags to arrange this or create new tag just for that. Here is how I see it.

--- CODE ON THE PAGE ---
some html here

<inp2:m_Queue queue_name="...">
    <script>
        // some javascript here
    </script>
</inp2:m_Queue>

some other html on the page

--- CODE IN FOOTER ---
<script>
    $(document).ready(function () {
        <inp2:m_Queue queue_name="..." minify_as="js"/>
    });
</script>


Some explanations:

* Parameter queue_name in example above is optional and allows to have several queues on one page.
* Parameter minify_as tells how queued data should be minified. When omitted no minification happens.
* Tag <script> is added inside just to keep IDE auto-complete working, otherwise whole JS code would be highlighted as big HTML error.
* All <script ...> and </script> tags would be stripped from the result to create one unified block.
* Each m_Queue pair tag can be interpreted as sort-of <inp2:m_Capture to_var=""> ... </inp2:m_Capture> that appends new data to already queued data.
* Each m_Queue non-pair tag can be interpreted as <inp2:m_Param.../> tag to get data from that parameter.

Hope you can see potential of m_Queue tag, since it allows to put absolutely anything into queue for later usage while keeping related data in same place in template.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1395 [In-Portal CMS] Email Templates bug report always 2012-09-14 11:10 2012-09-14 11:13
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/sAVoUaUMNZc/discussion
Change Log Message: Fixes stripped new lines in plain text e-mails
Estimate Points: 1
Summary: Too aggressive line ending normalization in plain text e-mails
Description: In In-Portal 5.2.0 release ability to separately enter HTML and Plain-text versions of e-mail was added.
Playing around with this feature I discovered that plain text version of e-mail being severely transformed in terms of line ending before it gets sent to recipient.

Here are the transformations I've found:

1. trailing line endings are replaced with a single line ending
This obviously was designed from HTML version of e-mail since there new line symbols doesn't mean much (unless inside a < pre > tag of course). As a fix I've kept this behavior only for HTML version of e-mail.

2. new lines, produced due m_DefineElement tag execution are removed
This is a bug, but since we only looked at HTML e-mail version where this wasn't noticeable we didn't knew this was happening at all.


To test the fixes I've made I've added "Send" button (visible only in debug mode) to e-mail events list. It just sends an e-mail event. I'm sure that nobody won't be against having this button also commited.
Beware, that not any e-mail event can be sent this way. For example e-mail events that rely on data to be preloaded by code which calls them would just be sent empty.
Steps To Reproduce:
Additional Information:
Attached Files: plain_text_email_line_ending_problem_fix.patch (7,249) 2012-09-14 11:10
http://tracker.in-portal.org/file_download.php?file_id=1802&type=bug
(0005178)
alex   
2012-09-14 11:12   
Will test all together later.
(0005179)
alex   
2012-09-14 11:13   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001395: Too aggressive line ending normalization in plain text e-mails





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1394 [In-Portal CMS] Data Management bug report always 2012-09-14 10:36 2012-09-14 10:40
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Ht5tv1PaT58/discussion
Change Log Message: Fixing multiple notices in Admin Console
Estimate Points: 1
Summary: Multiple notices discovered while developing System Log
Description: Fixing multiple notice types:

* Only variables should be assigned by reference
** function result is passed directly to array_shift function
** kApplication::recallObject result assigned by reference
* Undefined index: name - custom tag on shipping costs page
* Undefined index: mode - custom tag on shipping type groups page
* Undefined index: title - incorrect definition of "inp_edit_fck" block
* Undefined index: t - wrong template manipulation in adm_PrintSection tag
Steps To Reproduce:
Additional Information:
Attached Files: misc_notice_fixes_core.patch (6,518) 2012-09-14 10:36
http://tracker.in-portal.org/file_download.php?file_id=1800&type=bug
misc_notice_fixes_modules.patch (13,751) 2012-09-14 10:36
http://tracker.in-portal.org/file_download.php?file_id=1801&type=bug
(0005176)
alex   
2012-09-14 10:37   
Will test all together later.
(0005177)
alex   
2012-09-14 10:38   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001394: Multiple notices discovered while developing System Log





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1386 [In-Portal CMS] Data Management bug report always 2012-09-03 07:45 2012-09-14 10:21
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/xwFIs71lt38/discussion
Change Log Message: Fixes incorrect section physical template detection
Estimate Points: 1
Summary: Incorrect section/category physical template detection
Description: In-Portal has 2 types of sections/categories in "Structure & Data" section:

* physical - sections, that have 1 template on disk (TPL file) connected to them
* virtual - sections, that share single template (design template) with other sections (pure CMS pages, that just have different content, but identical layout)

Because of that physical sections actually have 2 urls:

* one, that matches TPL file location inside a theme
* other, that match associated section location inside "Structure & Data" section

If developer is required to perform specific actions based on physical template being used to render a page then method kApplication::getPhysicalTemplate can be used.

However I've recently found out, that virtual section has a symlink to a physical section this method sometimes failed to properly detect actual TPL file being used.
Steps To Reproduce:
Additional Information: This bug happens on all In-Portal 5.x versions (since symlink term was introduced), but kApplication::getPhysicalTemplate method only exists since 5.2.0-B1 version.
Attached Files: physical_template_detection_fix.patch (1,004) 2012-09-14 10:21
http://tracker.in-portal.org/file_download.php?file_id=1799&type=bug
(0005159)
alex   
2012-09-03 07:52   
Will test all together later.
(0005160)
alex   
2012-09-03 07:53   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001386: Incorrect section/category physical template detection





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1393 [In-Portal CMS] Admin Interfaces bug report always 2012-09-14 08:03 2012-09-14 08:10
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/1x7fFNQCuMY/discussion
Change Log Message: Fixes missing ID notice on some admin popup opening attempts
Estimate Points: 1
Summary: Random "Requested ID for prefix <prefix> not passed" notices
Description: While testing new "System Log" section I've been able to notice some error that were happening behind the scenes, e.g. in ajax requests or between page redirects.

Onе of such errors is happening, when attempt is made to query popup window size before actually opening. However it wasn't happening for all popups, but only ones that don't have adm_SetPopupSize tag in front of them.
Steps To Reproduce:
Additional Information:
Attached Files: missing_id_on_popup_open_core.patch (13,295) 2012-09-14 08:06
http://tracker.in-portal.org/file_download.php?file_id=1797&type=bug
missing_id_on_popup_open_modules.patch (17,067) 2012-09-14 08:06
http://tracker.in-portal.org/file_download.php?file_id=1798&type=bug
(0005174)
alex   
2012-09-14 08:07   
Will test all together later.
(0005175)
alex   
2012-09-14 08:09   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001393: Random "Requested ID for prefix not passed" notices





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1392 [In-Portal CMS] Front End bug report always 2012-09-13 06:00 2012-09-13 06:03
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/DVhNjWfkTkM/discussion
Change Log Message: Fixes fatal error on missing image display attempt
Estimate Points: 1
Summary: Resizing non-uploaded image caused fatal error
Description: When image upload isn't required then this means that there are no 100% guarantee that image will be there.

For such cases in template, where image will be displayed we:

* either display default image, e.g. <inp2:unit-prefix_Field name="ImageField" format="resize:100x100;default:img/no_image.gif"/>
* or place <inp2:m_if check="unit-prefix_Field" name="ImageField" db="db"> ... </inp2:m_if> around image display code

If none of mentioned above happens then horrible fatal error happens, that results in "The connection was reset" message being returned from a web server with no idea about what caused it.
Steps To Reproduce:
Additional Information:
Attached Files: missing_image_results_in_fatal_error.patch (469) 2012-09-13 06:00
http://tracker.in-portal.org/file_download.php?file_id=1796&type=bug
(0005172)
alex   
2012-09-13 06:03   
Will test all together later.
(0005173)
alex   
2012-09-13 06:03   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001392: Resizing non-uploaded image caused fatal error





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1391 [In-Portal CMS] Data Management bug report always 2012-09-11 11:23 2012-09-11 11:25
Reporter: erik Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-RC1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Ti7Jd33ep1g/discussion
Change Log Message: Fixes useless file renaming after upload
Estimate Points: 1
Summary: Excessive file name change on file upload
Description: When uploaded file name ends with "_{some number}", i.e. image_2.jpg, uploader excessively changes its name, by incrementing number in filename, even there is no same file name in the upload folder.

It is fixable by attached patch.
Steps To Reproduce:
Additional Information:
Attached Files: excessive_file_name_change_fix.patch (1,211) 2012-09-11 11:23
http://tracker.in-portal.org/file_download.php?file_id=1795&type=bug
(0005170)
alex   
2012-09-11 11:24   
Will test all together later.
(0005171)
alex   
2012-09-11 11:25   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001391: Excessive file name change on file upload Commit on behalf of Erik





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1390 [In-Portal CMS] Data Management bug report always 2012-09-10 12:59 2012-09-10 13:01
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Sa_zhWP8vo0/discussion
Change Log Message: Fixes notice about missing HTTP_ACCEPT_ENCODING
Estimate Points: 1
Summary: Undefined $_SERVER['HTTP_ACCEPT_ENCODING'] when from "run_event.php"
Description: In-Portal has a script, that allows to run any defined system event from command line as "root" (without permission check).
Since script is very powerful it's also password protected.

When executed on PHP 5.2.x server accepted encoding stored in $_SERVER['HTTP_ACCEPT_ENCODING'] is absent.
Steps To Reproduce:
Additional Information:
Attached Files: run_event_accept_encoding_fix.patch (3,262) 2012-09-10 12:59
http://tracker.in-portal.org/file_download.php?file_id=1794&type=bug
(0005168)
alex   
2012-09-10 13:01   
Will test all together later.
(0005169)
alex   
2012-09-10 13:01   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001390: Undefined $_SERVER['HTTP_ACCEPT_ENCODING'] when from "run_event.php"





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1389 [In-Portal CMS] Front End bug report always 2012-09-04 09:41 2012-09-04 09:43
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/C-ohuxNHFfc/discussion
Change Log Message: Fixes bug in c_ContentPageLink tag
Estimate Points: 1
Summary: Tag c_ContentPageLink builds broken link
Description: When you're printing a sitemap with links to all sections (pages) from a website on it you need to have solid tag to build a link to each page.
Right now there is tag <inp2:CategoryLink template='__default__'/> that does that.

Tag CategoryLink threats a section as a category and populates category_id in a link, but uses keeps template empty (if template parameter is set to "__default__") at the end.
Resulting link is valid because category url itself is a virtual template.

However if developer wants to rewrite some urls on the website and matches template name to an url he sees then nothing would happen, because as I've mentioned template name is empty.
Fortunately we have ContentPageLink that does the job. But over time (since nobody uses it) it broke. Both tags build same url at the end, however with ContentPageLink tag 't' parameter in rewrite listeners isn't empty.
Steps To Reproduce:
Additional Information:
Attached Files: contentpagelink_tag_fix.patch (698) 2012-09-04 09:41
http://tracker.in-portal.org/file_download.php?file_id=1793&type=bug
(0005166)
alex   
2012-09-04 09:43   
Will test all together later.
(0005167)
alex   
2012-09-04 09:43   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001389: Tag c_ContentPageLink builds broken link





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1388 [In-Portal CMS] Admin Interfaces bug report always 2012-09-04 06:02 2012-09-04 06:05
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/Xrb8f2-oCGg/discussion
Change Log Message: Fixing small z-index value problem in theme
Estimate Points: 1
Summary: Broken content mode when large z-index used in theme
Description: When large (over 100) z-index css values are used in theme, then all windows, that are opened in content mode are not visible. This happens because they have very small (99 - 102) z-index values.

Here are the affected places:

* content mode revision toolbar
* all modal windows opened in theme
* debugger report
Steps To Reproduce:
Additional Information:
Attached Files: zindex_theme_fix.patch (5,047) 2012-09-04 06:02
http://tracker.in-portal.org/file_download.php?file_id=1792&type=bug
(0005163)
alex   
2012-09-04 06:04   
I've add 1000000 (1 million) to all z-indexes being used and 1500000 to debugger report to ensure it's always on top of everything.
(0005164)
alex   
2012-09-04 06:05   
Will test all together later.
(0005165)
alex   
2012-09-04 06:05   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001388: Broken content mode when large z-index used in theme





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1387 [In-Portal CMS] Data Management bug report always 2012-09-04 05:51 2012-09-04 05:54
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/71-jew88oxI/discussion
Change Log Message: Fixes debugger report was opened at wrong scroll position
Estimate Points: 1
Summary: Debugger report is opened at wrong scroll position
Description: Debugger report usually is opened scrolled to top, but when fatal error happens it's automatically scrolled to show it. For some reason it now always thinks, that error has happened.
Steps To Reproduce:
Additional Information: Bug created during refactoring in @15130 revision (see http://tracker.in-portal.org/plugin.php?page=Source/view&id=18424).
Attached Files: wrong_scrolling_in_debugger_report_fix.patch (739) 2012-09-04 05:51
http://tracker.in-portal.org/file_download.php?file_id=1791&type=bug
(0005161)
alex   
2012-09-04 05:54   
Will test all together later.
(0005162)
alex   
2012-09-04 05:54   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001387: Debugger report is opened at wrong scroll position





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1385 [In-Portal CMS] Admin Interfaces bug report always 2012-09-02 10:31 2012-09-02 10:34
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/-j8BwZscpHs/discussion
Change Log Message: Fixes wrong filter for IP field in user list
Estimate Points: 1
Summary: Wrong grid filter for user's IP address
Description: User IP address is displayed with "date range" filter in users grid. I think, that we meant "like" filter to be used but due copy/paste error ended up with wrong filter.
Steps To Reproduce:
Additional Information:
Attached Files: wrong_ip_filter_fix.patch (1,612) 2012-09-02 10:31
http://tracker.in-portal.org/file_download.php?file_id=1790&type=bug
(0005157)
alex   
2012-09-02 10:34   
Will test all together later.
(0005158)
alex   
2012-09-02 10:34   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001385: Wrong grid filter for user's IP address





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1384 [Advanced] General task N/A 2012-08-21 12:49 2012-08-21 12:55
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 1.2.1-B1  
    Target Version: 1.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/lxUK4iZUhok/discussion
Change Log Message: Adds FormManager class
Estimate Points: 1
Summary: Make use of FormManager
Description: We've developed FormManager javascript class, that can be used to create forms, that are validated on the fly using ajax.
However it's only used in modern-store theme that isn't even released.

I'm proposing to use it also in "advanced" theme, that is widely used.
Steps To Reproduce:
Additional Information:
Attached Files: use_formmanager_in_advanced_theme.patch (103,287) 2012-08-21 12:53
http://tracker.in-portal.org/file_download.php?file_id=1789&type=bug
(0005154)
alex   
2012-08-21 12:50   
(edited on: 2012-08-21 12:56)
I've connected ajax validation to "My Profile" form, but this can be done in same way for all other forms if needed. I've also integrated changes from #0000629 task, that were made in Admin Console only.
(0005155)
alex   
2012-08-21 12:51   
Will test all together later.
(0005156)
alex   
2012-08-21 12:53   
Fix committed to [b]1.2.x branch[/b]. Commit Message: Fixes #0001384: Make use of FormManager





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1383 [In-Portal CMS] Admin Interfaces bug report always 2012-08-20 12:17 2012-08-20 12:20
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-B1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/gb-iJfz3zoE/discussion
Change Log Message: Fixes system setting page validation error detection
Estimate Points: 1
Summary: Incorrect setting page saving detection
Description: In 0001118 task we've added nice message, that is shown on configuration page when all settings were successfully saved.

However after using it a bit on my projects I've discovered, that message is shown if at least one of system settings, displayed on a page, was saved successfully.
Also on "Configuration -> Website -> Advanced" page, which is quite long, it's hard to see error in a setting value is is at the bottom of a page.

I'm proposing to:

1. display "Saved" message only when ALL system settings were saved without validation errors
2. scroll window/frame to first error on a page
Steps To Reproduce:
Additional Information:
Attached Files: system_setting_validation_fixes.patch (4,208) 2012-08-20 12:17
http://tracker.in-portal.org/file_download.php?file_id=1787&type=bug
(0005152)
alex   
2012-08-20 12:19   
Will test all together later.
(0005153)
alex   
2012-08-20 12:20   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001383: Incorrect setting page saving detection





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1382 [In-Portal CMS] Admin Interfaces bug report always 2012-08-20 10:30 2012-08-20 10:41
Reporter: phil Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/c6bV69o6Syw/discussion
Change Log Message: Fixes warning on configuration page
Estimate Points: 1
Summary: Error On Advanced Configuration Save
Description: Steps to reproduce:

1. go to "Configuration > Website > Advanced"
2. click Save:
3. see following exception:

Exception: Query method is called in class ConfigurationItem for prefix conf in /www/520/core/kernel/db/dbitem.php on line 1476
Steps To Reproduce:
Additional Information:
Attached Files: warning_on_setting_save_core.patch (2,506) 2012-08-20 10:39
http://tracker.in-portal.org/file_download.php?file_id=1785&type=bug
warning_on_setting_save_modules.patch (2,927) 2012-08-20 10:39
http://tracker.in-portal.org/file_download.php?file_id=1786&type=bug
(0005150)
alex   
2012-08-20 10:40   
Will test all together later.
(0005151)
alex   
2012-08-20 10:41   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001382: Error On Advanced Configuration Save





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1381 [In-Portal CMS] Database task always 2012-08-20 10:23 2012-08-20 10:25
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/8SfgR2JJRyk/discussion
Change Log Message: Added more info to item validation error message
Estimate Points: 1
Summary: Adding more info to item validation error message
Description: When validation of an item fails In-Portal triggers a notice with following text and adds detailed error list in a debugger report:

Notice (#1): Validation failed in prefix - conf, FieldErrors follow (look at items with "pseudo" key set)
You may ignore this notice if submitted data really has a validation error in ...\core\kernel\utility\validator.php on line 120


If you're editing only 1 record at a time (e.g. on editing page), then this is normal. But when multiple items are changed in database (e.g. 20), and only several of them have validation errors, then it's hard to determine which ones exactly.


I'm proposing to display item's ID and Title Field value as a help in solving this item identification problem. With proposed changed message now will look as follows:

Notice (#1): Validation failed in prefix - conf (VariableId: 55; VariableName: Require_AdminSSL), FieldErrors follow (look at items with "pseudo" key set)
You may ignore this notice if submitted data really has a validation error in ...\core\kernel\utility\validator.php on line 120
Steps To Reproduce:
Additional Information:
Attached Files: more_info_about_validated_item.patch (1,039) 2012-08-20 10:23
http://tracker.in-portal.org/file_download.php?file_id=1784&type=bug
(0005148)
alex   
2012-08-20 10:25   
Will test all together later.
(0005149)
alex   
2012-08-20 10:25   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001381: Adding more info to item validation error message





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1380 [In-Portal CMS] Data Management bug report always 2012-08-20 08:54 2012-08-20 08:58
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/e97EJPFUtrM/discussion
Change Log Message: Fixes notice on every page with debugger
Estimate Points: 1
Summary: Notice on every page with debugger
Description: In 5.2.0 version we've made changes related to scheduled tasks for cases, when they are executed after page is displayed to user (see 0001339).

However as a side effect a notice was happening on every page with debugger, but after the debugger report was generated. This was nobody was able to see that notice.
Steps To Reproduce:
Additional Information:
Attached Files: notice_on_every_page_with_debugger_fix.patch (344) 2012-08-20 08:54
http://tracker.in-portal.org/file_download.php?file_id=1783&type=bug
(0005146)
alex   
2012-08-20 08:58   
Will test all together later.
(0005147)
alex   
2012-08-20 08:58   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001380: Notice on every page with debugger





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1379 [In-Portal CMS] Data Management bug report always 2012-08-20 08:39 2012-08-20 08:39
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference:
Change Log Message:
Estimate Points: 2
Summary: Submitting system logs to Intechnic servers
Description: Addon for submitting data collected in 0001003 to Intechnic Servers.

Add following columns to SystemLog table:
-----------------------------------------
* Submitted (yes/no) - was this log record submitted to www.in-portal.org website for analysis
* SubmittedOn (date/time) - when this log record was submitted (empty if wasn't submitted yet)

New step will be added during installation (maybe on final stages, after configuration page)
------------------------------------------
On this step user will be faced with a question about "In-Portal Customer Experience" program and the following options:

Event log submission method:
* manual
* automatic (daily)
* automatic (weekly)
* automatic (monthly)

This should be a separate step, since user MUST notice what we are asking here.

There also will be "Submit To Developers" toolbar button (in System Log section) that allows to submit all previously not submitted data to www.in-portal.org website.
Steps To Reproduce:
Additional Information: During submission to www.in-portal.org website "127.0.0.1" in $_SERVER['REMOTE_ADDR'] will be replaced with IP address, used during data submission.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1378 [In-Portal CMS] Front End bug report always 2012-08-19 14:11 2012-08-19 14:13
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ZUhDmAi_kXY/discussion
Change Log Message: Fixes warnings on sequential login attempts
Estimate Points: 1
Summary: Sequential user login attempts result in a notice
Description: Steps to reproduce:

1. Enable mod-rewrite.
2. Try pressing "Login" button (on a login form) twice in a row without entering any user credentials.
3. You should end with "/?env=u-\-2----" at the end of url.
3. Try to login with valid credentials.
5. Warnings below are shown.

Notice (#1): Undefined index: pass in ...\core\units\helpers\user_helper.php on line 426
Warning (#2): implode() [function.implode]: Invalid arguments passed in ...\core\units\helpers\user_helper.php on line 426
Steps To Reproduce:
Additional Information:
Attached Files: warnings_on_normal_user_login_fix.patch (550) 2012-08-19 14:11
http://tracker.in-portal.org/file_download.php?file_id=1782&type=bug
(0005143)
alex   
2012-08-19 14:12   
Will test all together later.
(0005144)
alex   
2012-08-19 14:13   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001378: Sequential user login attempts result in a notice





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1377 [In-Portal CMS] Front End bug report always 2012-08-19 12:56 2012-08-19 12:58
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ckOAhWLkhrw/discussion
Change Log Message: Fixing notice after user performed a login
Estimate Points: 1
Summary: Notice after user completes a login procedure
Description: I see following notice after I've performed a login on Front-End:
Only variables should be passed by reference in ...\core\units\helpers\user_helper.php on line 164
Steps To Reproduce:
Additional Information:
Attached Files: notice_on_user_login_fix.patch (696) 2012-08-19 12:56
http://tracker.in-portal.org/file_download.php?file_id=1781&type=bug
(0005141)
alex   
2012-08-19 12:58   
Will test all together later.
(0005142)
alex   
2012-08-19 12:58   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001377: Notice after user completes a login procedure





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1376 [In-Portal CMS] Data Management refactoring N/A 2012-08-17 10:06 2012-08-17 10:09
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/EMgfT82cF2s/discussion
Change Log Message: Add kUtil::generateId method for random code generation
Estimate Points: 1
Summary: Single place for random code generation
Description: In-Portal has interesting method, that is used to generated random codes. For example it's used for session id generation.

Because this method is located in Session class it can't be used in other places due it's visibility. I'm proposing to move this method to kUtil class.
Steps To Reproduce:
Additional Information:
Attached Files: centralize_random_code_generation.patch (2,544) 2012-08-17 10:06
http://tracker.in-portal.org/file_download.php?file_id=1780&type=bug
(0005139)
alex   
2012-08-17 10:08   
Will test all together later.
(0005140)
alex   
2012-08-17 10:09   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001376: Single place for random code generation





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1375 [In-Portal CMS] Data Management bug report always 2012-08-17 09:21 2012-08-17 09:27
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/xJWNNF-1qec/discussion
Change Log Message: Fixes session cookies sent in PHP CLI
Estimate Points: 1
Summary: Session cookies are sent out from PHP CLI
Description: Session-related cookies (sid, cookies_on, etc.) are sent, when session must not be used.

This can be detected only, when /tools/cron.php is executed from PHP CLI and "Cannot modify header information - headers already sent by ..." warning is raised.
Steps To Reproduce:
Additional Information:
Attached Files: session_get_mode_in_php_cli.patch (439) 2012-08-17 09:21
http://tracker.in-portal.org/file_download.php?file_id=1779&type=bug
(0005137)
alex   
2012-08-17 09:26   
Will test all together later.
(0005138)
alex   
2012-08-17 09:27   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001375: Session cookies are sent out from PHP CLI





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1371 [In-Portal CMS] Data Management refactoring N/A 2012-08-07 05:57 2012-08-15 11:47
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.3.0  
Reference: https://groups.google.com/d/topic/in-portal-dev/qfiJKIW0ARM/discussion
Change Log Message: Change date/time processing code to support new approach
Estimate Points: 2
Summary: Replace "AdoDb Date Time Library" with PHP build-in DateTime class
Description: Replace usages of adodb_* and strtotime functions with DateTime class, that is available since PHP 5.2.x.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1372 [In-Portal CMS] Data Management bug report always 2012-08-07 06:00 2012-08-15 11:47
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-dev/qfiJKIW0ARM/discussion
Change Log Message: Add function for working DateTime class based on given timestamp
Estimate Points: 1
Summary: Add function for creating DateTime class from timestamp in PHP 5.2.x
Description: Add ability to easily create DateTime object from a given timestamp without breaking it's timezone.
Steps To Reproduce:
Additional Information:
Attached Files: create_datetime_object_from_timestamp_feat.patch (1,544) 2012-08-07 06:00
http://tracker.in-portal.org/file_download.php?file_id=1775&type=bug
create_datetime_object_to_timestamp_feat.patch (752) 2012-08-11 11:28
http://tracker.in-portal.org/file_download.php?file_id=1776&type=bug
(0005130)
alex   
2012-08-07 06:02   
Will test all together later.
(0005131)
alex   
2012-08-07 06:03   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001372: Add function for creating DateTime class from timestamp in PHP 5.2.x
(0005132)
alex   
2012-08-11 11:29   
Patch "create_datetime_object_to_timestamp_feat.patch" creates opposite feature: getting timestamp from DateTime class instance with check for PHP version (in PHP 5.3 there is method already).





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1373 [In-Portal CMS] Data Management bug report always 2012-08-15 06:04 2012-08-15 06:07
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/iQvoSuK7sPc/discussion
Change Log Message: Fixing GET parameter processing by kCurlHelper class
Estimate Points: 1
Summary: Class kCurlHelper ignores GET parameters
Description: In following code example parameters set through setRequestData method would be ignored:

$curl_helper = $this->Application->recallObject('CurlHelper');
/* @var $curl_helper kCurlHelper */

$curl_helper->setRequestData(Array ('param1' => 'value1'));
$response = $curl_helper->Send('http://www.twitter.com');
Steps To Reproduce:
Additional Information:
Attached Files: curl_ignoring_get_request_parameters_fix.patch (668) 2012-08-15 06:04
http://tracker.in-portal.org/file_download.php?file_id=1777&type=bug
(0005133)
alex   
2012-08-15 06:07   
Will test all together later.
(0005134)
alex   
2012-08-15 06:07   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001373: Class kCurlHelper ignores GET parameters





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1367 [In-Portal CMS] Admin Interfaces bug report always 2012-07-23 06:33 2012-07-27 11:09
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.2.0-RC1  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/ISKS_gdvjAo/discussion
Change Log Message: Fixes incorrect disabled toolbar button icons in sprites
Estimate Points: 1
Summary: Incorrect disabled toolbar button images in sprites
Description: I've found out, that disabled toolbar button images for at least "New Link" and "New Article" buttons are incorrect in toolbar buttons sprites, that are shipped along with In-Link and In-News modules.

Need to investigate if this problem is happening for other sprite images as well and fix it.
Steps To Reproduce:
Additional Information: Corresponding IB task: 35237
Attached Files: in-portal-520-sprites1.zip (207,712) 2012-07-27 10:00
http://tracker.in-portal.org/file_download.php?file_id=1774&type=bug
(0005128)
alex   
2012-07-27 11:04   
Will test all together later.
(0005129)
alex   
2012-07-27 11:09   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001367: Incorrect disabled toolbar button images in sprites





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1370 [In-Portal CMS] Front End bug report always 2012-07-26 13:27 2012-07-26 13:29
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 5.0.0  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 5.2.1-B1  
    Target Version: 5.2.1  
Reference: https://groups.google.com/d/topic/in-portal-bugs/5NwzlHM8Gas/discussion
Change Log Message: Fixing broken JPEG images are not being resized at all problem
Estimate Points: 1
Summary: Image resize not working in some cases
Description: In most cases images are sized properly, but image I've attached didn't resize and is producing following errors in debugger:

Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: gd-jpeg, libjpeg: recoverable error: Corrupt JPEG data: 359094 extraneous bytes before marker 0xd9 in w:\in-portal\core\units\helpers\image_helper.php on line 188
Warning: imagecreatefromjpeg() [function.imagecreatefromjpeg]: '.../system/images/Buddy on the porch.jpeg' is not a valid JPEG file in w:\in-portal\core\units\helpers\image_helper.php on line 188

At first I though image is broken, but it'd GD & libjpeg thinks what way. I can open that image on my PC using any program, even Photoshop.

Line, where error is happening says:
$src_image_rs = imagecreatefromjpeg($src_image);

I thought that I need to update JPEG library, but I already have latest version 6b from 1998 year.
Steps To Reproduce:
Additional Information:
Attached Files: resizing_of_corrupted_jpeg_images_fix.patch (386) 2012-07-26 13:27
http://tracker.in-portal.org/file_download.php?file_id=1773&type=bug
(0005126)
alex   
2012-07-26 13:28   
Will test all together later.
(0005127)
alex   
2012-07-26 13:29   
Fix committed to [b]5.2.x branch[/b]. Commit Message: Fixes #0001370: Image resize not working in some cases





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1125 [In-Portal CMS] Install / Upgrages task N/A 2011-09-20 11:30 2012-07-25 05:39
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.3  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.2.1  
Reference:
Change Log Message:
Estimate Points: 1
Summary: Prepare 5.2.0 release
Description: Prepare 5.2.0 release
Steps To Reproduce:
Additional Information:
Attached Files: differencies_between_clean_install_and_upgrade_520b2_fix.patch (4,157) 2012-03-12 06:41
http://tracker.in-portal.org/file_download.php?file_id=1549&type=bug
(0004627)
alex   
2012-05-12 15:48   
Actually @14588 contained a fix to kUploadFormatter::GetFormatted, where $force_direct_links parameter wasn't given to method in parent class resulting 'full_url' format to return broken image for 'PrimaryImage', 'Image1' and other virtual fields for users, categories and other category items.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
268 [In-Portal CMS] Optimization task always 2009-09-04 12:05 2012-07-25 05:39
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 5.2.1  
Reference:
Change Log Message:
Estimate Points: 3
Summary: Code Cleanup in 5.2.x branch
Description: This an ongoing task for Code cleanup in the whole system in 5.2.x branch.

---------------
1. kModRewriteHelper and kUrlManager both works with urls and get some data from kApplication class too. Need to unify url build/parse process (maybe by creating kiUrlProcessor interface, that will be implemented in PlainUrlProcessor and RewriteUrlProcessor classes).

2. Temp Handler class optimization:
- implement class using Collection pattern (like tests are collected in phpUnit) and create Clone, Delete, etc. methods for the class.
- this way operations will be single-item based, not table-based as right now.
- This of course will result separate sqls for subitem quering based on individual parent, but that's small price to pay to have correctly organized class hierarchy

3. 0001224 - Email event usage refactoring (part 1)
- create kEmail class with following public methods:
-- findEvent($name, $type)
-- setParams($params)
-- send()
- make $this->sender refer to kEmailSendingHelper class instance for easy access across all methods
- move existing code from EmailEventsEventHandler into new kEmail class
- replace OnEmailEvent event sending with new kEmail class usage

4. Email event refactoring (part 2)
- replace tons of "switch by RecipientType (to, cc, bcc) field" into polymorphism
Steps To Reproduce:
Additional Information: Users:

0001031: User management internals refactoring
0000964: Improvements to user Login field
0000778: Improvements to Create User & Admin form in Admin
0000948: Change in "Forgot Password" logic

Data Validation:

0000270: "Form Configuration" for Add/Edit in Admin Console
0000271: Redesign "Data Validation" Engine
https://groups.google.com/forum/#!topic/in-portal-dev/cfhRH6VUxaE/discussion
Attached Files: scope_kw_core.patch (410,800) 2011-10-04 04:32
http://tracker.in-portal.org/file_download.php?file_id=1193&type=bug
scope_kw_modules.patch (120,716) 2011-10-04 04:32
http://tracker.in-portal.org/file_download.php?file_id=1194&type=bug
removing_references_in_events_core.patch (267,180) 2012-03-03 12:37
http://tracker.in-portal.org/file_download.php?file_id=1527&type=bug
removing_references_in_events_modules.patch (182,174) 2012-03-03 13:01
http://tracker.in-portal.org/file_download.php?file_id=1528&type=bug
removing_references_in_makeclass_recallobject_core.patch (294,978) 2012-03-04 02:05
http://tracker.in-portal.org/file_download.php?file_id=1529&type=bug
removing_references_in_makeclass_recallobject_modules.patch (210,600) 2012-03-04 02:05
http://tracker.in-portal.org/file_download.php?file_id=1530&type=bug
removing_references_in_parent_event_core.patch (3,293) 2012-03-04 02:57
http://tracker.in-portal.org/file_download.php?file_id=1531&type=bug
removing_references_in_event_getobject_core.patch (95,682) 2012-03-04 03:03
http://tracker.in-portal.org/file_download.php?file_id=1532&type=bug
removing_references_in_event_getobject_modules.patch (84,935) 2012-03-04 03:03
http://tracker.in-portal.org/file_download.php?file_id=1533&type=bug
removing_references_in_tp_getobject_core.patch (44,335) 2012-03-04 03:24
http://tracker.in-portal.org/file_download.php?file_id=1534&type=bug
removing_references_in_tp_getobject_modules.patch (49,194) 2012-03-04 03:25
http://tracker.in-portal.org/file_download.php?file_id=1535&type=bug
use_simplexml_for_internal_xml_parsing.patch (23,360) 2012-03-04 05:50
http://tracker.in-portal.org/file_download.php?file_id=1536&type=bug
(0002970)
alex   
2010-11-07 12:48   
(edited on: 2010-12-28 11:29)
----------- kBase class ----------- - moved up "Conn" property to "kBase" class, since it is declared in most of class descendants anyway - hidden "kBase::Application" and "kBase::Conn" properties, so only descendant class could access them - added hidden "kBase::prefixSpecial" property to cache prefix special, instead of creating it on the fly as for now - removed "kBase::OriginalParams" property - removed "kBase::getProperty", "kBase::setProperty" methods ------------- kDBBase class ------------- - class marked as abstract - hidden "kDBBase::SelectClause" property in favor of already existing "kDBBase::SetSelectSQL" and "kDBBase::GetSelectSQL" access methods - hidden "kDBBase::Fields" property in favor of already existing "kDBBase::GetFieldOptions" and "kDBBase:SetFieldOptions" access methods - added "kDBBase::isField" method for checking if given field is declared in this object (because of hidden "kDBBase::Fields" property) - added "kDBBase::getFields" method (because of hidden "kDBBase::Fields" property) - added "kDBBase::GetFieldOption" and "kDBBase::SetFieldOption" methods for easy access to single option from unit config field declaration - hidden "kDBBase::customFields" property in favor of "kDBBase::setCustomFields" (existing) and "kDBBase::getCustomFields" (added) access methods - hidden "kDBBase::VirtualFields" property in favor of "kDBBase::setVirtualFields" (existing) and "kDBBase::getVirtualFields" (added) access methods - added "kDBBase::isVirtualField" method for checking if given virtual field is declared in this object (because of hidden "kDBBase::VirtualFields" property) - hidden "kDBBase::CalculatedFields" property in favor of "kDBBase::setCalculatedFields" (added), "kDBBase::addCalculatedField" (added) and "kDBBase::getCalculatedFields" (existing) access methods - added "kDBBase::isCalculatedField" method for checking if given virtual field is also a calculated field (because of hidden "kDBBase::CalculatedFields" property) - hidden "kDBBase::AggregatedCalculatedFields" property in favor of "kDBBase::setAggregatedCalculatedFields" (added) and "kDBBase::getCalculatedFields" (existing) access methods - added hidden "kDBBase::populateMultiLangFields" property to store object's initial ML status (formerly "$populate_ml_fields" parameter of "kDBItem::SetDefaultValues" method) - replaced "kDBBase::mode" property with already existing method "kDBBase::IsTempMode" usage - hidden "kDBBase::replaceModePrefix" and "kDBBase::addCalculatedFields" methods - removed "kDBBase::SetIDField" and "kDBBase::setTableName" methods, since properties "kDBBase::IDField" and "kDBBase::TableName" they are using has public access level anyway - added optional "$populate_ml_fields" parameter to "kDBBase::Configure" method (moved from "kDBItem::SetDefaultValues" method) - changed "kDBBase::Configure" method to support repeated invocation for repeated object configuration - added hidden "kDBBase::getFieldsBySpecial" method to unify retrieving values of special-based unit options, like "CalculatedFields", "ListSortings", etc. - changed "kDBBase::SetFieldOptions" and "kDBBase::GetFieldOptions" methods to support processing of virtual fields - made abstract "kDBBase::GetDBField", "kDBBase::HasField", "kDBBase::GetFieldValues", "kDBBase::isLoaded" and "kDBBase::GetCol" methods - hidden "kDBBase::prepareConfigOptions", "kDBBase::escapeField", "kDBBase::_replaceLanguageId" and "kDBBase::PrepareFieldOptions" methods - merged "kDBBase::PrepareOptions" method into "kDBBase::prepareConfigOptions" method ------------- kDBList class ------------- - renamed constants related to list processing (*_FILTER, FLT_*) to kDBList::*, e.g. WHERE_FILTER to kDBList::WHERE_FILTER - removed duplicate code from "kCatDBTagProcessor::CatalogItemCount" method (code was copied from "kDBList::GetRecordsCount" method) - method "kDBTagProcessor::groupRecords" encapsulated into "kDBList" class, since it only operates on it's properties - hidden "kDBList::Totals" and "kDBList::TotalsCalculated" properties in favor of already existing "kDBList::getTotal" and "kDBList::GetFormattedTotal" access methods - hidden "kDBList::OrderFields" property in favor of already existing "kDBList::AddOrderField", "kDBList::ClearOrderFields", "kDBList::GetOrderField" and "kDBList::GetOrderDirection" access methods - hidden "kDBList::RecordsCount" property in favor of existing "kDBList::GetRecordsCount" access method - merged "kDBList::GetNoFilterCount" method into "kDBList::GetRecordsCount" method because of similar nature - hidden "kDBList::NoFilterCount" property in favor of modified "kDBList::GetRecordsCount" access method - hidden "kDBList::SelectedCount" property in favor of added "kDBList::GetSelectedCount" access method - hidden "kDBList::CurrentIndex" property in favor of already existing "kDBList::getCurrentRecord", "kDBList::GoIndex", "kDBList::GoFirst", "kDBList::GoNext", "kDBList::GoPrev" and "kDBList::EOL" methods - hidden "kDBList::PerPage" property in favor of added "kDBList::GetPerPage" access method - hidden "kDBList::TotalPages" property in favor of already existing "kDBList::GetTotalPages" access method - hidden "kDBList::Page" property in favor of added "kDBList::GetPage" access method - hidden "kDBList::Offset" property in favor of added "kDBList::SetOffset" and "kDBList::GetOffset" access methods - hidden "kDBList::WhereFilter", "kDBList::HavingFilter" and "kDBList::AggregateFilter" properties in favor of already existing "kDBList::addFilter", "kDBList::getFilter" and "kDBList::removeFilter" access methods - hidden "kDBList::GroupByFields" in favor of already existing "kDBList::AddGroupByField" and "kDBList::RemoveGroupByField" access methods - hidden "kDBList::Queried" property in favor of already existing "kDBList::Query" and "kDBList::isLoaded" methods - hidden "kDBList::Counted" property in favor of new "kDBList::reset" and "kDBList:isCounted" methods - added "kDBList::reset" method, which handles "requery" parameter usage (reset counted status, clear filters [NEW], clear order fields) - hidden "kDBList::mainList" property in favor of new "kDBList::isMainList" access method (this way property made readonly) - added "kDBList::becameMain" method to allow setting list as main (one way, no way remove such mark!) - hidden "kDBList::CountRecs" method, since it is automatically called, when needed by "kDBList::GetRecordsCount" and "kDBList::GetTotalPages" methods - hidden "kDBList::CalculateTotals" method, since it is automatically called, when needed by "kDBList::getTotal" method - hidden "kDBList::extractCalculatedFields" method, since it's automatically called, when needed by "kDBList::GetWhereClause" and "kDBList::GetHavingClause" methods - removed unused "kDBList::SetWhereClause" method - hidden "kDBList::GetWhereClause", "kDBList::GetHavingClause", "kDBList::GetGroupClause" and "kDBList::GetOrderClause" methods to encapsulate database query building logic - changed "kDBList::GetFieldValues" method to properly return current record data by reference - changed "kDBList::getCurrentRecord" method to properly return "false" value by reference ------------- kDBItem class ------------- - hidden "kDBItem::FieldValues" property in favor of already existing "kDBBase::SetDBField" and "kDBBase::GetDBField" access methods - hidden "kDBItem::DirtyFieldValues" property in favor of already existing "kDBItem::SetDirtyField" and "kDBItem::GetDirtyField" access methods - hidden "kDBItem::OriginalFieldValues" property in favor of already existing "kDBItem::SetOriginalField" and "kDBItem::GetOriginalField" access methods - hidden "kDBItem::FieldErrors" property in favor of "kDBItem::SetError" (existing), "kDBItem::GetErrorPseudo" (added), "kDBItem::HasErrors" (existing), "kDBItem::GetErrorMsg" (existing), "kDBItem::GetFieldErrors" (added) and "kDBItem::RemoveError" (added) methods - hidden "kDBItem::ErrorMsgs" property in favor of already existing "kDBItem::SetError" and "kDBItem::GetErrorMsg" access methods - hidden "kDBItem::Loaded" property in favor of "kDBItem::isLoaded" (existing) and "kDBItem::setLoaded" (added) access methods - hidden "kDBItem::ID" property in favor of already existing "kDBItem::SetID" and "kDBItem::GetID" access methods - added "kDBItem::RemoveError", "kDBItem::GetErrorPseudo" and "kDBItem::GetFieldErrors" methods (because of hidden "kDBItem::FieldErrors" property) - hidden "kDBItem::GetKeyClause", "kDBItem::raiseEvent", "kDBItem::LogChanges", "kDBItem::getParentId" and "kDBItem::generateID" methods, since they are used only internally - changed "kDBItem::GetSelectSQL" method to match with parent class method declaration - hidden "kDBItem::CustomValidation" method, since it is designed to be called by "kDBItem::ValidateField" method from "kDBItem" class descendant classes only - changed declaration of "kDBItem::HasErrors" method to make "$skip_fields" parameter optional - hidden "kDBItem::ValidateUnique" and "kDBItem::ValidateRange" methods, since they are called by "kDBItem::ValidateField" method only - changed "kDBItem::GetErrorMsg" method to use newly added "kDBItem::GetErrorPseudo" method instead of duplicating it's code locally - changed "kDBItem::isRequired" method to use "isset" instead of "getArrayValue" (+performance boost) ------------------- kEventHandler class ------------------- - hidden "kEventHandler::eventMethods" property in favor of "kEventHandler::processEvent" access method - hidden "kEventHandler::permMapping" property in favor of "kEventHandler::CheckPermission" access method - hidden "kEventHandler::mapEvents", "kEventHandler::mapPermissions" and "kEventHandler::prepareObject" methods, since they are expected to be called by descendant classes only - hidden "kEventHandler::OnBuild", "kEventHandler::OnGoBack" and "kEventHandler::OnAfterConfigRead" methods, since all events in event handler are not directly accessible (only via "kEventHandler::processEvent" method) ------------------- kEventManager class ------------------- - added implementation of kiCacheable interface (cached data: build events, hooks, agents) - extracted new "kHookManager" class for hook processing from "kEventManager" class (delegate method "kEventManager:registerHook") - extracted new "kAgentManager" class for agent processing from "kEventManager" class (delegate methods "kEventManager::getAgents", "kEventManager::registerAgent", "kEventManager::runAgents" and "kEventManager::runAgent") - extracted new "kRequestManager" class for event from request processing from "kEventManager" class (delegate methods "kEventManager::ProcessRequest", "kEventManager::openerStackPush" and "kEventManager::openerStackChange") - renamed "kEventManager::getRegularEvents" into "kEventManager::getAgents" - renamed "kEventManager::RunRegularEvents" method into "kEventManager::runAgents" - renamed "kEventManager::registerRegularEvent" method into "kEventManager::registerAgent" ------------- NParser class ------------- - added ParserException exception class to handle errors during template compilation process - changed error processing during template compilation to use exception model instead of replacing current error handler to do it ------------- Session class ------------- - moved class "SessionStorage" and "InpSessionStorage" declarations into separate PHP files to conform with "one class - one file" rule - added "SessionStorage::setSession" method, which removed need of passing $session in each SessionStorage class method call - removed "SessionStorage::setSessionTimeout" method, because now SessionStorage class has direct access to Session class instance and could ask it, when needed - renamed session mode constants (sm*) to "Session::sm*), e.g. "smGET_ONLY" to "Session::smGET_ONLY" -------------- Debugger class -------------- - moved functions identical to "kUtil" class functions (from "Debugger" class) to new "DebuggerUtil" class - changed default value for DBG_IGNORE_STRICT_ERRORS debugger option to show E_STRICT php errors, since most of code, raising them was already fixed - added error/notice/warning number near each error, allowing for easy error finding in debugger report, when DBG_SQL_PROFILE option is enabled - added exception handler to "Debugger" class - moved debugger short report to debugger report, when opened (useful, when it's not initially visible, e.g. in grids or editing forms in admin console) [NEW] - not shown debugger, when DBG_RAISE_ON_WARNINGS is enabled during installation process ------------ kEvent class ------------ - renamed event status constants from "er*" into "kEvent::er*" (e.g. erSUCCESS to kEvent::erSUCCESS) - hidden "kEvent::Prefix_Special" property in favor of already existing "kEvent::getPrefixSpecial" method - hidden "kEvent::redirect_params" property in favor of new "kEvent::setRedirectParams" access method - renamed "kEvent::redirect_params" property into "kEvent::redirectParams" property to comply with naming standards - renamed "kEvent::redirect_script" property into "kEvent::redirectScript" property to comply with naming standards - hidden "kEvent::redirectParams" property in favor of "kEvent::getRedirectParams" (added), "kEvent::getRedirectParam" (added), "kEvent::SetRedirectParam" (existing) and "kEvent::setRedirectParams" (added) access methods - hidden "kEvent::specificParams" property in favor of already existing "kEvent::setEventParam" and "kEvent::getEventParam" access methods - hidden "kEvent::pseudoClass" property in favor of already existing "kEvent::setPseudoClass" access method - changed "kEvent::getPrefixSpecial" method to use parent class method, when possible (duplicate code removed) - added "kEvent::__toString" method for retrieving string representation of kEvent class instance - added "kEvent::copyFrom" method to copy data between current and given event (useful for sub-event processing) -------------- kFactory class -------------- - added implementation of kiCacheable interface (cached data: class names, file names, class dependencies) - added "$arguments" parameter to "kFactory::getObject" method to support passing additional parameters to instanced class constructor - added "$arguments" parameter to "kApplication::recallObject" (calls "kFactory::getObject") to support passing additional parameters to instanced class constructor - moved build event creation and running to "kEventManager::runBuildEvent" method (instead of "kEventManager::getBuildEvent" and "kApplication::HandleEvent" method calls) - removed "kFactory::getObjectP", because now build-in "ReflectionClass" (PHP 5.2+) class is used for passing additional parameters to instanced class constructor - removed "kApplication::recallObjectP", because called method "kFactory::getObjectP" was also removed - added "$arguments" parameter to "kApplication::makeClass" (calls "kFactory::makeClass") to support passing additional parameters to instanced class constructor - added "kFactory::unregisterClass" method (called by "kApplication::unregisterClass" method) for allowing to undo class registration, made by "kFactory::registerClass" - simplified "kFactory::registerDependency" method, since it was checking for 2 conditions, while one of them was always "true" - removed "makeClass" methods from various classes, who have additional parameters in their constructors, since now it's handled by new version of "kFactory::makeClass" method ---------------- kHTTPQuery class ---------------- - added "kHTTPQuery::discoveredUnits" property (former "kEventManager::queryMaps" property) - added "kHTTPQuery::getDiscoveredUnits" method - added "kHTTPQuery::discoverUnit" method (former "kEventManager::setQueryMap" method) - added "kHTTPQuery::getQueryString" method (former "kEventManager::getQueryMap" method) ----------------------- kUnitConfigReader class ----------------------- - added implementation of kiCacheable interface (cached data: unit config file locations) - changed data caching to get/set data via provided by kiCacheable interface methods (no private attributes are used as before) - added "kUnitConfigReader::preloadConfigVars" method to logically divide configuration variable preloading from overall cache saving method - added debugger message, that cache was rebuild during current page display - divided "kUnitConfigReader::parseConfig" method into separate methods: "kUnitConfigReader::parseClasses", "kUnitConfigReader::parseAgents", "kUnitConfigReader::parseHooks" and "kUnitConfigReader::parseAggregatedTags" - changed typecasting into array in "kUnitConfigReader::parseClasses" method to be performed in more native way (could be a performance boost) - fixed "kUnitConfigReader::ValidateConfig" to show debugger, when unit config validation was made (worked before, but was broken at some point) ----------------- kCurlHelper class ----------------- - hidden "kCurlHelper::connectionID" and "kCurlHelper::logFilePointer" properties - added hidden "kCurlHelper::requestMethod" property with "kCurlHelper::SetRequestMethod" access method - renamed "kCurlHelper::postData" property into "kCurlHelper::requestData" property - hidden "kCurlHelper::requestData" property in favor of "kCurlHelper::SetPostData" (existing) and "kCurlHelper::SetRequestData" (added) methods - hidden "kCurlHelper::requestHeaders" property in favor of already existing "kCurlHelper::SetHeaders" access method - hidden "kCurlHelper::responceHeaders" property in favor of already existing "kCurlHelper::ParseHeader" method - hidden "kCurlHelper::options" property in favor of already existing "kCurlHelper::setOptions" access method - hidden "kCurlHelper::_resetSettings", "kCurlHelper::prepareOptions", "kCurlHelper::applyOptions", "kCurlHelper::ParseHeader" and "kCurlHelper::prepareHeaders" methods - added "kCurlHelper::SetRequestMethod" method to set curl request type to GET or POST - changed "kCurlHelper::prepareHeaders" method to support headers without distinct value (e.g. "Connection Keep-Alive" vs "Host: www.site.com") -------------------------- kMultiLanguageHelper class -------------------------- - hidden "kMultiLanguageHelper::languageCount" property in favor of added "kMultiLanguageHelper::getLanguages" method - hidden "kMultiLanguageHelper::languagesIDs" property in favor of added "kMultiLanguageHelper::getLanguages" method - added "kMultiLanguageHelper::getLanguages" method, that returns all language ids, that have/should have lN_FieldName columns created in other tables - removed "kMultiLanguageHelper::getLanguageCount" method in favor of added "kMultiLanguageHelper::getLanguages" method - hidden "kMultiLanguageHelper::LanguageFound" method in favor of added "kMultiLanguageHelper::getLanguages" method ------------------ file "globals.php" ------------------ - renamed 99% of global functions in "globals.php" file into new static class "kUtil" members with their names intact (although some were renamed and will be noted below) - renamed "print_pre" function into "kUtil::print_r" static method - renamed "array_merge_recursive2" function into "kUtil::array_merge_recursive" static method - renamed constant "POUND_TO_KG" into "kUtil::POUND_TO_KG" - not changed "getArrayValue" function due inability to pass undetermined parameter count to it - renamed "parse_portal_ini" function into "kUtil::parseConfig" static method - added "kUtil::getConfigVars" method to retrieve parsed content of "config.php" file (also removed global variable "$vars" used for that purpose) - renamed function "k4_include_once" into "kUtil::includeOnce" static method - renamed function "makepassword4" into "kUtil::generatePassword" static method - removed "ref_call_user_func_array" function (used eval inside), because now build-in "ReflectionClass" (PHP 5.2+) class does the same but faster (+performance boost) - renamed function "fputcsv2" into "kUtil::fputcsv" static method - moved "request_headers" function to "kMainTagProcessor::_requestHeaders" hidden method, since only use was discovered there - not changed "parse_ini_string" function because of it will be available since PHP 5.3 anyway - not changed "memory_get_usage" function to handle cases, when PHP was compiled without memory usage tracking capabilities - not changed "imagecreatefrombmp" because of someday GD could also have such a function - all useless calls to "safeDefine" function replaced with calls to "define" function - removed "getmicrotime" function definition from "globals.php", since it is declared in every main php file (e.g. index.php, cron.php, etc.) ----- Other ----- - formatting changed in some PHP files (initial tabbed column removed) - changed Status field display on "agent editing form" from dropdown to radio buttons (since it only has 2 values) - removed "view menu" filters, which duplicated grid column filters (from 5.1.1) - moved "per_page" setting to template from unit config for "Search Config" sections - merged notable changes from "curl_post" function to "kCurlHelper" class (e.g. skip SSL certificate checking) - replaced "curl_post" function usage with "kCurlHelper" class usage - removed "curl_post" function, since it's deprecated - replaced "array_merge_recursive2" function usage with "array_merge" function usage, when only one-dimensional arrays were used (+performance boost) - introduced exception throwing/handling model (in both Debugger and kApplication classes) - replaced user fatal errors triggering with exception throwing - renamed email event related constants to have "EmailEvent::" prefix in their name - added "kiCacheable" interface to indicate, that class can provide data to be stored/retrieved to unit config cache (uses "Keeper" pattern) - removed "kApplication::Application" property from "kApplication" class (prevents recursion, when object data is displayed using "debug_backtrace" function) - removed duplicate installed module loading query from "kApplication::refreshModuleInfo" method - database query from "kApplication::refreshModuleInfo" method marked as cacheable - used "$this->Application->EventManager" reference instead of using "kApplication::recallObject" to retrieve it - removed duplication SERVER_NAME constant declaration from "kApplication::SetDefaultConstants" method - database query from "kApplication::ConfigValue" method marked as cacheable - renamed parameters of "kApplication::HandleEvent" method to conform with naming standards - refactored "kApplication::registerHook" method to have 4 parameters (2 of them are optional) instead of 8 required parameters - added automatic call trace display in debugger, when user fatal error is triggered or exception is thrown - simplified code of "kApplication::handleError" method - removed unused "kApplication::reportError" method - duplicate code removed from "kApplication::GetTempName" method (now it uses "kApplication::GetTempTablePrefix" method) - cached usage results of "kApplication::IsTempTable" function, because of regular usage - implementation of kiCacheable interface added to kApplication class (cached data: configuration variables, replacement templates, rewrite listeners, installed modules) - renamed change log related constants to ChangeLog::* - renamed agent related constants to Agent::* - renamed mailing list related constants to MailingList::* - renamed user login process related constants to LoginResult::* - renamed form submission related constants to SubmissionFormField::* - changed declaration of kCatDBItem::NameCopy method to match parent class method declaration - replaced duplicate code (classes: kCatDBEventHandler, ImageEventHandler) with "kSearchHelper::SetComplexFilter" method usage, which does the same - renamed constructors of almost all classes into "__construct" (easier to call parent class constructor without knowing which of parent classes has overridden constructor) - fixed non-resetable cache problem in "kCatDBTagProcessor::HasAdditionalImages" method (from 5.1.1) - rewritten database connection error processing in kDBConnection class (from 5.1.1) - replaced "..." html tags with "..." html tags in some error messages - changed event status of "kDBEventHandler::OnViewFile" event to be "kEvent::erSTOP" instead of doing "exit;" at the end of event - replaced "kDBTagProcessor::getObject" method usage to "kDBTagProcessor::GetList" method usage in "kDBTagProcessor::PerPage" method - changed "TemplatesCache::CheckDir" method to stop processing, when it's unable to create at least one directory in requested path - formatted database query in "kMainTagProcessor::RequireLogin" and "kMainTagProcessor::IsMember" methods - fixed direct prefix/special change (not via kDBBase::Init method) in "kTagProcessor::ProcessParsedTag", "kTagProcessor::processAggregatedTag", "LanguagesTagProcessor::ListLanguages" and "kDBTagProcessor::PerPage" methods - hidden "kHelper::prepareTagParams" method - added implementation if kiCacheable interface in kArray class (cached data: tag aggregation mapping) - removed unused "AdminTagProcessor::SetConst" method - optimized "AgentEventHandler::OnRefreshAgents" method to load all agents information with one database query instead of one query per agent as before - added "RunTime" (was missing) and "Status" (was commented out) columns to agent grid - changed declaration of "CategoriesItem::NameCopy" method to match parent class method declaration - improved menu cache rebuild (on admin login screen with missing memory cache; from 5.1.1) - renamed XML_* constants to kXMLHelper::XML_* - changed declaration of "LanguagesItem::Load" and "ThemeItem:Load" methods to match parent class method declaration - "Custom" section in admin console made visible in debug mode only - added constants for coupon, discount, product option, product inventory - changed declaration of "FilesItem::Delete" method to match parent method declaration - moved "add to cart" logic and "discount" calculation in order logic to new OrderCalculator and OrderManager classes - changed declaration of "OrdersItem::GetErrorMsg" method to match parent method declaration - removed undefined "$rootURL" global variable usage in "startup.php" file - removed usage of missing "DomainDetect" configuration variable in module license processing code - fixed "kApplication::setDBCache" now doesn't accept value by reference - replaced "getmicrotime" function with "microtime(true)" function call - changed login code during "Install Maintenace" to use UserHelper::loginUser directly, instead of calling u:OnLogin event - changed licensing url to point to in-portal.com instead of intechnic.com website
(0003206)
alex   
2011-01-12 09:15   
(edited on: 2011-07-05 15:38)
- created class kCacheManager to hold all caching processing code - moved configuration variable & phrase caching code to kCacheManager class - moved unit config caching code from kUnitConfigReader class to kCacheManager class - created kUrlManager class for all url building code - moved url building code from kApplication class to kUrlManager class - removed unused PhraseCache::GetCachedIds, PhraseCache::UpdateCache methods - moved usage of kApplication::ConfigValue method from unit configs to event handlers - moved kApplication::getFilename to kModRewriteHelper, since it's used only there [B]Test Plan for 2 previous commits:[/B] - check upgrade from 4.0.1 to 5.2.0 (change database column of "text" type to be NULL, change path from "/kernel/" to "/system" in PageContent table on all languages, subject and body ML columns added to EmailMessage table, phrases from multiple languages merged into single-record-per-phrase basis) - check curl requests in all payment gateways in In-Commerce
(0003583)
alex   
2011-07-05 11:32   
- ability to override every system class, that is retrieved via factory (e.g. kEventManager) - all classes are created via kFactory class, so they can be overridden too - system object, like kUnitConfigReader class object are no longer stored in kFactory class - class registration in kApplication::RegisterDefaultClasses method rearranged into logical groups - design patterns, noted in class/method comments, when applicatable - unit config re-reading redesign by interface usage
(0004137)
alex   
2011-11-07 04:52   
What was done with url processing code: 1. all url building code was moved from kApplication to kUrlManager class 2. mod-rewrite/non-mod-rewrite code was split into kRewriteUrlProcessor and kPlainUrlProcessor classes 3. mod-rewrite parsing code was moved from kModRewriteHelper class into kRewriteUrlProcessor 4. non-mod-rewrite parsing code was moved from kHTTPQuery class into kPlainUrlProcessor class
(0004482)
alex   
2012-03-03 15:16   
Patches removing_references_in_events_core.patch & removing_references_in_events_modules.patch does: 1. added check for SimpleXML upon install 2. required version of PHP incremented to 5.3.2 3. removed "&" before $event function parameters 4. manual class file loading & class dependencies ('require_classes' parameter in unit config) replaced with autoloader 5. added ability to override factory class upon application initialization (for unit testing purposes) 6. display short debugger report inside toolbar (no need to scroll down the page) 7. don't run affiliate code during installation





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1368 [In-Portal CMS] Data Management refactoring N/A 2012-07-23 08:01 2012-07-23 08:17
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.2.0-RC1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/LDN9GQhjurY/discussion
Change Log Message: Removed module-root concept
Estimate Points: 3
Summary: Removing "module root category" term and related functionality
Description: Here are all places, based on code, where "RootCat" word is used. I must admit, that some of them are pretty weird and most probably were traveling from one release to another without being noticed.

1. SuggestItemLink tag - when shown on index page, then actually allows to suggest into module root category - I haven't seen suggest link on index page :))
2. IsModuleHome tag - used to display different content of category in case if that's module root category (used in In-Commerce in in-commerce/designs/section.tpl) - used for mixed themes (e.g. where in-link and in-commerce are together used). I won't be recommending such themes to be created. I vote for create e-shop themes independent from in-link themes and so on. Or at least display all top/hot and so on items on main site index page, not to each module have it's own.
3. CategorySelector tag - shows child category structure based on module root category for suggest/edit link/article page - since it don't know what category is a top, them "Home" category will be used and that will display In-News categories on In-Link suggest page
4. c_CheckModuleRoot tag - ensures that module root category is always displayed using given template (used in onlinestore theme) - never used in advanced theme, so I propose to remove it at all
5. c_CategoryLink tag - builds link to module root category - just won't be doing that anymore
6. PrintList - lists category items from module root category recursively - just will be printing from "Home" category and deeper
7. c_NavigationBar - renders module root category using separate block - that I don't know how to handle; maybe there is no need for special handling, since you could do the same by specifying different section design for category acting as module root (if any)
8. Item rendering template detection, when category not passed - get from root category of module associated with given prefix (don't recall if it even was required by someone)
9. u:OnResetPassword event redirects to thank you page with In-Commerce root category hardcoded :) - works even, when In-Commerce isn't installed, needs to be removed
10. Various places getting top product category (In-Auction, In-Commerce) - could scan all db instead

All output related usages could use Home category instead and will get same behavior.

My most concern is about CategorySelector tag.
Steps To Reproduce:
Additional Information: Then tags "c_CheckModuleRoot" and "IsModuleHome" should be deleted, since they rely on module root categories only. Other places will get category as follows:

* when not passed, then Home category used
* when passed will use passed category
* when 0 passed, then actual ID of Home category will be used


Also we will remove interface for changing module root category (useful for websites who do an upgrade to keep what they have) and we set Home as root category for all modules during new installations.
We can keep "RootCat" column in Modules table for backwards compatibility, but don't rely on it internally.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1365 [In-Commerce] Front End bug report always 2012-07-22 08:07 2012-07-22 08:07
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/Kqc4Hrw5q7Y/discussion
Change Log Message: Adds ability to translate product options
Estimate Points: 1
Summary: Ability to translate product option names and their values
Description: 1. add phrase support to option name (when text is escaped with "!" then it's a phrase, e.g. "!lu_OptionName!"; this way no upgrade script needed)

2. add phrase support to option values of radio/select/multiselect options (when text is escaped with "!" then it's a phrase, e.g. "!lu_OptionValue!"; this way no upgrade script needed)
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1347 [In-Commerce] Refactoring feature request N/A 2012-07-10 11:20 2012-07-10 11:20
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/8BrVPbujkno/discussion
Change Log Message: Adds reoccurring payment automatic system
Estimate Points: 2
Summary: Reoccurring orders API
Description: In In-Commerce we have such term as reoccurring orders. Here are steps to start using it:

1. create a product of subscription type in Admin Console and on "Access & Pricing" tab check "Recurring Billing" checkbox (db field: Products.IsRecurringBilling)
2. then, when user buys that product that reoccurring mark will be placed in his order and next charge time will be automatically set (based on subscription interval chosen at time of product adding to cart on it's detail page)
3. then this order needs to be processed & charged by website administration to have "processed" (instead of "pending" status)

Then scheduled task in cron will periodically check for orders, who are processed, but have next charge time and:

* clone order
* set it's status to Pending
* set next charge date to next month (or whatever subscription interval is)
* charge order, that will make it's status to Processed

This way order is cloned for each payment and In-Commerce keeps track when to do next charge.
User can cancel reoccurring charging at any time while viewing cloned order details from "My Orders" page on Front-End.


However these days payment gateways become clever enough to do reoccurring charging themselves and only report charged/failed status back to In-Commerce. This feature is called "subscriptions".
Sadly, but In-Commerce absolutely doesn't support this feature.

Here is how I see it implemented:

1. add "SubscriptionProcessing = {None, Gateway, In-Commerce}" parameter to each payment gateway integration class
2. only clone orders for charging (see above) if payment gateway, associated with payment type specified in order has "SubscriptionProcessing = In-Commerce" setting
3. on order preview step during checkout we add some extra fields to create subscription on payment gateway side (instead of single payment) if payment gateway associated with payment type from current order has "SubscriptionProcessing = Gateway" setting and user brough subscription with "Recurring Billing" checkbox set

Once order is approved payment gateway will automatically start charging user on a regular basis. Once charge happens (or fails) we'll receive notification to same /modules/in-commerce/gw_notify.php script and clone order (see above), but set it to Processed right away so no extra charge will happen.


P.S.
I saw some PayPal subscription handling code pieces in In-Commerce but database columns mentioned in code were not present in database and tags created for same purpose wasn't used anywhere too. Surely these are pieces of some old customization that are left without being noticed for a long time.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
66 [In-Portal CMS] Admin Interfaces feature request N/A 2009-06-12 06:51 2012-03-22 11:54
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs feedback Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/yTfC29_hLEg/discussion
Change Log Message: added feature to store complete email copy in the email log
Estimate Points: 0
Summary: Add Email Details feature to Email Logs
Description: Add ability, to view details of sent emails from email log grid. It's not content of email itself, it's a data, that was associated with email event that was sent.

For example for LINK.ADD or LINK.MODIFY events we could make email log subject a link to editing form of that link. Same for users and other related stuff. This way based on email log (in case of admin haven't received actual email) he/she can view details for each email and why it was sent at all.
Steps To Reproduce:
Additional Information:
Attached Files:
(0000058)
Dmitry   
2009-06-12 10:51   
I like the idea. I think we can use our Change Log feature and get association with changed items if there were any? I also think that storing actual Email body would help too. Down on the road we can add functionality for Exclusions and Agents to Clean up or even Compress the logs so they stored in a files. Give me your thought on this.
(0004422)
Dmitry   
2012-01-17 16:43   
(edited on: 2012-01-17 17:04)
[B]I believe we should do the following here:[/B] 1. Store complete Email message that has been sent out to the User. It can play the role of Web Copy when needed. We should have new fields added which will store: - Email Subject - Email Body - AdditionalRecepients (all recipients like CC, BCC users, groups and so on - it's okay to store) - EmailKey (random 15 ro 20 alpa-numeric) to be able to reference to this log from the Front end - if needed (will use in URL) We would need to have some sort of Tag which can be used within the Template and which during the mailing will be build correct URL with proper Key so users can click and view they web version if needed. 2. Create new System Configuration which would allow to specify number days to keep Email logs and delete all older ones (default 30 days). It's kind of rotation. 3. Create ScheduledJob which would do cleaning once a day.
(0004505)
Dmitry   
2012-03-22 11:54   
We actually decided to create a separate task for features described in my prev. note ##4422 #1228: Email Log Rotation and New Fields





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1061 [In-Portal CMS] Admin Interfaces feature request N/A 2011-05-27 05:15 2012-01-06 02:55
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.2  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/xrOFASoXZS8/discussion
Change Log Message: Adds ability to enter inline description for files in Flash Uploader
Estimate Points: 2
Summary: Ability to enter inline description for files in Flash Uploader
Description: I've developed a small extension to flash uploader, that allows to enter a short description for each file that was uploaded.

Field Name: [browse button]

            [x] [thumbnail1] image filename
                              [______description________]

            [x] [thumbnail2] image filename
                              [______description________]

            [x] [thumbnail3] image filename
                              [______description________]

In mockup above image thumbnail's height is larger, then image name and description field height together. That's why this will look normally together.


This is pure Flash Uploader extension and can't be used with category items (e.g. links), since they naturally don't support Flash Uploader at all.


To enable description entering ability you need to specify 'description_field' => 'DescriptionFieldName' in particular field declaration in unit config.

Of course you need to create a real or virtual field that will store all that descriptions.

Descriptions are stored the same way as files are - "descr1|descr2|....". Positions of description and uploaded file in 2 fields (with files and with descriptions) matches, e.g. file at position 2 in file field will have description at position 2 in description field.
Steps To Reproduce:
Additional Information:
Attached Files: feat_flash_uploader_inline_uploaded_files_description.patch (5,149) 2011-05-27 05:15
http://tracker.in-portal.org/file_download.php?file_id=1024&type=bug
(0004390)
alex   
2012-01-06 02:55   
We could use [url]http://stackoverflow.com/questions/3448831/store-return-json-value-in-input-hidden-field[/url] to store JSON object in a hidden field instead of just only descriptions. This way we could keep track of unlimited number of properties associated with each image being uploaded.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
851 [In-Portal CMS] Admin Interfaces task N/A 2010-09-01 02:58 2011-12-29 13:05
Reporter: alex Platform:  
Assigned To: OS:  
Priority: minor OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-design/browse_thread/thread/b8547a2fcd4cc0a1
Change Log Message:
Estimate Points: 3
Summary: Improvements to translatable field interface
Description: We have 2 possible layouts of forms, that have translatable fields on them:
1. show all fields on all languages at once
- getting very large form, when there are a lot of translatable fields on it
+ no need to refresh form to enter field value on other language

2. only field on current language is visible
+ small form
- need to refresh form and validate all data to enter value from other language

We need to invent something new, that will allow to enter field values on different languages without form refresh and that doesn't make forms bigger, when new languages are added to the site.

In 2nd approach errors from translatable field on any language are redirected back to field on primary language.

For example:

    * you have l1_Name and l2_Name fields on form;
    * 2nd language is primary;
    * in case of error in l1_Name field it will be shown under l2_Name field.

So here is the solution, that should fit our needs without even requiring extra space for additional controls. No new controls added only existing controls will work a bit different:

   1. each translatable field will have input controls on all languages, but only one control per field will be visible at a time;
   2. dropdown on top (with language list) will affect all translatable fields and will make controls on new selected language become visible (instead of previous current language) without form refresh;
   3. top dropdown name will be "m_lang", so it will be remembered as form language once form is submitted;
   4. translatable fields should use "inp_edit_box_ml" and "inp_edit_textarea_ml" blocks for this to work;
   5. mentioned above blocks needs to be rewritten to support such behavior.

We have JavaScript Form class, that tries to fill empty space at form bottom by resizing textarea, so we should trick it and make it assume, that same field on different languages is actual one field, that uses space on form and not all of them will be always visible.
Steps To Reproduce:
Additional Information:
Attached Files:
(0003896)
alex   
2011-09-24 05:30   
Reminder sent to: Dmitry
I disagree, that this issue has minor priority. It's obviously very hard for users, who have their website content entered at least on 5 languages to manage it's translations on all languages with all that form reloads on every language change. Other solution for making all fields from all languages shown at once is bad too, since it makes very large forms.
(0004354)
administrator   
2011-12-29 13:05   
Moving this feature to Icebox until we get to Improvement of Admin Interfaces.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
87 [In-Portal CMS] Admin Interfaces bug report always 2009-06-17 06:52 2011-12-28 23:50
Reporter: alex Platform:  
Assigned To: erik OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.0.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Make scrollable grid in "Tools -> Query Database" section
Description: Currently we have some kind of outdated grid, when "SELECT" query is performed and results are shown. I propose to use our standard scrollable grid style in this template.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1153 [In-Portal CMS] Refactoring refactoring always 2011-11-01 12:27 2011-12-23 11:37
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/vuGnrVy25cA/discussion
Change Log Message: Minimized In-Portal Core
Estimate Points: 3
Summary: Minimizing In-Portal CORE
Description: It's quite noticeable that out In-Portal CORE is constantly growing in all directions - both features and code. We should minimize the CORE module and create small modules for other less critical to In-Portal functionality.

Below is a list of tables breakdown:


In-Portal CORE Tables
=====================
1. PortalUser (list of users/admins, registered in system)
2. PortalGroup (list of groups, that can be assigned to registered users)
3. UserGroup (user-group associations)
4. PersistantSessionData (list of session-independent user settings; fix grammatical error in table name)
5. UserSession (list of sessions, produced by logged-in site visitors)
6. SessionData (data, associated with created user sessions)

7. Language (list of languages, defined in system)
8. LocalesList (list of supported locales, used for switching website language to user's browser language only)
9. CountryStates (list of countries with their states, used on user registration form)
10. Phrase (list of language labels of every language, defined in system)
11. Events (list of e-mail templates, that can be sent from the system)

12. Modules (list of modules, installed in system)
13. ConfigurationValues (list of configuration settings)
14. SearchConfig (list of search-related settings)

15. Category (list of pages, defined in system)
16. Images (list of images, currently used by categories and catalog items)
17. PageContent (content, that was entered in the pages, using Content Blocks)
18. Cache (system cache when no Memcached installed/used)
19. CachedUrls (list of parsed & cached page mod-rewrite urls)
20. Semaphores (table, used in engine, that protects data from concurrent edit/save attempts by different users)

21. Theme (list of front-end themes)
22. ThemeFiles (list of front-end theme templates, used for mod-rewrite page url parsing)
23. Skins (list admin console skins)

24. PermCache (used only for advanced category-based permissions scheme, that can be disabled by default in future)
25. PermissionConfig (used only for advanced category-based permissions scheme, that can be disabled by default in future)
26. Permissions (list admin section permissions)
27. Agents (list of cronjobs)


In-Portal tables, that we can get rid of by peforming refactoring
===================================================================

IdGenerator (table, that keeps track of ResourceIds generated, get rid of it in future. we can use one of existing tablesuch as Cache, and get rid of this at all later on)

PhraseCache (merge with CachedUrls somehow)

PopupSizes (store in PortalUser.PopupSizes field/PersistentSessionData table as serialized array, we can have key, like md5(template_path) and popup size)

Counters (we only have 3 counters and can easily transfer them to memcache, or Cache table if memcache is not avaialble)

StatItem (delete)


In-Portal tables that can be moved into separate Modules
========================================================

USER BANS
BanRules

LOGS
SessionLogs
ChangeLogs
CurlLog
EmailLog
SlowSqlCapture
StatisticsCapture

CUSTOM FIELDS
CustomField
CategoryCustomData
PortalUserCustomData

MAILING LIST
EmailQueue
MailingLists

CATALOG ITEMS
CategoryItems
Favorites
ImportCache
ImportScripts
ItemFiles
ItemFilters
ItemRating
ItemReview
ItemTypes
SearchLog
RelatedSearches
CountCache
SpamReports
SpamControl
Relationship

SUBMISSION FORMS
Drafts
FormFields
Forms
FormSubmissions
SubmissionLog

MULTI-DOMAINS
SiteDomains

DICTIONARY
Thesaurus
SpellingDictionary
StopWords
Steps To Reproduce:
Additional Information: ========== Info from 0000268: Code Cleanup in 5.2.x branch ===
1. Somehow divide In-Portal into layers, that can be easily turned on/off.

2. Maybe modularize core itself, e.g. "form submissions", "permission system", "various logs", "visits", "site domains".

3. Maybe some parts (within the main module) can be downloaded separately.
============

Interesting code in WordPress and I got this idea:

Have system-level events, that modules can hook to so it will be easier for us to from module.

For example OnGetTheme event could retrieve theme_id from url and hook to it from SiteDomain module can override that theme with the one, that matches current site domain.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
666 [In-Portal CMS] Install / Upgrages feature request N/A 2010-03-27 17:47 2011-12-18 15:31
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.3-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/d3860bb668ee7750
Change Log Message:
Estimate Points: 3
Summary: Show latest available version in top frame in administrative console
Description: I propose we show latest available version in top frame in administrative console. For example: "Latest Version: 5.0.2. Your Version: 5.0.0. [Upgrade]". Upgrade is link to download page. This way administrator will be always aware, that new version is available for download. Maybe we also should place link to issue tracker filtered by given release on download page near module name.

Here are some of my thoughts how this can be even more useful to users:


0. Only available in Admin Advanced Interface (NOT Simple).


1. In Top Frame (exact location needs to be picked) display a message if a new version of In-Portal or other Modules are available. The logic can be the following:

a. If new In-Portal version is available, show message -- In-Portal 5.0.3 is available.
b. or Show message -- In-LInk 5.0.3 is available. It will be a link to


2. The message above (in top frame) will LINK to "Configuration -> Modules" section where user can see ALL all of his installed modules (now) and new columns that will show:

a. Latest Version - shows latest stable version, ie. 5.0.3 (download zip or gz); with DIRECT links for downloads.
b. Change Log - link (opens in new window) to Issue Tracker with filters for that version to see what was done.


3. All checks should be done for Admin ONLY and probably using an Agent (regular event).


Since it will be a Web Service from In-Portal.com website we would NEED TO THINK:

1. about In-Commerce and In-Auction modules check?
2. somehow validate license, and build Direct download links?


Also, see some screenshots how WP does it.
Steps To Reproduce:
Additional Information:
Attached Files: NewVersionOptions1.jpg (120,156) 2010-03-27 17:47
http://tracker.in-portal.org/file_download.php?file_id=418&type=bug
jpg

NewVersionOptions2.jpg (92,064) 2010-03-27 17:48
http://tracker.in-portal.org/file_download.php?file_id=419&type=bug
jpg
(0003946)
alex   
2011-09-30 12:02   
Will do in this version if we have time
(0003947)
alex   
2011-09-30 12:07   
We may try to use [url]http://www.php.net/manual/en/book.stream.php[/url], since it has "ftp://" stream build-in in each PHP5 installation. FTP related functions are disabled by default, since Linux versions of PHP doesn't have "--enable-ftp" passed by default.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1048 [In-Portal CMS] Caching System bug report always 2011-05-04 15:41 2011-12-18 15:06
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.2  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/KqaMFx0JO8Y/discussion
Change Log Message: Fixing fatal error on content language negotiation when memcached is used
Estimate Points: 2
Summary: Using "Content Language Negotiation" along with Memcache cold start gives Fatal Error
Description: I have "Content Language Negotiation" and memory caching enabled. When I restarted Memcached server and then visited Front-end with empty url, e.g. http://www.site.com/ then redirect was made, since my "Accept-Language" header matched non-default language.

Because I have no cache, then kApplication::RewriteListeners array was empty and attempt to build redirect link resulted in fatal error listed below:


Notice: Undefined index: m in ...\core\kernel\application.php on line 1953

Fatal error: Method name must be a string in .../core/kernel/application.php on line 1955


I suggest following fixing approach:
1. place return ; after each kApplication::Redirect method call
2. when !$this->Application->InitDone and redirect attempt is made, then schedule redirect, but don't perform
3. when init finishes and there is a scheduled redirect, then perform it
Steps To Reproduce:
Additional Information: Here are the places, when redirects happen:
* Redirect on Session Expiration
* Redirect on non-rewritten url
* Redirect on language negotiation
* Redirect on missing item’s view permission
* Redirect on category import completion
* Redirect on module install finished
* Redirect on site domain mismatch
* Redirect on category cache updated finish
* Redirect on request event processed
* Redirect on CSV import complete
* Redirect on install complete
* Redirect on login required template
* Redirect on SSL mode mismatch
* Redirect on email queue processing finished
* Redirect on url ending mismatch
* Redirect on template compilation finished
Attached Files:
(0004110)
alex   
2011-11-01 08:41   
This might not be the right way to fix this. We should move all code that does redirects during initialization into 1 place.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1139 [Modern-Store] General bug report always 2011-10-05 09:59 2011-12-05 09:24
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
 
ETA: none Fixed in Version: 1.0.0-B1  
    Target Version: 1.0.0  
Summary: Ajax-based shopping cart
Description: Ajax-based shopping cart
Steps To Reproduce:
Additional Information:
Attached Files: shopcart_ajax_advanced_theme_incomplete.patch (203,346) 2011-10-05 10:04
http://tracker.in-portal.org/file_download.php?file_id=1216&type=bug
(0004174)
alex   
2011-11-24 10:41   
Fix committed to [b]1.0.x branch[/b]. Commit Message: Fixes #0001139: Ajax-based shopping cart
(0004198)
Dmitry   
2011-12-02 12:10   
(edited on: 2011-12-02 13:18)
[B]Shopping cart Issues found[/B] - http://screencast.com/t/OMgKXavphKeH 1. Discount shows 0 on first Shopping Cart load 2. Discount is not recalculated when Quantity changed in Shopping cart 3. Change ItemsInCart tag to return Total Sum of Items in the Order. Currently it's incorrectly only returns count of different Product Types in the Cart while Items is total count of items including the same ones. 4. We need to update Cart Total and Order Items (in header) when Discount is applied OR Quantity is changed, or
(0004202)
alex   
2011-12-05 09:23   
done





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
996 [In-Portal CMS] Localization feature request always 2011-02-08 22:08 2011-11-06 15:52
Reporter: Dmitry Platform:  
Assigned To: Dmitry OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.2-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-local/CvgC_wMW8g0/discussion
Change Log Message: Integrated Google Translation API
Estimate Points: 2
Summary: Integrate Google Translation API into Language Translation
Description: Google has very nice Google Translation API that we can utilize to translate In-Portal into multiple languages.

The following features will be implemented in this feature:

1. Ability to mass translate Phrases and Email Events when Language Pack is created from another one (all phrases + events are copied). The proper Locale must be selected for both (source and target) language packs.

2. Ability to get Translation (as suggestion) of any label when editing it via Admin->Labels & Phrases section. The purpose of this is to be able to translate Labels individually.


We are using Google Translate API version 2 - http://code.google.com/apis/language/translate/v2/getting_started.html


Also, both API related Configuration Settings (Google Translate API Url and Google Translate API Key) are put under Admin->Configuration->Advanced->3rd Party API Settings section (new)
Steps To Reproduce:
Additional Information:
Attached Files: GoogleTranslatePrototype-v3.patch (26,631) 2011-02-08 22:08
http://tracker.in-portal.org/file_download.php?file_id=937&type=bug
(0003224)
Dmitry   
2011-02-08 22:09   
Please test.
(0003903)
Dmitry   
2011-09-24 22:20   
New patch for 5.2.x needed (PHP 5 format)
(0003918)
alex   
2011-09-27 04:30   
We also need to test PHP code separately here. Maybe idea of task is good, but implementation doesn't match.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
665 [In-Portal CMS] Optimization task N/A 2010-03-27 17:42 2011-11-06 15:51
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.3-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-bugs/browse_thread/thread/ea65bbfb9b6d670c
Change Log Message:
Estimate Points: 2
Summary: Get rid of multi-column indexes in database
Description: We should get rid of multi-column indexes in database or at least create individual indexes for these columns.

Also Price field index is missing in product prices table.

ALTER TABLE `inp_ProductsPricing` ADD INDEX ( `Price` ); # not on dev though

Also we could place UNIQUE indexes when appropriate, but not in tables, associated (through unit config) with template, that have "Clone" button on them. Phrase table could be a good start.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1155 [In-Portal CMS] Front End feature request always 2011-11-01 22:41 2011-11-02 03:54
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/c1lH7uqYUHc/discussion
Change Log Message: Integrated OpenSearch
Estimate Points: 1
Summary: Integrate OpenSearch
Description: Integrate OpenSearch functionality.

For example you place <link rel="search" type="application/opensearchdescription+xml" href="http://www.website.com/opensearch.php" title="description_here" />

Then you provide that "opensearch.php" file, that contains OpenSearch settings, to be used by browser (or any program, that supports open search):

<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
<ShortName>Company</ShortName>
<Description>Company Search</Description>
<Contact/>
<Url type="text/html" template="http://www.website.com/index.php?story={searchTerms}&do=search&subaction=search"/>
<LongName>Company Search</LongName>
<Image height="64" width="64" type="image/png">http://www.website.com/logo.png</Image>
<Image height="16" width="16" type="image/vnd.microsoft.icon">http://www.website.com/favicon.ico</Image>
<Developer>Company (http://www.website.com)</Developer>
<Attribution>Copyright 2007-2011 Company.</Attribution>
<SyndicationRight>open</SyndicationRight>
<AdultContent>false</AdultContent>
<Language>ru-ru</Language>
<OutputEncoding>windows-1251</OutputEncoding>
<InputEncoding>windows-1251</InputEncoding>
</OpenSearchDescription>


Full specifications: http://www.opensearch.org/Specifications/OpenSearch/1.1

No additional programming needed, only create XML file with a set of settings.

NOTES:

It's better if we try creating a template so it ends as http://www.website.com/PATH/opensearch.html or something (and not PHP file).
Steps To Reproduce:
Additional Information: Recently I've accidentally pressed TAB when typing a website address. And my Google Chrome browser displayed site-specific search form, that allowed me search data on that site even without visiting it.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
379 [In-Portal CMS] Front End bug report always 2009-10-12 09:14 2011-10-05 10:49
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.0.1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Last component of url is not received by rewrite listeners in case if it's number
Description: Last component of url is not received by rewrite listeners in case if it's number. In this case we assume, that it's page number and it should be processed the same way for all rewrite listeners and parse it before calling them and strip from the url, that is passed to rewrite listeners.

I came across task, where in case, that last url component is number, then it should be parsed as item id, but that was not possible, because it didn't survive in trip to my rewrite listener.
Steps To Reproduce:
Additional Information:
Attached Files:
(0003924)
alex   
2011-09-27 06:28   
Don't know how to solve it without breaking down URLs cached by spiders, like Google.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
854 [In-Portal CMS] Admin Interfaces feature request N/A 2010-09-02 06:01 2011-10-04 02:38
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: reviewed and tested Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/3f00ab8c635261b6
Change Log Message:
Estimate Points: 0
Summary: Possible improvements to grid date range filter
Description: We have pretty obvious "grid_date_range_filter" filter, that allows to enter date interval (from and to date) to filter grid records by.

I think, that we could make interval selection easier by placing dropdown above date fields with such possible values:

    * empty value
    * today
    * yesterday
    * 1 week (today minus 1 week)
    * 1 month (today minus 1 month)
Steps To Reproduce:
Additional Information:
Attached Files: date_range_filter_improvement.patch (4,625) 2010-09-02 06:01
http://tracker.in-portal.org/file_download.php?file_id=745&type=bug
date_range_filter_improvement_v2.patch (5,119) 2010-09-06 12:58
http://tracker.in-portal.org/file_download.php?file_id=746&type=bug
(0002764)
Dmitry   
2010-09-05 20:36   
Thanks, but patch needs to be reassembled - there seems to be some code which is different from current latest repo version (in tpl file).
(0002765)
Dmitry   
2010-09-05 20:38   
Also, I propose to test and include this in the current release so we don't have issues with this later. I know it's not entirely what we are looking for, but we can end up with lots of broken patches lately.
(0002775)
alex   
2010-09-06 05:45   
Reminder sent to: Dmitry
No need for that, since there only 1 new tag in kDBTagProcessor and template grid_blocks.tpl is modified.
(0002778)
Dmitry   
2010-09-06 12:39   
Reviewed and tested - basic functionality works okay, but there an issue with Calendar format date hard-coded in the block (Europe date fo. We should be able to auto-apply "Input DATE format" from currently selected language. Please let me know your thoughts on this.
(0002779)
alex   
2010-09-06 12:41   
Reminder sent to: Dmitry
When task is in "Needs Testing" status, then please: 1. test it OR 2. ask question without status change Since when you change status back and forth to "Needs Testing", then your username is set as Developer, however it's not always true. Maybe we should review issue state transition diagram to fit whatever action you are performing on tasks. This is not the first time with messed Developer field by the way.
(0002780)
alex   
2010-09-06 12:43   
Reminder sent to: Dmitry
Date format fix is pretty easy: replace calendar_format="d/m/Y" to calendar_format="" in filter block DefineElement statement.
(0002781)
Dmitry   
2010-09-06 12:51   
Reminder sent to: alex
Actually, I have tried that already and then it adds the TIME to the drop-down which is not exactly what we need. In best case scenario we need to have just a DATE (no time) as we see now, but in proper format. What you think?
(0002782)
alex   
2010-09-06 12:59   
Fixed. Also fix for "grid_date_range_filter" name was added, when used from unit config field array generator (was "grid_date_rage_filter" there).
(0002783)
Dmitry   
2010-09-06 14:37   
Thanks, tested good!
(0003985)
alex   
2011-10-04 02:38   
Maybe we shouldn't hurry with putting this to 5.2.0





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
973 [In-Portal CMS] Data Management feature request N/A 2011-01-25 04:20 2011-10-03 03:19
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: minor OS Version:  
Status: needs work Product Version: 5.1.2-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/Tdz1fixeM6o/discussion
Change Log Message: Adding Daemon mode
Estimate Points: 0
Summary: Daemon mode
Description: There are situation, when there is a need to process large amounts of data in short time.

To do that I propose to minimize action count, that In-Portal performs during it's initialization including:
* doing database queries that won't help to perform requested action (e.g. loading phrase cache, when phrase are not used at all)
* performing initialization of system parts that are not used (e.g. session initialization, when no login is made)

In total In-Portal is temporarily converted to sort of unix-like daemon (standalone service), that quickly performs given requests. That's why I called such operation mode as "daemon mode".

Usage (one of following):
- add $_CONFIG['Misc']['DaemonMode'] = '1'; to "system/config.php" file when system-wide daemon mode is required
- add define('DAEMON', 1); in PHP file, where daemon mode is required (e.g. cron.php, run_event.php, index.php, etc.); it should happen before FULL_PATH constant definition

Tables never used in daemon mode:
- CachedUrls (mod-rewrite caching won't work)
- PhraseCache (phrase and configuration variable caching won't work)
- Counters (counters, like member count won't work)
- ThemeFiles (for mod-rewrite url parsing)
- CustomField (no custom field data can be accessible)
- Forms (new forms are not added to admin tree for their submission reviewing)

Proposed database table permissions that should be at least for this to work:
GRANT SELECT ON `inportal_database`.`inp_Phrase` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_ConfigurationValues` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Language` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Modules` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Theme` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Skins` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_SiteDomains` TO 'inportal_user'@'localhost';

As you can clearly see there is only 7 database table needed, instead of 71 tables, that could be used (I'm not saying that all of them are used on each run).

What won't be working:
- building links using "use_section" parameter of "m_Link" tag
- new agents are not added based on found "RegularEvents" unit config option (already existing agents will work of course)
- new records in Category table are not added based theme file scanning (so you should do "Rebuild Theme Files" while daemon mode is off)
- importing language pack
- new theme file discovery (for mod-rewrite url detection)
Steps To Reproduce:
Additional Information: For all this to work you need to enable memcache caching.
Attached Files: daemon_mode_feature.patch (7,270) 2011-01-25 04:20
http://tracker.in-portal.org/file_download.php?file_id=916&type=bug
(0003920)
alex   
2011-09-27 05:01   
I won't be hurrying with this patch applying.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
351 [In-Portal CMS] Optimization task always 2009-10-05 06:41 2011-09-30 11:56
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Remove "kDBEventHandler::RemoveRequiredFields" method
Description: Method "kDBEventHandler::RemoveRequiredFields" is used to make all required fields non-required to be able save object without validating it. This doesn't help in case, when custom validation is used.

I propose to remove this method, and use "$object->IgnoreValidation = true;" where mentioned above method is used.
Steps To Reproduce:
Additional Information:
Attached Files:
(0003907)
alex   
2011-09-25 09:32   
This maybe not the best idea to do this, since proposed solution completely ignores all validation errors. For example I saw this method to be used for resetting all validation settings and then user manually set the ones he needs right now. This method should go away by itself since Forms functionality #000271 task will be implemented.
(0003908)
Dmitry   
2011-09-25 11:21   
Moved to 5.2.0 for further review based on the Alex's note





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
956 [In-Portal CMS] Database task sometimes 2011-01-03 02:56 2011-09-30 11:54
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/forum/#!topic/in-portal-dev/A4uPHS34o_8
Change Log Message: Fixed some errors, when not tables in database are available
Estimate Points: 0
Summary: Insufficient database permission handling
Description: Recently there was a case, when only some of In-Portal table were actually present/accessible to In-Portal (sort of daemon mode), when there was a need to handle simple request and nothing more.

I've noticed, that in such case In-Portal doesn't properly handle this resulting more warning/notices to be raised.

Here is the patch, that prevents such behavior.
Steps To Reproduce:
Additional Information: These are only permissions, that should be given to MySQL user for testing:


GRANT SELECT ON `inportal_database`.`inp_Phrase` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_ConfigurationValues` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Language` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Modules` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Theme` TO 'inportal_user'@'localhost';
GRANT SELECT ON `inportal_database`.`inp_Skins` TO 'inportal_user'@'localhost';


Also please disable debug mode or just turn DBG_SQL_FAILURE off.
Attached Files: handling_insufficient_database_permissions.patch (8,292) 2011-01-03 02:56
http://tracker.in-portal.org/file_download.php?file_id=888&type=bug
handling_insufficient_database_permissions_v2.patch (10,422) 2011-01-03 08:58
http://tracker.in-portal.org/file_download.php?file_id=890&type=bug
(0003902)
Dmitry   
2011-09-24 22:20   
New patch for 5.2.x needed (PHP 5 format)
(0003919)
alex   
2011-09-27 04:32   
I won't be hurrying with applying this patch.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
139 [In-Portal CMS] Admin Interfaces feature request N/A 2009-07-23 13:13 2011-09-30 11:53
Reporter: alex Platform:  
Assigned To: OS:  
Priority: minor OS Version:  
Status: active Product Version: 5.0.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Make possible to control visibility of grid columns via group permissions
Description: On group editing screen add new "Grids" tab. On that tab there will be list of all grids available in system in form "<prefix> - <grid_name>" (dropdown) and a "inp_edit_picker" control (to select what columns are allowed to be viewed by given group. When grid is selected, then we will populate "inp_edit_picker" control with columns from given grid.

Maybe we need to hide fields on edit templates, related to hidden columns in grid.
Don't know really, but described here feature could be useful in any way.
Steps To Reproduce:
Additional Information: Need to cache all grids from all unit configs somewhere. It's bad idea to put it into "configs_parsed" cache, since there won't be any common use for that.

On the other hand we could scan for "mod[Default]columns_." like variables in persistent session data table. Here "mod" is unit config prefix and "Default" is grid name.

But that variables will only presented if user has visited the grid at least once.

To store all this we need to create GroupGridPermissions table with following fields:
- GridPermissionId
- GroupId
- Prefix
- GridName
- VisibleColumns


This way before showing grid we could query this table and if no record found for this grid, then all columns are allowed to be shown.


I can't really determine how long it will take to implement this feature, since no idea about how to get all grids registered in system with all their fields quickly.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1138 [Modern-Store] General task always 2011-09-29 21:51 2011-09-29 21:51
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: 1.0.0  
Summary: General Template Work
Description: General Template Work (ie. structure changes)
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
850 [In-Portal CMS] Optimization task N/A 2010-09-01 02:31 2011-09-26 05:08
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/913c2ee4329cd75e
Change Log Message:
Estimate Points: 0
Summary: Automatic class name retrieving based on it's filename
Description: I propose we auto-guess php class name based on filename, where that class is stored.

For example "my_super_helper.php" file will contain "MySuperHelper" class and nothing other.

There are several benefits of this:

    * no need to specify class name in unit config file (only class filename remains);
    * developer will be forced to properly name class file to connect it's class to the system.

We'll make some presumptions, that:

    * "eh" will transform to "EventHandler"
    * "tp" will transform to "TagProcessor"
    * all classes from "core" module, that are not event handler/tag processor should have "k" in front of their name

Before:

    * UsersEventHandler, users_event_handler.php
    * UserGroupsEventHandler, user_groups_eh.php
    * kThemesHelper, themes_helper.php
    * CustomFieldsTagProcessor, custom_fields_tag_processor.php

After:

    * UserEventHandler, user_eh.php
    * UserGroupEventHandler, user_group_eh.php
    * kThemeHelper, theme_helper.php
    * CustomFieldTagProcessor, custom_field_tp.php
Steps To Reproduce:
Additional Information: This large change, since we need to rename most of our classes/files to keep everything working. That's why I propose this change to be made as part of 5.2.0 release.
Attached Files:
(0002768)
Dmitry   
2010-09-05 20:54   
I believe there is a type in one of your examples: * CustomFieldEventHandler, custom_field_tp.php will be: * CustomFieldEventHandler, custom_field_eh.php Also, just to clarify all non-EH/TP and NON-Core module Classes will NOT have "k" infront of it. Let's say Custom module Helper or something else?
(0002773)
alex   
2010-09-06 05:38   
Reminder sent to: Dmitry
10x for noticing, but error was on other part: EventHandler should be replaced with TagProcessor, since most of other examples already have EventHandler in them. I've fixed that.
(0003913)
alex   
2011-09-26 05:07   
We'll wait with this once, since auto-detecting filename could slow down unit config cache rebuild process.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
270 [In-Portal CMS] Admin Interfaces feature request N/A 2009-09-04 14:55 2011-09-26 05:05
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: "Form Configuration" for Add/Edit in Admin Console
Description: Currently each editing template in Administrative Console consists of several parts:

1. header - shows template header and record name, that being edited;
2. toolbar - common buttons, that allows to manipulate record being edited;
3. form fields - set of blocks, that shows controls used for data editing on given form.

There nothing special about header and toolbar, because they are already highly flexible and meet most and less common needs, but there is something not too flexible about form fields. Form fields order and grouping into subsections is hardcoded and can't be changed without directly editing given template. For now we only have option for dynamically hiding each of the fields and in case if all subsection fields are hidden, then subsection will be hidden automatically.

Idea is to define form (or several forms) inside unit config and tell what form fields should be displayed, where they should be displayed inside the layout (see task 0000269) that is used on that form, how they should be grouped into subsections, tell the order of fields and what validator class should be used to validate data from this form (see task 0000271). In mentioned below example there is approximate idea about how form configuration could be made.

$config = Array (
    'Forms' => Array (
        'Default' => Array (
            'Validator' => 'kValidator',
            'ValidationRules' => Array (
                'SampleField' => Array ('required' => 1, 'max_len' => 255),
                'Discount' => Array ('min_value_inc' => 0, 'max_value_inc' => 100),
            ),
            'LayoutName' => 'TwoColumns',
            'LayoutData' => Array (
                'cell_one' => Array (
                    'la_subsection_General' => Array (
                        'Priority' => 1,
                        'Fields' => Array (
                            'SampleField' => Array ('name' => 'inp_edit_box', 'title' => 'la_fld_SampleField'),
                            'OptionField' => Array ('name' => 'inp_edit_options', 'title' => 'la_fld_OptionField', 'has_empty' => 1),
                        ),
                    ),
                    'la_subsection_Discount' => Array (
                        'Priority' => 2,
                        'Fields' => Array (
                            'Discount' => Array ('name' => 'inp_edit_box', 'title' => 'la_fld_Discount', 'style' => 'width: 50px;'),
                            'DiscountType' => Array ('name' => 'inp_edit_radio', 'title' => 'la_fld_DiscountType'),
                        ),
                    ),
                ),
                'cell_two' => Array (
                ),
            ),
        ),
    ),
);

Example mentioned above is a hard piece, that's why it will be described more thoroughly. In this example there is one form named "Default". Later this form name will be used on editing template to show this form. There are four main parameters in each form definition: Validator (validator class, that should be used to validate data, that will be submitted from this form), ValidationRules (field-specific validation rules if any, for fields, displayed on this form), LayoutName (layout name, used to display form on editing template), LayoutData (form field placement inside the layout). Each key of "LayoutData" array is cell name inside layout (see task 0000269) and it's content are fields, that should be shown in that cell. Field-specific validation rules, specified in ValidationRules option will be passed to validator class (see task 0000271), specified in "Validator" option of form and will be used to validate given form field. Each cell data consists of subsection names (as keys) and form fields inside each subsection. Each subsection has priority ("Priority" key) among other subsections in this cell and form fields ("Fields" key), that will be shown in this subsection. Keys in "Fields" array are field names, to be shown. All options will be passed directly to "kApplication::ParseBlock" method to form individual form field HTML code.

Form-based data validation will allow to create different forms for editing same data and each of forms can have different validation logic form same fields. This aspect will be detailed in 0000271 task.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
56 [In-Portal CMS] Admin Interfaces feature request always 2009-06-08 09:16 2011-07-19 08:25
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/28N41Tn6KFE/discussion
Change Log Message: Ability to have all grid columns in column picker
Estimate Points: 0
Summary: Ability to choose from all Grid Columns in Column Picker
Description: I propose to all all possible columns to all grids with "hidden" status - won't be shown after install, but will be available in column picker. This way we can give user possibility to display information he/she needs, not only information we have preselected for him.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
360 [In-Portal CMS] Front End feature request always 2009-10-06 14:20 2011-07-17 05:28
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Section renaming tracking
Description: Section names are used in url building, e.g. "http://www.site.com/sample/path" consists of two sections: "sample" and "path". In case, when one of them is renamed, then url to the page is changed, and previous page url is no longer accessible for example to "http://www.site.com/another-sample/path".

This is not good in case, when google or other spider has already indexed previous url to the page.

I propose to track such type of renaming and it will act as FriendlyURL field: when all page url matches renamed page url, then redirect is made to new url with 301 (Moved Permanently) code, so spiders will be happy.

It should also work in case, when page will be renamed more then once. But it's possible, that problem could occur in case, when in time some pages will be renamed to same name or worse. So there is need for some testing here.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
971 [In-Portal CMS] Data Management bug report always 2011-01-25 03:40 2011-05-18 13:19
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.2-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/aIpQRyA3p3I/discussion
Change Log Message: Fixed CSV file encoding problems from CRON
Estimate Points: 0
Summary: Function "fgetcsv" doesn't work with UTF-8 files from CRON
Description: Function "fgetcsv" doesn't work with UTF-8 files from CRON.

This happens, because it takes "LANG" environment variable into account, which is missing by default (like all environment), when cron scripts are executed.

http://www.php.net/fgetcsv - See notes section.


We can do "setenv" from kApplication::Init for case, when LANG could be missing. Not sure about PHP4, but this will work in PHP5 for sure.
Steps To Reproduce:
Additional Information: If we will use "fgetcsv" function, then we must set proper environment variable, that should match to parsed file encoding before continuing.

This could affect CSV file import, when grid has non-english symbols in it.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1040 [In-Portal CMS] Localization task always 2011-04-19 21:43 2011-04-19 21:43
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.2  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/FNgAVe_oJCg/discussion
Change Log Message: Improved description of Admin config settings
Estimate Points: 0
Summary: Improve Descriptions for Configuration fields across the System
Description: There is a need to review and improve current descriptions for Configuration fields across the System.

In particular need to specify types of Units accepted in Time/Date fields - seconds, hours, days or something else.

At the same time check on all other fields.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
1012 [In-Portal CMS] Admin Interfaces feature request N/A 2011-03-11 13:40 2011-03-11 13:40
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.2-B2  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-dev/FfMfI-Faq6U/discussion
Change Log Message: Adding "View Presets" functionality to grids
Estimate Points: 0
Summary: Grid "View Presets" functionality
Description: In-Portal has a "View Menu" almost on each of templates, that are used to display tabular data, e.g. grids/lists.

There was a lot of menu items in earlier versions of In-Portal, but right now there 3 menu items:
* Select Columns - opens dialog window for rearranging grid columns (show/hide/move left/move right)
* Auto-Refresh - will open submenu, where user can make grid auto-refresh periodically
* Per Page - will open submenu to change row count that are simultaniosly displayed in the list

Also when user changes filters, sorting or per-page, then they are stored into PersistantSessionData table to make sure that user will see current grid the same way he left it, when he logged-out from Admin Console.

I'm proposing to store various combinations of all of them as "View Presets", that can be used later.


In there database there will be 2+ presets:
* default (without name as for now)
* sandbox (used for temporary data storage)
* user preset 1
* user preset 2
* ....
* user preset N

Sandbox preset won't be visible in menus, but it will be used to temporarily store columns/filters/per-page until user decides to save them under preset of his choice OR create new preset. Sandbox preset will be used ONLY, when user has selected "user preset X". This will ensure, that "user preset X" isn't unintentionally changed by system until user decides to do that manually. When user is using "user preset X" and decides to create a new preset or update existing one, then all data from sandbox preset will be copied to the destination preset.

Switching to "user preset X" will overwrite sandbox preset contents with contents from selected preset. Then sandbox preset will be used to store any change user will made and to protect "user preset X" for unintended changes.


When default preset is selected, then changes will be saved directly to it without use of sandbox preset. This will ensure backwards compatibility and grid will work as before when presets are not used at all. When user is using default preset and decides to create a new preset or update existing one, then all data from default preset will be copied to destination preset.


Technically current preset name will be stored in session, but actual preset data read/write operations will happen on sandbox preset, when "user preset X" is being used.


Visually it will be a new "Presets" submenu (on top) of "View Menu":

Presets
  -- user preset A - [update] - [x]
  -- user preset B - [update] - [x]
  -- create new preset...

Maybe update and delete links will be more intuitive if replaced with nice small icons, maybe like our save/cancel toolbar buttons, but smaller.

We will ask user confirmation before actually deleting preset from database.
Steps To Reproduce:
Additional Information: Maybe preset deletion won't be causing page refresh so I can quickly delete more then one of them.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
715 [In-Portal CMS] Front End feature request always 2010-04-26 08:01 2011-02-25 12:14
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/5dc836fb951a5077
Change Log Message: Created replacement for Security Image functionality
Estimate Points: 0
Summary: Replacement for CAPTCHA functionality
Description: Today most popular approach is to place captcha code on form to verify, that
humans (not search engines) are submitting site forms. More dirty captcha
image is, more chances are spider/bot won't be able to recognize it. On the
other hand it makes form submitting uncomfortable for users. Also captcha is
used only on forms, when user is not logged in.

Here is approach, that is not using captcha, but still provides same level
of protection:

   1. after page with form is loaded, then send ajax request to server
 
   2. in ajax responce send random name and random value + save both to
   session

   3. when ajax responce is received, then dynamically add hidden field with
   received name and value

   4. when form is submitted, then check, that submitted value matches
   generated one from session


We are generating random hidden field name to allow same form to be
submitted from different tabs of same browser, when we have same user
session.
Because of spiders don't execute page javascript this approach can work.
Steps To Reproduce:
Additional Information: Small correction:

for correct simultaneous form submissions, two
hidden fields should be dynamically added, one with name like
"verification_key" and another with name like "verification_value",
also this pair is stored on server in session array called like
"verification_pairs" with "verification_key" as key and
"verification_value" as value. Then on submission we take session
array element with passed key and compare passed value to stored one.
Sure, also we verify that both key and value have been passed, and
passed key exists in session array.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
847 [In-Portal CMS] Admin Interfaces feature request N/A 2010-08-31 13:46 2011-02-06 09:19
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/39548a006271dc55
Change Log Message:
Estimate Points: 0
Summary: Domain-specific configuration variables
Description: In-Portal has a set of configuration pages, with a set of configurable parameters on each of them. It could be a good idea if each site domain could alter any configuration parameter value to fit it's needs. When parameter value isn't altered, then common (from the main site) value is used.

Interface changes:
==================
In top right corner of each configuration page (on blue bar) new dropdown called "Domain" will be added. Dropdown will be have ":: default ::" option, that will be selected by default and list of site domain names:
* :: default ::
* www.sample-site.com
* www.other-site.com

Database changes:
=================
System will add new column to ConfigurationValues table to hold site-domain specific configuration parameter. Column will include site domain ID in it's name: "sd<DOMAIN_ID>_VariableValue", e.g. "sd15_VariableValue".

Database query, used to select configuration parameter by name should changed from:
SELECT VariableValue
FROM ConfigurationValues
WHERE VariableName = 'Site_Name';

to:

SELECT COALESCE(sd2_VariableValue, VariableValue)
FROM ConfigurationValues
WHERE VariableName = 'Site_Name';
Steps To Reproduce:
Additional Information: Introduce 2 new configuration parameters:
* ImageUrl (or UploadedUrl)
* CompressedResourceUrl (or CompressedUrl)

By default:
* all links to resized images will be build using "ImageUrl" parameter
* all links to compressed resources (js/css) will be build using "CompressedResourceUrl" parameter

When appropriate configuration parameter isn't set, then system will use default site url as before.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
989 [In-Portal CMS] Front End feature request N/A 2011-02-05 07:57 2011-02-05 07:57
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.2-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://groups.google.com/d/topic/in-portal-bugs/82EJXjbGIco/discussion
Change Log Message: Added ability to use favorites for Guest users
Estimate Points: 0
Summary: Favorites functionality for unregistered users (guests)
Description: For now only registered and logged-in users can add links (In-Link) to favorites. When not logged-in then this ability is disabled by default.

However by enabling FAVORITES category-based permission for Guest/Everyone user groups non logged-in users can add favorites. The problem is that all non logged-in users share their favorites.

To eliminate such possibility I'm proposing to do the following:

For non logged-in users only:
* generate random cookie (only, when missing) for user computer's web-browser being used
* add UserCookie column to Favorites table (or any interested table, e.g. Link)
* when Favorite (or ant interested data, e.g. Link) is added, then also store UserCookie value with it
* when Favotite is removed, then check, that UserCookie of Favorite matches the one from user computer
* match Guest users with cookie to registered users with same cookie


* when new user is created, then store UserCookie in PortalUser table.
* when favorite list for logged-in users is shown, then select records this way:
- based on user cookie
- based on user id

This way, when user presses Logout button, then he still will see favorites he used to add, while being non logged-in.

Also we need to auto-claim (get user id based on it's UserCookie and set as CreatedById in appropriate tables) favorites added by guests after new user registration and after user login processes.
Steps To Reproduce:
Additional Information: There should not be more then 1 user registration from one web-browser for all this to work.
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
106 [In-Commerce] Admin Interfaces feature request always 2009-06-30 22:08 2011-01-31 02:18
Reporter: Dmitry Platform:  
Assigned To: alex OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: https://in-business.intechnic.com/?27995
Change Log Message: Ability to dynamically change Product Price in Catalog grid
Estimate Points: 0
Summary: Ability to Change Price on Products "Advanced View" Grid
Description: Ability to Change and Save Price in Products Advanced View Grid. See attachment.
Steps To Reproduce:
Additional Information: This has been completed as customization - custom.zip attached for future reference.
Attached Files: PriceChangeInGrid.gif (84,687) 2009-06-30 22:08
http://tracker.in-portal.org/file_download.php?file_id=19&type=bug
gif

custom.zip (34,172) 2009-06-30 22:09
http://tracker.in-portal.org/file_download.php?file_id=20&type=bug
grid_editable_price.patch (5,483) 2010-03-10 06:20
http://tracker.in-portal.org/file_download.php?file_id=338&type=bug
grid_editable_price-cleaned-Dmitry.patch (5,629) 2010-05-14 17:38
http://tracker.in-portal.org/file_download.php?file_id=542&type=bug
(0001873)
Dmitry   
2010-04-12 18:48   
(edited on: 2010-04-12 18:48)
Patch tested - working okay EXCEPT: I see no option to Save Price changes in Catalog Grid in "Show Structure" mode (while Save button available in Show All). Additional questions: 1. is whether we CAN or can NOT have Cancel button next to Save so it's activated the same way as Save does now 2. can we move both Save and Cancel button after Approve / Decline buttons, but add a separator before new them on Show All and HIDE that ability to change Price dynamically from the Catalog Gird in Show Structure for now since there is NO room for Save/Cancel buttons. I want consult with Andrew (interfaces) before putting under the main Catalog Grid.
(0001876)
alex   
2010-04-13 02:55   
1 - why to cancel, just don't press save button 2 - we can't move, since we only have specific place in toolbar, where all buttons from other tabs are inserted, like "New Link", "New Product" is added. We can hide this button in catalog, that's ok.
(0002205)
Dmitry   
2010-05-14 17:35   
Reminder sent to: alex, andrew
Hi Alex, I have shown Andrew what we have now. Below are his comments: [B]1.[/B] We want to have this ability for other TEXT fields (not all of course) and possibly for other items (not just Products or even Catalog). Example - Name/Title, SKU, Link URL and so on. [B]2.[/B] Save button. We'll need to find a better way to manage Save and Cancel options for this. Perhaps, not a Toolbar button, but something more dynamic smoothly poping up once we start editing. [B]3.[/B] Ability to have drop-down if the field was a drop-down choice. Alex, please look into listed above notes and comment. I know everything is possible - it's a matter of time so please be considerable. We have agreed that he'll look into the Interfaces and provide us with some new ideas how to better implement into what we have now.
(0002206)
Dmitry   
2010-05-14 17:40   
Also, uploaded (grid_editable_price-cleaned-Dmitry.patch file) cleaned version of Alex's patch after 5.0.3 merge into 5.1.0 considering numerous changes in products_config.php.
(0002207)
alex   
2010-05-15 04:33   
Reminder sent to: Dmitry
So you are trying to convert our grid to Microsoft Excel? Our grid wasn't designed for that. For example no input inside is resized, when you resize column. For now I use current cell data to place OnClick handler to replace that text with textbox. In case, when field displayed is empty, then click won't work. Also you imagine that we will have a lot of click handlers (for each cell in each row) for all this to work no matter if user will click on cell to change data or not. At the end we will face same problems, as described in [url]http://groups.google.com/group/in-portal-dev/browse_thread/thread/6d9a942de3693087[/url] discussion. Also any large scale modifications of javascript-based grid will make it slower for sure and I don't think, that this is what we want most. By my opinion editable grid is not the feature, that we will experience in 5.1.0 release.
(0002211)
Dmitry   
2010-05-15 18:39   
Hi Alex, Thanks for the feedback. The answer is NO we are not trying to convert to MS Excel! The goal is to fully review the options we have and improve the Grid in such way so it becomes even more easier to work with and more attractable to the regular users, and more then just a plan grid! Timeline - I propose to move this whole improvement thing to 5.2.0, and work on all Grid aspects at once. I believe we all can agree that our grid needs to evolve and many ways so it's more lightweight, Ajax enabled, Pagination and Sorting friendly and uses the JQ if possible. Please keep in mind we need to do both Interface and Code improvements to reach higher goals! What you think?
(0002214)
alex   
2010-05-16 01:45   
Agreed, let's move.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
178 [In-Portal CMS] Other bug report always 2009-08-04 16:17 2010-12-06 13:05
Reporter: Dmitry Platform:  
Assigned To: Dmitry OS:  
Priority: minor OS Version:  
Status: needs work Product Version: 5.0.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: Google Groups http://groups.google.com/group/in-portal-dev/browse_thread/thread/f59f71c76410d128
Change Log Message:
Estimate Points: 0
Summary: Replace nlsMenu in Admin and Front with JQuery
Description: Replace nlsMenu in Admin and Front with JQuery.

Requirements:

1. JS, but fully Search Engine Friendly.

In a perfect world it should be based on LI and A elements, but run on
JavaScript.

2. Highly Customizable.

Can be used as Horizontal as well as Vertical website menu. Full
support of CSS and good custom options/settings.

3. Open Source.

Menu script can be used in other Open Source as well as Commercial
scripts. Normally it would be ANYTHING under open source licenses like
GPL, LGPL or similar.
Steps To Reproduce:
Additional Information: Issue Moved to 5.0.2 release.
Attached Files:
(0001192)
alex   
2009-12-20 07:43   
This is not supposed to be done soon, so moving away from 5.0.2 release.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
671 [In-Commerce] Data Management bug report always 2010-03-27 18:26 2010-12-06 12:49
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.0.3-B1  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-bugs/browse_thread/thread/c5f623d9752037d0
Change Log Message:
Estimate Points: 0
Summary: Store "Qty Sold" in separate field, not in "Hits" field and update processing code too
Description: I propose to create "QtySold" for products and update it instead of "Hits" field. Then we should use Hits field for counting how much users are visiting product detail page (as it works for link detail page for now). Then we'll create new "top_seller" value for "types" parameter (usage: <inp2:p_PrintList render_as="top_seller_element" types="top_seller" parent_cat_id="any"/>) which will list only products, that were sold at all. Default sorting for such product list will be: most sold on top with user unable to change it of course.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
875 [In-Portal CMS] Data Management feature request N/A 2010-09-28 10:10 2010-12-06 11:59
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: reviewed and tested Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/82362d6da4761151
Change Log Message: Added ability to specify size and orientation for generated PDFs
Estimate Points: 0
Summary: Ability to set custom page size of PDF document
Description: In-Portal has nice kPDFHelper class, that allows to generate PDF document based on given template name. It only has limitation, that it always uses A4 as page size for created document. And there is no ability to change that format from inside of HTML.

Here is patch, that allows to change page size using @page { size: width height orientation; } which is complaint to CSS2 specifications. You can set page size and orientation or one of them.
Steps To Reproduce:
Additional Information:
Attached Files: custom_page_size_support_for_pdfhelper.patch (7,229) 2010-09-28 10:10
http://tracker.in-portal.org/file_download.php?file_id=792&type=bug
custom_page_size_support_for_pdfhelper_v2.patch (8,371) 2010-10-06 03:42
http://tracker.in-portal.org/file_download.php?file_id=797&type=bug
(0002877)
alex   
2010-10-06 03:44   
Patch "custom_page_size_support_for_pdfhelper_v2.patch" fixes: * problem, when tag BODY size wasn't affected by specified page size * TCPDF default margins was preventing images that should fill all page from rendering correctly (they were shifted right and appeared on next page)
(0002887)
Dmitry   
2010-10-17 11:56   
Tested okay on 5.1.1 Beta1
(0003114)
alex   
2010-12-06 11:59   
Moving to future, since we plan to use mPDF instead of whole kPDFHelper class.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
864 [In-Portal CMS] Data Management bug report always 2010-09-15 05:10 2010-12-06 11:58
Reporter: alex Platform:  
Assigned To: !COMMUNITY OS:  
Priority: normal OS Version:  
Status: reviewed and tested Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-bugs/browse_thread/thread/1eacc23733b1b767
Change Log Message:
Estimate Points: 0
Summary: Styles from HEAD tag are ignored by kPDFHelper
Description: I recently discovered, that kPDFHelper doesn't properly work with last version of kXMLHelper class. In particular it results a <style> within <head> tag to be ignored.
Steps To Reproduce:
Additional Information:
Attached Files: head_styles_ignored_fix.patch (781) 2010-09-15 05:10
http://tracker.in-portal.org/file_download.php?file_id=770&type=bug
(0002836)
alex   
2010-09-15 05:12   
To test create template (that will be converted to PDF document) and set body background color like this: Without this patch page color will be white, but with patch it will became red.
(0002888)
Dmitry   
2010-10-17 11:57   
Tested fine on 5.1.1 Beta1.
(0003113)
alex   
2010-12-06 11:58   
Moving to future, since we plan to use mPDF instead of whole kPDFHelper class.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
935 [In-Portal CMS] Data Management feature request always 2010-11-25 08:18 2010-11-26 10:17
Reporter: phil Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-bugs/browse_thread/thread/e65cee7ca10911bd
Change Log Message: Added "alt" field for category item file upload
Estimate Points: 0
Summary: File Upload Short Description Field
Description: When we upload a file, we are missing a field to describe the file, which would be used to display on front (actually we have file 1, file 2...).

we need to:
- add "Description" field to files in database
- create corresponding File1Description, File2Description ... virtual fields for storing Description creation processing code

Name - filled automatically by system (required)
Description - filled by user (optional), link/product name is displayed as "Description" when not entered
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
895 [In-Portal CMS] Data Management feature request always 2010-10-20 23:05 2010-10-20 23:05
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.1-B2  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/720cfe294c660f31
Change Log Message:
Estimate Points: 0
Summary: Improvements to Custom Field Validations
Description: 1. Add 2 Validation fields which would hold basic validation options
for Text field:

a. Validation drop-down with basic presets like Email address or Regular Expression
b. Text field which will be shown only when Regular Expression is selected and will hold that actual express which will be used for data entry validation both Admin and Front end.


2. Admin Validation of Custom Field name - when user is defining new custom field - most of them don't know that Spaces are NOT allowed.

Implement sort of validation we are doing with phrase names: only Latin characters and numbers (must start with letter in any case) + "_".
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
537 [In-Commerce] Shipping Engine feature request always 2010-01-06 18:50 2010-09-28 12:04
Reporter: Dmitry Platform:  
Assigned To: gleb OS:  
Priority: normal OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: FedEx Intergration
Description: Integration of FedEx Shipping Engine.
Steps To Reproduce:
Additional Information: Project Phrases:

1. Research and document (current)
2. Plan
3. Estimate development type
4. Development process
5. Beta testing
6. Schedule for In-Commerce release
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
863 [In-Portal CMS] Template System feature request always 2010-09-12 22:56 2010-09-12 22:57
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version:  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference: http://groups.google.com/group/in-portal-dev/browse_thread/thread/601a4153b90af84a
Change Log Message: New "less_than" and "greater_than" functionality for IF tag
Estimate Points: 0
Summary: Add new "less_than" and "greater_than" parameters to IF tag
Description: In-Portal has <inp2:m_if tag, that allows to display template parts based on a condition, e.g.
 

<inp2:m_if check="prefix_TagName">
    show something
</inp2:m_if>


Text "show something" will be visible only, when tag "TagName" of prefix
"prefix" will return *true*.

Also, that <inp2:m_if tag has universal parameter called "equals_to", that allows to compare any tag result to given value list (multiple values can be separated using |, e.g. "*value1|value2|value3*").


Proposed new functionality:

1. add "greater_than" and "less_than" parameters + their processing

2. move that 3 parameters ("greater_than", "less_than" and "equals_to") processing into compiled template code, so we have no to check for their presence during each tag processing.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
76 [In-Portal CMS] Admin Interfaces feature request N/A 2009-06-15 07:32 2010-08-31 14:27
Reporter: alex Platform:  
Assigned To: Dmitry OS:  
Priority: normal OS Version:  
Status: needs feedback Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Ability to export language export to another site
Description: On language export screen add text field, where user can specify another In-Portal-based site to import given language to. This was we can transfer language packs between various in-portal installations in 3 clicks:
1. select language(-s)
2. press Export button
3. enter target site url
4. press export button.
Steps To Reproduce:
Additional Information:
Attached Files:
(0000214)
alex   
2009-08-03 07:53   
Can we move this issue a bit closer to releasing, maybe to 5.1.0. This feature could prove very useful, when you have 2 or more sites and want to keep language pack synchronized and up to date.
(0000215)
Dmitry   
2009-08-03 11:02   
I still have some questions on this. Can you describe in a bit more details how do we can specify which new installation to import to? Sites should reside on the same server so DB access can be gained?
(0000281)
alex   
2009-08-09 03:25   
This is how it works: On language export screen you specify url of any In-Portal installation, that have In-Portal where such functionality is also present, like this: "http://www.in-portal.net" (no need to be on the same server). Also I now see, that we should specify admin's login and password for script to be able login remotely on other side. Then when you press "Save/Export" button on that screen and curl request, that logins you is sent to target site. If that works, then exported language pack (that normally you can download after export is done) is sent also via curl to target site. On target site received language pack is imported with no overwrite option. This way you can populate same language pack, that can even contain multiple languages to other In-Portal based website without leaving your administrative console. If error will happen during one of curl requests (can't login using given user and password or can't import language pack) then this error will be shown in appropriate field.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
269 [In-Portal CMS] Admin Interfaces feature request N/A 2009-09-04 14:06 2010-08-31 14:27
Reporter: alex Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: "Form Layout" Configurator for Add/Edit Templates in Admin
Description: Most of data editing templates in administrative console have one column layout, this means, that fields on such forms are placed one under another by one field in a row. This suits for most of the forms, but when it comes to forms that required more fields to be placed on standard size (e.g. 1024x768) form, then not easy to achieve. Currently we can create table with required layout and place fields into it, but form field automatic resizing will not work, because it assumes, that all fields are placed into one column and resized them accordingly.

Idea is to add new unit config option named "FormLayouts", that will be collected from all unit configs into single placed and then used where requested. Mentioned above option will be associative array, where key is layout name, but value is array, that represents layout. It will be better understandable using example below:

$config = Array (
    'FormLayouts' => Array (
        'SingleColumn' => Array (
            Array (
                'attributes' => Array ('id' => 'sample_id', 'class' => 'sample-class another-class'),
                'cells' => Array (
                    'cell_one' => Array ('id' => 'cell_id', 'style' => 'width: 100%; background-color: red;'),
                )
            ),
        ),
        
        'TwoColumns' => Array (
            Array (
                'attributes' => Array ('id' => 'sample_id', 'class' => 'sample-class another-class'),
                'cells' => Array (
                    'cell_one' => Array ('id' => 'cell_id', 'style' => 'width: 50%; background-color: red;'),
                    'cell_two' => Array ('style' => 'width: 50%; background-color: green;'),
                )
            ),
        ),
        
        'MixedColumns' => Array (
            Array (
                'attributes' => Array ('id' => 'sample_id', 'class' => 'sample-class another-class'),
                'cells' => Array (
                    'cell_one' => Array ('id' => 'cell_id', 'style' => 'width: 50%; background-color: red;'),
                    'cell_two' => Array ('style' => 'width: 50%; background-color: green;'),
                )
            ),
            Array (
                'attributes' => Array ('id' => 'other_id', 'class' => 'sample-class another-class'),
                'cells' => Array (
                    'cell_three' => Array ('colspan' => 2, 'style' => 'width: 100%; background-color: red;'),
                )
            ),
        ),
    ),

);

In example above there are defined 3 layouts: SingleColumn, TwoColumns and MixedColumns. Each layout except of MixedColumns have 1 row (it's record count on 1st level of layout declaration). Each consists of two more arrays: attributes (row HTML attributes, optional) and cells (cells inside given row, required). It's required, that each row must consist of at least one cell. Each cell has it's name (e.g. cell_one, cell_three), that must be unique inside given layout. This cell name will be used to place form fields inside that cell later when form will be defined, that uses given layout (see task 0000270).

When used, each layout will be directly converted to HTML table inside template. Besides layout, specified inside form declaration (see task 0000270) will help javascript Form class correctly determine location of each field inside layout and resize it respectively.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
229 [In-Portal CMS] Front End feature request always 2009-08-14 13:02 2010-08-31 14:26
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Ability to Auto-Validate Form Fields using Ajax
Description: Let's add functionality for Auto-Validation Form Fields using Ajax.

This will submit submit Ajax request with the data and mark field as Ok or Invalid with corresponding error message.

This should be able to handle cross-prefix fields on the same form and trigger validation on Change or Blur event.
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
116 [In-Portal CMS] Admin Interfaces bug report always 2009-07-17 20:34 2010-08-31 14:25
Reporter: Dmitry Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: active Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: In-Portal Tags not Visible in FCK Editor Textareas
Description: In-Portal Tags are fully skipped and not visible in FCK Textareas.

Example - Your suggested category "" has been added.

This mainly applies to Email Templates editing.


Need to find solution to escape <INP2:../> tags so they some visible or at least treated as Regular text.
Steps To Reproduce:
Additional Information:
Attached Files: in-portal tags in fckeditor.patch (6,978) 2009-09-29 14:58
http://tracker.in-portal.org/file_download.php?file_id=56&type=bug
(0000136)
alex   
2009-07-19 05:53   
Reminder sent to: Dmitry
Earlier such tags were threated as HTML and were mangled and were broken as a result. I've implemented this quick fix, that hides such tags from editor window, but they will be back, when text is saved. Although there are some cases, when tag is between two words and words are deleted, then tag is deleted as well. Normally we should display place holders (yellow ones, like in Dreamweaver) where in-portal tags are located.
(0000157)
Dmitry   
2009-07-19 08:47   
Agreed, we'll work on this shortly
(0000188)
alex   
2009-07-25 06:33   
I've tried to research what actually FCKEditor will allow and here is what I've got: 1. all non-pair In-Portal tags are converted to pair tags, because FCKEditor don't know anything about them: will become 2. all tag names and parameter names are lowercased, because it's XHTML. 3. There is a way to replace In-Portal tags with fake images and replace them back when text is saved, but this results in that content of pair In-Portal tags, like "" is not visible/editable after replace is made and we can see only one image. If we have nested pair tags, with some html inside, then we can't edit it after this replace. 4. When replacing In-Portal tags to fake images there is no way to determine if we are replacing opening or closing tag, both tags appear to be same document element with contents inside it. As a result this quite difficult to do such a thing. Maybe you will have better luck finding useful solution on the Internet (pair tags content should be visible after fake images are shown!).
(0000590)
alex   
2009-09-29 14:59   
I've attached what I've done so far. I hope, that this will be starting point when we address this issue later.





Viewing Issue Advanced Details
ID: Category: Type: Reproducibility: Date Submitted: Last Update:
71 [In-Portal CMS] Admin Interfaces bug report always 2009-06-13 10:38 2010-08-31 14:25
Reporter: alex Platform:  
Assigned To: alex OS:  
Priority: critical OS Version:  
Status: needs work Product Version: 5.1.0  
Product Build: Resolution: open  
 
ETA: none Fixed in Version:  
    Target Version: Icebox  
Reference:
Change Log Message:
Estimate Points: 0
Summary: Impossible to add image and link to it in one screen in FCKEditor
Description: 1. In FCKEditor press "Insert/Modify Image" button.
2. Upload or select image from already uploaded.
3. Go to "Link" tab and select link to internal page.
4. Press OK.

As a result there will be link to correct page, but instead of image inside link we will get @@ID@@ (this is actual link in href attribute).
Steps To Reproduce:
Additional Information:
Attached Files: